[JBoss JIRA] (WFCORE-610) Integrate Elytron for management security.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-610:
------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 2.0.0.Alpha9)
> Integrate Elytron for management security.
> ------------------------------------------
>
> Key: WFCORE-610
> URL: https://issues.jboss.org/browse/WFCORE-610
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta1
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)). However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-263:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.Alpha9)
> Cancelling management op on slave HC tree is broken
> ---------------------------------------------------
>
> Key: WFCORE-263
> URL: https://issues.jboss.org/browse/WFCORE-263
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: James Livingston
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
> Attachments: unundeployable.zip
>
>
> If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via:
> /host=master/core-service=management/service=management-operations:find-non-progressing-operation
> /host=slave/core-service=management/service=management-operations:find-non-progressing-operation
> Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again.
> If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive.
> Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled.
> Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in bin
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-25?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-25:
----------------------------------------
Where does this stand? I scheduled for CR1 as Alpha9 is clearly incorrect.
> Windows PowerShell scripts in bin
> ---------------------------------
>
> Key: WFCORE-25
> URL: https://issues.jboss.org/browse/WFCORE-25
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.CR1
>
>
> Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-278) Revisit error message for an authentication failure.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-278?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-278:
------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Alpha9)
> Revisit error message for an authentication failure.
> ----------------------------------------------------
>
> Key: WFCORE-278
> URL: https://issues.jboss.org/browse/WFCORE-278
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 2.0.0.CR1
>
>
> After authentication fails in the CLI the following error message is output: -
> {code}
> Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms
> {code}
> This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-266:
------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 2.0.0.Alpha9)
> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-266
> URL: https://issues.jboss.org/browse/WFCORE-266
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Beta1
>
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-683) ListModuleRootsHandler and ModuleLocationHandler don't handle PrivilegedActionException properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-683?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-683:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.Alpha9)
> ListModuleRootsHandler and ModuleLocationHandler don't handle PrivilegedActionException properly
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-683
> URL: https://issues.jboss.org/browse/WFCORE-683
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.CR1
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> The two inner class OSHs in ModuleLoadingResourceDefinition don't deal with exceptions properly. They invoke AccessController.doPrivileged and then deal with any PrivilegedActionException by rethrowing as OperationFailedException.
> OperationFailedException represents a client mistake and is handled as such (e.g. isn't logged in the server log.) It shouldn't be thrown here unless the PrivilegedActionException.getCause() value is itself an OFE. Otherwise, the OSHs should throw a RuntimeException.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months