January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2596) JASPI Web layer problems

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2596?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-2596: ------------------------------------ Assignee: Stefan Guilhen (was: Stuart Douglas) Stefan is looking at the remaining failures > JASPI Web layer problems > ------------------------ > > Key: WFLY-2596 > URL: https://issues.jboss.org/browse/WFLY-2596 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: Fedora 19, x86_64 > Reporter: István Tóth > Assignee: Stefan Guilhen > > I have found several problems in the current (master, trunk) Wildfly JASPI Web layer implementation > Undertow related: > ---------------------- > * It does not support pre-emptive authentication: > When the ServerAuthenticationModule returns AUTH_SUCCESS and null userPrincipal, it should let the request fall through unathenticated, instead it is rejected. > * It does not call secureResponse when the authentication was unsuccessful > * It does not populate the org.jboss.security.SecurityContext, only the undertow Account structure. > * It does not support the wrapper feature (Spec 3.8.3.5 and B.9) > The attached pull request aims to fix the first three issues. > Credits: This patch is based on Arjan Tijms' analysis, and suggested patches for the Jboss 7.X valve based authentitactor. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2525) Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2525?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2525: -------------------------------------- See UNDERTOW-171 > Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416) > --------------------------------------------------------------------------------------------- > > Key: WFLY-2525 > URL: https://issues.jboss.org/browse/WFLY-2525 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23) > atmosphere chat-multiroom sample: > https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat... > Reporter: John Teller > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1 > > > In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling. In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error: > 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async > at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3] > at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3] > at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3] > at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3] > at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3] > at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager module needs a dependency on javax.mail.api

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1300: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1051335|https://bugzilla.redhat.com/show_bug.cgi?id=1051335] from NEW to POST > org.jboss.log4j.logmanager module needs a dependency on javax.mail.api > ---------------------------------------------------------------------- > > Key: WFLY-1300 > URL: https://issues.jboss.org/browse/WFLY-1300 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.Alpha1 > > > Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager module needs a dependency on javax.mail.api

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1300: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=971076, https://bugzilla.redhat.com/show_bug.cgi?id=1051335 > org.jboss.log4j.logmanager module needs a dependency on javax.mail.api > ---------------------------------------------------------------------- > > Key: WFLY-1300 > URL: https://issues.jboss.org/browse/WFLY-1300 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.Alpha1 > > > Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2725) Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2725?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2725: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1050003|https://bugzilla.redhat.com/show_bug.cgi?id=1050003] from NEW to POST > Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2725 > URL: https://issues.jboss.org/browse/WFLY-2725 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > > 'JBAS011046: A component named > 'TestBean' is already defined in this module', I have narrowed it > down to it occurs if they have a jar manifest with Class-Path: . > It looks like when deploying it looks at the jar with the manifest > entry which then must be having it scan the jar containing the EJB > again and failing. > Having the Class-Path: . doesn't really make sense to me, however it > also seems like we should not be trying to deploy it twice. > It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib > server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.java -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2725) Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2725?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2725: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1049999|https://bugzilla.redhat.com/show_bug.cgi?id=1049999] from NEW to POST > Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2725 > URL: https://issues.jboss.org/browse/WFLY-2725 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > > 'JBAS011046: A component named > 'TestBean' is already defined in this module', I have narrowed it > down to it occurs if they have a jar manifest with Class-Path: . > It looks like when deploying it looks at the jar with the manifest > entry which then must be having it scan the jar containing the EJB > again and failing. > Having the Class-Path: . doesn't really make sense to me, however it > also seems like we should not be trying to deploy it twice. > It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib > server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.java -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should Not Fail for Non-existent User.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2660: ----------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from NEW to POST > LDAP Group Loading - Should Not Fail for Non-existent User. > ----------------------------------------------------------- > > Key: WFLY-2660 > URL: https://issues.jboss.org/browse/WFLY-2660 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Final > > > Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP. > One example is local authentication where the user may not exist. > Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should Not Fail for Non-existent User.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2660: ----------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1051240|https://bugzilla.redhat.com/show_bug.cgi?id=1051240] from NEW to POST > LDAP Group Loading - Should Not Fail for Non-existent User. > ----------------------------------------------------------- > > Key: WFLY-2660 > URL: https://issues.jboss.org/browse/WFLY-2660 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Final > > > Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP. > One example is local authentication where the user may not exist. > Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2734) Unable to use --runtime_name in jboss-cli deploy command

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2734?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-2734: ------------------------------------- I believe it should be {{--runtime-name}}. Note the dash instead of the underscore. > Unable to use --runtime_name in jboss-cli deploy command > -------------------------------------------------------- > > Key: WFLY-2734 > URL: https://issues.jboss.org/browse/WFLY-2734 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Running on Windows 7 > Reporter: David Hatten > Labels: jboss, jboss-as > > When using the jboss-cli utility, I am unable to use the --runtime_name parameter to specify a Runtime Name. I have tried the following configurations: > 1) Deploy a war using both --name and --runtime_name. When I view the deployment in the admin console, both the Name and Runtime Name fields are set to the value of --name > 2) Deploy a war using only --runtime_name parameter. When I view the deployment in the admin console, the Runtime Name is the name of the file being deployed. > In both cases, the specified value of --runtime_name is ignored. I believe this is a bug and not a configuration error -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2734) Unable to use --runtime_name in jboss-cli deploy command

by David Hatten (JIRA)

David Hatten created WFLY-2734: ---------------------------------- Summary: Unable to use --runtime_name in jboss-cli deploy command Key: WFLY-2734 URL: https://issues.jboss.org/browse/WFLY-2734 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Environment: Running on Windows 7 Reporter: David Hatten When using the jboss-cli utility, I am unable to use the --runtime_name parameter to specify a Runtime Name. I have tried the following configurations: 1) Deploy a war using both --name and --runtime_name. When I view the deployment in the admin console, both the Name and Runtime Name fields are set to the value of --name 2) Deploy a war using only --runtime_name parameter. When I view the deployment in the admin console, the Runtime Name is the name of the file being deployed. In both cases, the specified value of --runtime_name is ignored. I believe this is a bug and not a configuration error -- 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

12 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2014