[JBoss JIRA] (WFCORE-1815) It's not possible to re-add extension
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1815?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1815:
-----------------------------------
Assignee: Tomaz Cerar (was: Brian Stansberry)
> It's not possible to re-add extension
> --------------------------------------
>
> Key: WFCORE-1815
> URL: https://issues.jboss.org/browse/WFCORE-1815
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Martin Simka
> Assignee: Tomaz Cerar
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=ejb3:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] reload
> [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:remove
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'",
> "rolled-back" => true
> }
> {noformat}
> {noformat}
> 13:46:48,278 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.jboss.as.ejb3")]): java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:222)
> at org.jboss.as.controller.extension.ExtensionRegistry$DeploymentManagementResourceRegistration.registerSubModel(ExtensionRegistry.java:922)
> at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerDeploymentModel(ExtensionRegistry.java:700)
> at org.jboss.as.ejb3.subsystem.EJB3Extension.initialize(EJB3Extension.java:91)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83)
> 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)
> {noformat}
> the error with logging subsystem, I didn't try other subsystems
> reload after extension:remove helps
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1815) It's not possible to re-add extension
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1815?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1815:
-------------------------------------
I think it is similar problem to what we had in WFCORE-1785
> It's not possible to re-add extension
> --------------------------------------
>
> Key: WFCORE-1815
> URL: https://issues.jboss.org/browse/WFCORE-1815
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Martin Simka
> Assignee: Brian Stansberry
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=ejb3:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] reload
> [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:remove
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'",
> "rolled-back" => true
> }
> {noformat}
> {noformat}
> 13:46:48,278 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.jboss.as.ejb3")]): java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:222)
> at org.jboss.as.controller.extension.ExtensionRegistry$DeploymentManagementResourceRegistration.registerSubModel(ExtensionRegistry.java:922)
> at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerDeploymentModel(ExtensionRegistry.java:700)
> at org.jboss.as.ejb3.subsystem.EJB3Extension.initialize(EJB3Extension.java:91)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83)
> 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)
> {noformat}
> the error with logging subsystem, I didn't try other subsystems
> reload after extension:remove helps
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7192) 'name' attribute missing in XSD while required by web subsystem parser
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7192?page=com.atlassian.jira.plugin.... ]
Kabir Khan resolved WFLY-7192.
------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
> 'name' attribute missing in XSD while required by web subsystem parser
> ----------------------------------------------------------------------
>
> Key: WFLY-7192
> URL: https://issues.jboss.org/browse/WFLY-7192
> Project: WildFly
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Labels: downstream_dependency
> Fix For: 11.0.0.Alpha1
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal]
> While configuring the global valve using the following article :
> https://access.redhat.com/solutions/379813
> It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml".
> So "name" attribute is mandatory to configure this valve.
> but it is not mentioned in the schema of valve as shown below :
> {code:xml}
> <xs:element name="valve">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" />
> </xs:sequence>
> <xs:attribute name="class-name" type="xs:string" use="required" />
> <xs:attribute name="module" type="xs:string" use="required" />
> <xs:attribute name="enabled" default="true" type="xs:boolean" />
> </xs:complexType>
> </xs:element>
> {code}
> Version-Release number of selected component (if applicable):
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7143:
-----------------------------
Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/230 (was: https://github.com/wildfly-security/elytron-subsystem/pull/230, https://github.com/wildfly-security/wildfly-elytron/pull/496)
> Unsafe Elytron role/permission mapping
> --------------------------------------
>
> Key: WFLY-7143
> URL: https://issues.jboss.org/browse/WFLY-7143
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Jan Kalina
> Priority: Blocker
>
> Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
> The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
> {code:xml}
> <mappers>
> <simple-permission-mapper name="login-permission-mapper">
> <permission-mapping roles="All">
> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
> </permission-mapping>
> </simple-permission-mapper>
> <constant-role-mapper name="constant-roles" roles="All"/>
> </mappers>
> {code}
> We have to make the default server configuration secure for users.
> *Suggestions for improvement:*
> * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles
> * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7204) Unsafe Elytron role/permission mapping
by Jan Kalina (JIRA)
Jan Kalina created WFLY-7204:
--------------------------------
Summary: Unsafe Elytron role/permission mapping
Key: WFLY-7204
URL: https://issues.jboss.org/browse/WFLY-7204
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
{code:xml}
<mappers>
<simple-permission-mapper name="login-permission-mapper">
<permission-mapping roles="All">
<permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
</permission-mapping>
</simple-permission-mapper>
<constant-role-mapper name="constant-roles" roles="All"/>
</mappers>
{code}
We have to make the default server configuration secure for users.
*Suggestions for improvement:*
* the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles
* constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-641) Unsafe Elytron role/permission mapping
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-641?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7204 to ELY-641:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-641 (was: WFLY-7204)
Component/s: (was: Security)
> Unsafe Elytron role/permission mapping
> --------------------------------------
>
> Key: ELY-641
> URL: https://issues.jboss.org/browse/ELY-641
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
> The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
> {code:xml}
> <mappers>
> <simple-permission-mapper name="login-permission-mapper">
> <permission-mapping roles="All">
> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
> </permission-mapping>
> </simple-permission-mapper>
> <constant-role-mapper name="constant-roles" roles="All"/>
> </mappers>
> {code}
> We have to make the default server configuration secure for users.
> *Suggestions for improvement:*
> * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles
> * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2101) DELIVERY_TIME: protocol to measure delivery times
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2101?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2101:
---------------------------
Summary: DELIVERY_TIME: protocol to measure delivery times (was: DELIVERY_STATS: protocol to measure delivery times)
> DELIVERY_TIME: protocol to measure delivery times
> -------------------------------------------------
>
> Key: JGRP-2101
> URL: https://issues.jboss.org/browse/JGRP-2101
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> This protocol should be placed at the top of the stack. It measure delivery times:
> * Average times for single messages to get delivered. This returns when {{receive()}} returns
> * Average times for message batches: the delivery time is computed as time to deliver the batch divided by batch size
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months