[JBoss JIRA] (WFLY-8619) Incorrect IIOP security config validation
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-8619?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFLY-8619:
---------------------------------
Description:
In org.wildfly.iiop.openjdk.ConfigValidator.java:
{code}
if (supportSSL && !sslConfigured) {
throw IIOPLogger.ROOT_LOGGER.noSecurityDomainOrSSLContextsSpecified();
}
else if (serverRequiresSsl || clientRequiresSsl) {
// if either the server or the client requires SSL, then SSL support must have been enabled.
throw IIOPLogger.ROOT_LOGGER.sslNotConfigured();
}
{code}
Shouldn't go to second if if supporSSL is configured.
was:
In org.wildfly.iiop.openjdk.ConfigValidator.java:
{code}
if (supportSSL && !sslConfigured) {
throw IIOPLogger.ROOT_LOGGER.noSecurityDomainOrSSLContextsSpecified();
}
else if (serverRequiresSsl || clientRequiresSsl) {
// if either the server or the client requires SSL, then SSL support must have been enabled.
throw IIOPLogger.ROOT_LOGGER.sslNotConfigured();
}
{code}
Should go to second if if supporSSL is configured.
> Incorrect IIOP security config validation
> -----------------------------------------
>
> Key: WFLY-8619
> URL: https://issues.jboss.org/browse/WFLY-8619
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Blocker
>
> In org.wildfly.iiop.openjdk.ConfigValidator.java:
> {code}
> if (supportSSL && !sslConfigured) {
> throw IIOPLogger.ROOT_LOGGER.noSecurityDomainOrSSLContextsSpecified();
> }
> else if (serverRequiresSsl || clientRequiresSsl) {
> // if either the server or the client requires SSL, then SSL support must have been enabled.
> throw IIOPLogger.ROOT_LOGGER.sslNotConfigured();
> }
> {code}
> Shouldn't go to second if if supporSSL is configured.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2705) The default ModelControllerClient closes resources asynchronously could cause intermittent issues in consumers
by James Perkins (JIRA)
James Perkins created WFCORE-2705:
-------------------------------------
Summary: The default ModelControllerClient closes resources asynchronously could cause intermittent issues in consumers
Key: WFCORE-2705
URL: https://issues.jboss.org/browse/WFCORE-2705
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
The {{RemotingModelControllerClient}} closes some of it's resources asynchronously. This could cause issues consumers of the client that may attempt to change class loaders after the client is closed. The {{ModelControllerClient.close()}} should block until resources are closed.
Example stack trace from the wildfly-maven-plugin:
{code}
Exception in thread "Remoting "management-client" task-8" java.lang.NoClassDefFoundError: org/xnio/XnioWorker$2
at org.xnio.XnioWorker.shutDownTaskPool(XnioWorker.java:770)
at org.xnio.nio.NioXnioWorker.shutdown(NioXnioWorker.java:285)
at org.jboss.remoting3.EndpointImpl.finishPhase1(EndpointImpl.java:255)
at org.jboss.remoting3.EndpointImpl.closeTick1(EndpointImpl.java:238)
at org.jboss.remoting3.EndpointImpl.access$200(EndpointImpl.java:93)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.finishWork(EndpointImpl.java:835)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:822)
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)
Caused by: java.lang.ClassNotFoundException: org.xnio.XnioWorker$2
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 10 more
{code}
See WFMP-77 for more details on one place this error seemed intermittent.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2704) PersistentResourceXMLDescription should marshall default values by default
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2704:
----------------------------------------
Summary: PersistentResourceXMLDescription should marshall default values by default
Key: WFCORE-2704
URL: https://issues.jboss.org/browse/WFCORE-2704
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The WFCORE-836 fix didn't initialize marshalDefaultValues to true, so user-configured default values still aren't being persisted unless the subsystem author overrides the default behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7570) JBeret WildFly extension cannot handle runtime-name
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-7570?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7570:
-------------------------------------
Unfortunately there's not that can be done for anything under WildFly 11. WildFly 11.0.0.Alpha1 has been released though with this fix.
> JBeret WildFly extension cannot handle runtime-name
> ---------------------------------------------------
>
> Key: WFLY-7570
> URL: https://issues.jboss.org/browse/WFLY-7570
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 11.0.0.Alpha1
> Environment: Nightly build from 11th of November from here:
> https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
> java -version
> {noformat}
> java version "1.8.0_102"
> Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
> {noformat}
> Reporter: Markus Falk
> Assignee: James Perkins
> Fix For: 11.0.0.Alpha1
>
> Attachments: error.png
>
>
> A NullPointerException is thrown, when using a runtime-name for a batch job.
> Exception
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 13) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "batch-chunk-csv-database.war"),
> ("subsystem" => "batch-jberet"),
> ("job" => "myJob")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:68)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:988)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2691:
------------------------------------------
Thanks for starting that. :)
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7570) JBeret WildFly extension cannot handle runtime-name
by Robert Smith (JIRA)
[ https://issues.jboss.org/browse/WFLY-7570?page=com.atlassian.jira.plugin.... ]
Robert Smith edited comment on WFLY-7570 at 4/20/17 12:52 PM:
--------------------------------------------------------------
We are seeing this same error when we deploy in Wildfly 9.
We have found that it occurs if we change the name on deployment.
If we leave the name, it deploys ok.
I dont know if it matters, but in our case the job name matches the war name.
was (Author: rsmith1):
We are seeing this same error when we deploy in Wildfly 9.
We have found that it occurs if we change the name of the war on deployment.
If we leave the name, it deploys ok.
I dont know if it matters, but in our case the job name matches the war name.
> JBeret WildFly extension cannot handle runtime-name
> ---------------------------------------------------
>
> Key: WFLY-7570
> URL: https://issues.jboss.org/browse/WFLY-7570
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 11.0.0.Alpha1
> Environment: Nightly build from 11th of November from here:
> https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
> java -version
> {noformat}
> java version "1.8.0_102"
> Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
> {noformat}
> Reporter: Markus Falk
> Assignee: James Perkins
> Fix For: 11.0.0.Alpha1
>
> Attachments: error.png
>
>
> A NullPointerException is thrown, when using a runtime-name for a batch job.
> Exception
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 13) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "batch-chunk-csv-database.war"),
> ("subsystem" => "batch-jberet"),
> ("job" => "myJob")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:68)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:988)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7570) JBeret WildFly extension cannot handle runtime-name
by Robert Smith (JIRA)
[ https://issues.jboss.org/browse/WFLY-7570?page=com.atlassian.jira.plugin.... ]
Robert Smith commented on WFLY-7570:
------------------------------------
We are seeing this same error when we deploy in Wildfly 9.
We have found that it occurs if we change the name of the war on deployment.
If we leave the name, it deploys ok.
I dont know if it matters, but in our case the job name matches the war name.
> JBeret WildFly extension cannot handle runtime-name
> ---------------------------------------------------
>
> Key: WFLY-7570
> URL: https://issues.jboss.org/browse/WFLY-7570
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 11.0.0.Alpha1
> Environment: Nightly build from 11th of November from here:
> https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
> java -version
> {noformat}
> java version "1.8.0_102"
> Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
> {noformat}
> Reporter: Markus Falk
> Assignee: James Perkins
> Fix For: 11.0.0.Alpha1
>
> Attachments: error.png
>
>
> A NullPointerException is thrown, when using a runtime-name for a batch job.
> Exception
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 13) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "batch-chunk-csv-database.war"),
> ("subsystem" => "batch-jberet"),
> ("job" => "myJob")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:68)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:988)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-2691:
------------------------------------
The problem is not displaying placeholder - the problem is that children are obtained even when they are hidden behind the placeholder.
btw, maybe we can move to discussion at mailinglist as suggested?
started with subject "*read-resource (even with include-runtime=false) iterates over dynamic children*"
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2691:
------------------------------------------
The include-runtime=false does not help. JMX queries do not care about that. Plus even if we changed read-resource(include-runtime=false) to not show placeholders (which might be a bad idea; needs thought; and for sure is a potentially breaking change) it wouldn't help for a simple :read-resource
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months