[JBoss JIRA] (WFCORE-1847) PatchMerger overrides submodule's content merging the outer module
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-1847:
-----------------------------------------
Summary: PatchMerger overrides submodule's content merging the outer module
Key: WFCORE-1847
URL: https://issues.jboss.org/browse/WFCORE-1847
Project: WildFly Core
Issue Type: Bug
Components: Patching
Affects Versions: 3.0.0.Alpha9
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
PatchMerger merges two CPs into one. In case the first CP includes updates for modules like org.outermodule and org.outermodule.innermodule. And the second CP including an update for org.outermodule.innermodule only, the merge may not happen correctly in case the modification for the innermodule will appear before the modification for the outermodule in the first CP.
The merger will copy the innermodule's content first and then override it copying the outermodule's content (including the previous version of the innermodule).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-7229:
------------------------------------
> It was coded because two standard mechanisms you mentioned were considered not sufficient. I'm not saying they didn't work - they did and still do, but we wished to free resources faster than they can. I didn't say that earlier, but there are actually +30 sessions per user to wipe (+30 apps we thought we needed coordinated logout for, to free resources).
The code in MainServlet will not free resources any faster than the standard mechanism. The distributed session manager in WF 10 does not rely on a polling mechanism (like older releases did), but instead schedules expiration eagerly. Thus sessions will be destroyed as soon as they are sufficiently idle.
> Now, in WF 10.1 (and only there) it's logging errors.
It's logging errors because this doesn't work in WF10. In WF10, the distributed HttpSession is not a traditional map of attributes, but rather a proxy to a distributed cache in which the session attributes are stored. This proxy is only functional within the context of a container thread (e.g. request thread, listener thread, async context thread, etc.).
> If I understood you right - then this is quite possibly what I want to happen.
I don't think you understood me fully. This would result in premature expiration. If a request fails over to another node, and the original node is still alive, it will expire the session even though it is still being used. I highly doubt that this is what you want to happen.
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ]
Peter Palaga commented on SECURITY-930:
---------------------------------------
> I'll try to find this commit and check if it has made it into WildFly. I'll post again once I figure this out.
[~sguilhen], any update on this?
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: SECURITY-930
> URL: https://issues.jboss.org/browse/SECURITY-930
> Project: PicketBox
> Issue Type: Bug
> Components: JBossSX, Security-SPI
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7255) Creating LDAP security realm fails with cryptic error message
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-644 to WFLY-7255:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-7255 (was: ELY-644)
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: WFLY-7255
> URL: https://issues.jboss.org/browse/WFLY-7255
> Project: WildFly
> Issue Type: Bug
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7255) Creating LDAP security realm fails with cryptic error message
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7255:
-----------------------------
Component/s: Security
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: WFLY-7255
> URL: https://issues.jboss.org/browse/WFLY-7255
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (ELY-644) Creating LDAP security realm fails with cryptic error message
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-644?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-644:
--------------------------------
Problem is the LdapRealm obtain value of "writable" attribute directly from query, fail instead of using default.
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: ELY-644
> URL: https://issues.jboss.org/browse/ELY-644
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7254) pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7254:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7254
> URL: https://issues.jboss.org/browse/WFLY-7254
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears).
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months