[JBoss JIRA] (WFLY-8301) Picketlink trust domain config needs to be in attribute and not path
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-8301:
---------------------------------
Summary: Picketlink trust domain config needs to be in attribute and not path
Key: WFLY-8301
URL: https://issues.jboss.org/browse/WFLY-8301
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Tomaz Cerar
Assignee: Darran Lofthouse
Currently trustdomain for PL federation is configured by adding new sub resource under idenity-provider
Problem is that name of the trust domain resource you add is an url.
In case that URL is ipv6 one in square brackets [::1] this makes it a invalid path.
Currently testsuite relies on this to work, and by some miracle it works when configured via XML, but trying to do so with CLI fails as [] are forbidden chars in path (resource name)
example of CLI command
{{/subsystem=picketlink-federation/federation=federation-simple-redirect-binding/identity-provider=idp-redirect.war/trust-domain=${public.ip}:add
/subsystem=picketlink-federation/federation=federation-redirect-with-signatures/identity-provider=idp-redirect-sig.war/trust-domain=${public.ip}:add
/subsystem=picketlink-federation/federation=federation-simple-post-binding/identity-provider=idp-post.war/trust-domain=${public.ip}:add
/subsystem=picketlink-federation/federation=federation-post-with-signatures/identity-provider=idp-post-sig.war/trust-domain=${public.ip}:add
/subsystem=picketlink-federation/federation=federation-with-metadata/identity-provider=idp-metadata.war/trust-domain=${public.ip}:add}}
where ${public.ip} can be 127.0.01 or [::1]
I think given that TrustDomainResourceDefinition has no attributes beyond own name.
it could be converted to a List<String> on parent resource.
or name should be used only for id, with additional attribute that would represent domain.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-8228:
-----------------------------
Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/141 (was: https://github.com/wildfly/wildfly/pull/9748, https://github.com/wildfly-security-incubator/wildfly/pull/141)
> Servlet server distribution fails to work with Elytron - NoClassDefFoundError
> -----------------------------------------------------------------------------
>
> Key: WFLY-8228
> URL: https://issues.jboss.org/browse/WFLY-8228
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Ingo Weiss
> Priority: Blocker
> Original Estimate: 1 day
> Time Spent: 1 day
> Remaining Estimate: 0 minutes
>
> Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails.
> Sample output:
> {code}
> 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json
> at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91)
> at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42)
> at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104)
> at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156)
> at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56)
> at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35)
> at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588)
> at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595)
> at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110)
> 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:84)
> 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:46)
> 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:1702)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702)
> 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:211)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-8228:
-----------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9748 (was: https://github.com/wildfly/wildfly/pull/9744)
> Servlet server distribution fails to work with Elytron - NoClassDefFoundError
> -----------------------------------------------------------------------------
>
> Key: WFLY-8228
> URL: https://issues.jboss.org/browse/WFLY-8228
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Ingo Weiss
> Priority: Blocker
> Original Estimate: 1 day
> Time Spent: 1 day
> Remaining Estimate: 0 minutes
>
> Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails.
> Sample output:
> {code}
> 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json
> at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91)
> at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42)
> at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104)
> at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156)
> at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56)
> at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35)
> at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588)
> at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595)
> at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110)
> 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:84)
> 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:46)
> 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:1702)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702)
> 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:211)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8228) Servlet server distribution fails to work with Elytron - NoClassDefFoundError
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-8228:
-----------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9748, https://github.com/wildfly-security-incubator/wildfly/pull/141 (was: https://github.com/wildfly/wildfly/pull/9748)
> Servlet server distribution fails to work with Elytron - NoClassDefFoundError
> -----------------------------------------------------------------------------
>
> Key: WFLY-8228
> URL: https://issues.jboss.org/browse/WFLY-8228
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Ingo Weiss
> Priority: Blocker
> Original Estimate: 1 day
> Time Spent: 1 day
> Remaining Estimate: 0 minutes
>
> Elytron uses {{javax.json.Json}} to format audit events (e.g. authentication). The {{javax.json}} is not part of the servlet distribution, so the usage of Elytron fails.
> Sample output:
> {code}
> 17:08:20,394 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /form-auth/restricted/j_security_check: java.lang.NoClassDefFoundError: javax/json/Json
> at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:91)
> at org.wildfly.security.audit.JsonSecurityEventFormatter.handlePermissionCheckEvent(JsonSecurityEventFormatter.java:42)
> at org.wildfly.security.auth.server.event.SecurityEventVisitor.handlePermissionCheckSuccessfulEvent(SecurityEventVisitor.java:104)
> at org.wildfly.security.auth.server.event.SecurityPermissionCheckSuccessfulEvent.accept(SecurityPermissionCheckSuccessfulEvent.java:43)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$1.lambda$null$1(AuditResourceDefinitions.java:156)
> at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:56)
> at org.wildfly.security.audit.AuditLogger.accept(AuditLogger.java:35)
> at org.wildfly.security.auth.server.SecurityDomain.handleSecurityEvent(SecurityDomain.java:588)
> at org.wildfly.security.auth.server.SecurityDomain.safeHandleSecurityEvent(SecurityDomain.java:595)
> at org.wildfly.security.auth.server.SecurityIdentity.implies(SecurityIdentity.java:684)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1727)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1697)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:450)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:446)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:929)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:728)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:215)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:105)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:110)
> 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:84)
> 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:46)
> 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:1702)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1702)
> 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:211)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-8217:
--------------------------------------
I get exactly the same result with the snapshot (downloaded 30 minutes ago on March 6th, 2017). I'll attach the server.log.
> ActiveMQ leaks connections if a JMS message is sent from an MDB
> ---------------------------------------------------------------
>
> Key: WFLY-8217
> URL: https://issues.jboss.org/browse/WFLY-8217
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
> Reporter: Scott Van Wart
> Assignee: Jeff Mesnil
> Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log
>
>
> If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test).
> 1) Build the EAR
> 2) Run wildfly with the standalone-full.xml configuration:
> {{standalone.bat --server-config=standalone-full.xml}}
> 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM:
> {{jboss-cli.bat -c}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}}
> 4) Deploy the EAR.
> 5) Access http://localhost:8080/leak-web/rest/test?message=Hi
> The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs
> (see attached log.txt)
> I have no idea why JIRA attached each file twice.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.... ]
Scott Van Wart updated WFLY-8217:
---------------------------------
Attachment: server.log
> ActiveMQ leaks connections if a JMS message is sent from an MDB
> ---------------------------------------------------------------
>
> Key: WFLY-8217
> URL: https://issues.jboss.org/browse/WFLY-8217
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
> Reporter: Scott Van Wart
> Assignee: Jeff Mesnil
> Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log
>
>
> If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test).
> 1) Build the EAR
> 2) Run wildfly with the standalone-full.xml configuration:
> {{standalone.bat --server-config=standalone-full.xml}}
> 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM:
> {{jboss-cli.bat -c}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}}
> 4) Deploy the EAR.
> 5) Access http://localhost:8080/leak-web/rest/test?message=Hi
> The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs
> (see attached log.txt)
> I have no idea why JIRA attached each file twice.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8299) There is missing CS integration with core management
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8299?page=com.atlassian.jira.plugin.... ]
Hynek Švábek commented on WFLY-8299:
------------------------------------
[~brian.stansberry]
RFE EAP7-538 has requirements to update core management to use credential store reference. This RFE had VERIFICATION TODO state yet. And this wasn't implemented yet.
> There is missing CS integration with core management
> ----------------------------------------------------
>
> Key: WFLY-8299
> URL: https://issues.jboss.org/browse/WFLY-8299
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Priority is BLOCKER because this issue blocks RFE verification https://issues.jboss.org/browse/EAP7-538
> There must be credential store integration with core management as is mentioned in requirements of RFE.
> *management/security-realm*
> *management/security-realm/authentication/truststore* keystore-password
> *management/security-realm/server-identity/ssl* key-password and keystore-password
> *management/security-realm/server-identity/secret*
> *management/security-realm/authentication/users*
> But *security-realm* is deprecated, these resources have this description:
> {code}
> The security-realm configuration is deprecated and may be removed or moved in future versions.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1048:
----------------------------------
Description:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
https://help.github.com/articles/renaming-an-organization/
Preparation:
1) Get some experience
- Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from foo_org
-- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and rename it from foo_org to foo_org_kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
More stuff to try:
- What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect?
2) (Optional - not needed now that we are renaming org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be renaming the org.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- Freeze starts, announce in capitals on every IRC channel
- Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way).
- *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/
- Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this?
- Freeze stops, announce in capitals on every IRC channel
6) Clean up the fallout
- Change the pom.xml scm tag for master (in all repo's that ref it)
- Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to:
-- all code
-- openhub
-- jira
-- fisheye
-- .org websites (incl jboss.properties)
-- jboss.org
- have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac).
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
was:
[~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
https://help.github.com/articles/renaming-an-organization/
Preparation:
1) Get some experience
- Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
-- Once from foo_org
-- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...")
- Add some local changes on both dirs.
- On GitHub, go into the repository settings, in the danger zone and move it from foo_org to foo_org_kiegroup.
- Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
-- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
-- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
-- What happened to the open PR?
More stuff to try:
- What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect?
2) (Optional - not needed now that we are moving org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
4) Reach out
- Talk to each type of person involved:
-- R&D developer
-- QA
-- Productization
-- Product docs
-- Community
- Make an inventory of references to "github.com/droolsjbpm"
-- Do a find in path on all our files for "github.com/droolsjbpm")
-- Which webapps reference it?
--- jenkins
--- jira
--- www.openhub.net
--- gitter
--- stackoverflow
--- google forums / mailing lists
--- ...
- Set a date when you'll be renaming the org.
-- Clearly communicate on all channels to let everyone know. This includes:
--- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
--- Internal mailing lists: sme-brms, pm lists, bsig, etc
--- IRC channel topics
--- Social media (Twitter accounts etc)
--- ...
- Clearly communicate:
-- What you'll do
-- When you'll do it
-- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
-- A recipe: What they need to do - step by step for dummies - after the merge is done.
-- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out.
- You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
5) Do it:
- Freeze starts, announce in capitals on every IRC channel
- Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way).
- *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/
- Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this?
- Freeze stops, announce in capitals on every IRC channel
-OLD WAY Don't do this any more:
- You can do one repository at a time, or do multiple at the same time.
-- I'd recommend to start with just 1 to get a feel for it.
- Do them in reverse order of the repository-list.txt!
- DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
-- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
-- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
- In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
- Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
OLD WAY END-
6) Clean up the fallout
- Change the pom.xml scm tag for master and 7.0.x (in all repo's that ref it)
- Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to:
-- all code
-- openhub
-- jira
-- fisheye
-- .org websites (incl jboss.properties)
-- jboss.org
- have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac).
Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
> Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
> ---------------------------------------------------------------------
>
> Key: DROOLS-1048
> URL: https://issues.jboss.org/browse/DROOLS-1048
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Critical
>
> [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
> https://help.github.com/articles/renaming-an-organization/
> Preparation:
> 1) Get some experience
> - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
> -- Once from foo_org
> -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...")
> - Add some local changes on both dirs.
> - On GitHub, go into the repository settings, in the danger zone and rename it from foo_org to foo_org_kiegroup.
> - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
> -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
> -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
> -- What happened to the open PR?
> More stuff to try:
> - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect?
> 2) (Optional - not needed now that we are renaming org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
> 4) Reach out
> - Talk to each type of person involved:
> -- R&D developer
> -- QA
> -- Productization
> -- Product docs
> -- Community
> - Make an inventory of references to "github.com/droolsjbpm"
> -- Do a find in path on all our files for "github.com/droolsjbpm")
> -- Which webapps reference it?
> --- jenkins
> --- jira
> --- www.openhub.net
> --- gitter
> --- stackoverflow
> --- google forums / mailing lists
> --- ...
> - Set a date when you'll be renaming the org.
> -- Clearly communicate on all channels to let everyone know. This includes:
> --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
> --- Internal mailing lists: sme-brms, pm lists, bsig, etc
> --- IRC channel topics
> --- Social media (Twitter accounts etc)
> --- ...
> - Clearly communicate:
> -- What you'll do
> -- When you'll do it
> -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
> -- A recipe: What they need to do - step by step for dummies - after the merge is done.
> -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out.
> - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
> 5) Do it:
> - Freeze starts, announce in capitals on every IRC channel
> - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way).
> - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/
> - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this?
> - Freeze stops, announce in capitals on every IRC channel
> 6) Clean up the fallout
> - Change the pom.xml scm tag for master (in all repo's that ref it)
> - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to:
> -- all code
> -- openhub
> -- jira
> -- fisheye
> -- .org websites (incl jboss.properties)
> -- jboss.org
> - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac).
> Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by Radovan Netuka (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
Radovan Netuka commented on SECURITY-921:
-----------------------------------------
PR for master branch: https://github.com/wildfly-security/jboss-negotiation/pull/36
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final
> Environment: *
> Reporter: Harald Krause
> Assignee: Radovan Netuka
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months