[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ]
Darran Lofthouse resolved WFCORE-107.
-------------------------------------
Resolution: Won't Do
No demand for this change.
> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
> Key: WFCORE-107
> URL: https://issues.jboss.org/browse/WFCORE-107
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-1145.
--------------------------------------
Resolution: Out of Date
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: affects_elytron, domain-mode
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-2346) Revisit enforcement of required file system permissions.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-2346?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2346.
--------------------------------------
Resolution: Out of Date
> Revisit enforcement of required file system permissions.
> --------------------------------------------------------
>
> Key: WFCORE-2346
> URL: https://issues.jboss.org/browse/WFCORE-2346
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: management_security,
>
> Now that AS8 has moved to Java 7 we can re-visit the level of control we have over file system permissions, this can be from taking more control of the local authentication mechanism to ensure incorrect permissions are not inherited to verifying sensitive configuration files are not world readable.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-11530) Distributed @Stateful EJB implementation should not hold references to CapabilityServiceSupport
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-11530:
-----------------------------------
Summary: Distributed @Stateful EJB implementation should not hold references to CapabilityServiceSupport
Key: WFLY-11530
URL: https://issues.jboss.org/browse/WFLY-11530
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 15.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The Distributed @Stateful EJB implementation currently holds references to the CapabilityServiceSupport obtained via the OperationContext, in order to resolve capability names. We should migrate this code to fully leverage CapabilityServiceConfigurator when configuring service dependencies.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
by Geoffrey De Smet (Jira)
[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1781:
-------------------------------------
Description:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* Look for all "findbugs" and replace it by "spotbugs"
** Except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave that one alone!
** For example, change findbugs-check -> spotbugs-check, ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
was:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
** findbugs-check -> spotbugs-check
** ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-1781
> URL: https://issues.jboss.org/browse/DROOLS-1781
> Project: Drools
> Issue Type: Task
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Priority: Major
> Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> *How to migrate*
> * Replace
> {code}
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>findbugs-maven-plugin</artifactId>
> {code}
> by
> {code}
> <groupId>com.github.spotbugs</groupId>
> <artifactId>spotbugs-maven-plugin</artifactId>
> {code}
> * Look for all "findbugs" and replace it by "spotbugs"
> ** Except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave that one alone!
> ** For example, change findbugs-check -> spotbugs-check, ...
> * Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
> * Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
> ** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
> ** Ignore contributed experiments, that repo is dead
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
by Geoffrey De Smet (Jira)
[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1781:
-------------------------------------
Description:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
** findbugs-check -> spotbugs-check
** ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
was:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
** findbugs-check -> spotbugs-check
** ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-1781
> URL: https://issues.jboss.org/browse/DROOLS-1781
> Project: Drools
> Issue Type: Task
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Priority: Major
> Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> *How to migrate*
> * Replace
> {code}
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>findbugs-maven-plugin</artifactId>
> {code}
> by
> {code}
> <groupId>com.github.spotbugs</groupId>
> <artifactId>spotbugs-maven-plugin</artifactId>
> {code}
> * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
> ** findbugs-check -> spotbugs-check
> ** ...
> * Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
> * Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
> ** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
> ** Ignore contributed experiments, that repo is dead
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
by Geoffrey De Smet (Jira)
[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1781:
-------------------------------------
Description:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
** findbugs-check -> spotbugs-check
** ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
was:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate (by Geoffrey)*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
** findbugs-check -> spotbugs-check
** ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-1781
> URL: https://issues.jboss.org/browse/DROOLS-1781
> Project: Drools
> Issue Type: Task
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Priority: Major
> Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> *How to migrate*
> * Replace
> {code}
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>findbugs-maven-plugin</artifactId>
> {code}
> by
> {code}
> <groupId>com.github.spotbugs</groupId>
> <artifactId>spotbugs-maven-plugin</artifactId>
> {code}
> * * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
> ** findbugs-check -> spotbugs-check
> ** ...
> * Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
> * Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
> ** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
> ** Ignore contributed experiments, that repo is dead
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
by Geoffrey De Smet (Jira)
[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1781:
-------------------------------------
Description:
SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
*How to migrate (by Geoffrey)*
* Replace
{code}
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
{code}
by
{code}
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
{code}
* * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
** findbugs-check -> spotbugs-check
** ...
* Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
* Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
** Ignore contributed experiments, that repo is dead
was:SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-1781
> URL: https://issues.jboss.org/browse/DROOLS-1781
> Project: Drools
> Issue Type: Task
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Priority: Major
> Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> *How to migrate (by Geoffrey)*
> * Replace
> {code}
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>findbugs-maven-plugin</artifactId>
> {code}
> by
> {code}
> <groupId>com.github.spotbugs</groupId>
> <artifactId>spotbugs-maven-plugin</artifactId>
> {code}
> * * Look for all "findbugs" and replace it by "spotbugs", except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave those alone.
> ** findbugs-check -> spotbugs-check
> ** ...
> * Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
> * Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
> ** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
> ** Ignore contributed experiments, that repo is dead
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ELY-1475) Empty username for FormAuthenticationMechanism causes IllegalArgumentException
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1475:
----------------------------------
Fix Version/s: 1.2.0.Beta12
(was: 1.8.0.CR1)
> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
> Key: ELY-1475
> URL: https://issues.jboss.org/browse/ELY-1475
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.2.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Priority: Major
> Fix For: 1.2.0.Beta12
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months