[JBoss JIRA] (WFCORE-2342) CLI can't connect to DC on native port without defined remote protocol
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2342?page=com.atlassian.jira.plugi... ]
Ken Wills moved JBEAP-9197 to WFCORE-2342:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2342 (was: JBEAP-9197)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Remoting
Security
(was: CLI)
(was: Remoting)
(was: Security)
Affects Version/s: (was: 7.1.0.DR12)
Affects Testing: (was: Regression)
> CLI can't connect to DC on native port without defined remote protocol
> ----------------------------------------------------------------------
>
> Key: WFCORE-2342
> URL: https://issues.jboss.org/browse/WFCORE-2342
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Remoting, Security
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Blocker
> Labels: cli, regression, remoting, ssl
>
> CLI is able to connect to DC to native port (9999) only when protocol _remote_ is specified. It is regression, EAP 7.0.0.GA is able to connect when no protocol is defined or with _remoting_ and _remote_ (maybe some others).
> EAP 7.0.0.GA
> {noformat}
> msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> {noformat}
> EAP 7.1.0.DR12
> {noformat}
> msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999
> Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999
> msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999
> Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999
> msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999
> [domain@127.0.0.1:9999 /] quit
> {noformat}
> Stacktrace from attached jboss-cli.log
> {noformat}
> 15:46:26,184 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
> at org.xnio.ssl.JsseStreamConduit.performIO(JsseStreamConduit.java:1364)
> at org.xnio.ssl.JsseStreamConduit.read(JsseStreamConduit.java:991)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123)
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:165)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:160)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:446)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2217:
-------------------------------------
Fix Version/s: 4.0.0.Alpha1
(was: 4.0.0.Beta1)
(was: 3.0.0.Beta7)
[~kabirkhan] I'm removing this from the 3.0.0 schedule, as it seems complex and risky but not critical. If I'm wrong about that please reschedule.
> ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2217
> URL: https://issues.jboss.org/browse/WFCORE-2217
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha16
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... does not get called.
> The fix is quite simple:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
> }
>
> resultAction = postExtContext.executeOperation();
> + }
>
> - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> - Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> - Resource root = managementModel.get().getRootResource();
> - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> - extraValidationStepHandler, partialModel, securityIdentitySupplier);
> - validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> - resultAction = validateContext.executeOperation();
> - }
> + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> + Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> + Resource root = managementModel.get().getRootResource();
> + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> + extraValidationStepHandler, partialModel, securityIdentitySupplier);
> + validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> + resultAction = validateContext.executeOperation();
> }
>
> return resultAction == OperationContext.ResultAction.KEEP;
> {code}
> but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full.
> I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives.
> For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
> }
>
> resultAction = postExtContext.executeOperation();
> + }
>
> - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> - Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> - Resource root = managementModel.get().getRootResource();
> - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> - extraValidationStepHandler, partialModel, securityIdentitySupplier);
> - validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> - resultAction = validateContext.executeOperation();
> - }
> + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> + Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> + Resource root = managementModel.get().getRootResource();
> + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> + extraValidationStepHandler, partialModel, securityIdentitySupplier);
> + validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> + resultAction = validateContext.executeOperation();
> }
>
> return resultAction == OperationContext.ResultAction.KEEP;
> {code}
> So although the fix is simple, the fallout of this is quite big.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1958:
------------------------------------------
Besides the one remaining test, I have no idea what this was about. :) I just reenabled a bunch of ignored tests because they pass and are needed to guard against regressions. But there may very well be some work that was meant to happen that still needs to happen.
> Clean up testsuite Elytron registration
> ---------------------------------------
>
> Key: WFCORE-1958
> URL: https://issues.jboss.org/browse/WFCORE-1958
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta7
>
>
> In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them..
> Also re-enable the following test case: -
> * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-107:
------------------------------------
Fix Version/s: (was: 3.0.0.Beta7)
> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
> Key: WFCORE-107
> URL: https://issues.jboss.org/browse/WFCORE-107
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-107:
-----------------------------------------
Agreed, this is not easily accessible yet.
> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
> Key: WFCORE-107
> URL: https://issues.jboss.org/browse/WFCORE-107
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-107:
-----------------------------------------
[~dlofthouse] I think this needs to be unscheduled or moved to 4.0.0.Beta1.
> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
> Key: WFCORE-107
> URL: https://issues.jboss.org/browse/WFCORE-107
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta7
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 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: 4.0.0.Alpha1
(was: 3.0.0.Beta7)
> 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
>
> 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
(v7.2.3#72005)
7 years, 2 months