[JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller need to check access before attempting to read information
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------
Jakub Cechacek <jcechace(a)redhat.com> changed the Status of [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] from ON_QA to VERIFIED
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2139
> URL: https://issues.jboss.org/browse/WFLY-2139
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller need to check access before attempting to read information
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------
Jakub Cechacek <jcechace(a)redhat.com> made a comment on [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994]
Verified for 6.2.0.ER4
Tests previously failing due to this issue passed. After looking at threads through visual vm I consider this fixed.
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2139
> URL: https://issues.jboss.org/browse/WFLY-2139
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed
by Richard Bourner (JIRA)
[ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin... ]
Richard Bourner commented on DROOLS-281:
----------------------------------------
Additional information: it seems like the problem starts occuring for Beta3.
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
> Key: DROOLS-281
> URL: https://issues.jboss.org/browse/DROOLS-281
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR4
> Reporter: Richard Bourner
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2214) LDAP security realm needs to have configurable timeouts
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2214:
----------------------------------------
This actually raises an interesting point to also consider - if we can detect that the first server was not used maybe for a short period of time we should re-order the server list to give a higher priority to the server we know does exist.
As authentication also establishes a connection to the server to verify the password it would be beneficial to lower the priority of the missing server.
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
> Key: WFLY-2214
> URL: https://issues.jboss.org/browse/WFLY-2214
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Beta1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
> result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
> String url = config.require(URL).asString();
> result.put(Context.PROVIDER_URL,url);
> + result.put("com.sun.jndi.ldap.connect.timeout", "500");
> return result;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2157) JSF ViewExpiredException without cookies.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2157?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2157.
----------------------------------
Fix Version/s: 8.0.0.Beta1
Resolution: Done
> JSF ViewExpiredException without cookies.
> -----------------------------------------
>
> Key: WFLY-2157
> URL: https://issues.jboss.org/browse/WFLY-2157
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 8.0.0.Alpha4
> Reporter: Marek Schmidt
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Beta1
>
> Attachments: weld-numberguess.war
>
>
> On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)
> {noformat}
> 14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> ... 29 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months