[JBoss JIRA] (WFCORE-2878) CLI autocompletion can't handle empty {}
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2878?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise moved JBEAP-11168 to WFCORE-2878:
------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2878 (was: JBEAP-11168)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.DR18)
> CLI autocompletion can't handle empty {}
> ----------------------------------------
>
> Key: WFCORE-2878
> URL: https://issues.jboss.org/browse/WFCORE-2878
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> CLI autocompletion can't handle empty {}
> *Steps to Reproduce:*
> # embed-server
> # /subsystem=elytron/token-realm=JwtRealm:add(jwt={}<TAB><TAB><TAB><TAB><TAB>
> *Actual results:*
> /subsystem=elytron/token-realm=JwtRealm:add(jwt={}}}}}}
> *Expected results:*
> /subsystem=elytron/token-realm=JwtRealm:add(jwt={}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2877) The add-user script doesn't prompt when updating a user
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2877?page=com.atlassian.jira.plugi... ]
Jan Kalina moved JBEAP-11166 to WFCORE-2877:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2877 (was: JBEAP-11166)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Security)
> The add-user script doesn't prompt when updating a user
> -------------------------------------------------------
>
> Key: WFCORE-2877
> URL: https://issues.jboss.org/browse/WFCORE-2877
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> The add-user script is not prompting when entering a username that already exists (to update a user). It automatically overwrites the existing user information. This is what I see when I enter the username "test", which already exists:
> {code}
> [ahoffer@ahoffer bin] $ ./add-user.sh
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a):
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : test
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> {code}
> Before I get asked for a password, I should see the following prompt for this existing user:
> {code}
> User 'test' already exists and is enabled, would you like to...
> a) Update the existing user password and roles
> b) Disable the existing user
> c) Type a new username
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (ELY-1205) Wildfly Elytron Tool, Wildfly Elytron Tool error output would contain error message rather than stacktrace.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1205:
---------------------------------
Summary: Wildfly Elytron Tool, Wildfly Elytron Tool error output would contain error message rather than stacktrace.
Key: ELY-1205
URL: https://issues.jboss.org/browse/ELY-1205
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Blocker
Wildfly Elytron Tool error output would contain error message rather than stacktrace.
I understand that it is very useful but the behaviour must be consistent with other apps, e.g.: jboss-cli.
Now we have inconsistency even in this tool - half exceptions, half error messages.
Here is example
{code}
java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret secretpassword --location="test.store1" --password secret_password --summary --salt 12345678 --iteration 230 --create -type=KeyStoreCredentialStore123
Exception encountered executing the command:
java.security.NoSuchAlgorithmException
at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:65)
at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:157)
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:75)
{code}
I suggest add application parameter \-\-verbose (\-\-debug, ...) which enables print stack trace when error occurs.
By default there is expected only error message and with this parameter there will be printed stack trace.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (ELY-1131) WildFly Elytron Tool, For vault command bulk-convert is missing validation for parsed values from description file.
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/ELY-1131?page=com.atlassian.jira.plugin.s... ]
Ingo Weiss reassigned ELY-1131:
-------------------------------
Assignee: Ingo Weiss (was: Darran Lofthouse)
> WildFly Elytron Tool, For vault command bulk-convert is missing validation for parsed values from description file.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1131
> URL: https://issues.jboss.org/browse/ELY-1131
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ingo Weiss
>
> For vault command bulk-convert is missing validation for parsed values from description file.
> There is expected to have some kind of validation for parsed value. There must be defined which values are required and which not.
> There are these problems with required arguments:
> # omitting "alias" leads to NullPointerException
> # omitting "location" leads to incorrect tool output where is "null" value as credential store, converted file isn't created but it seems that operation was successful.
> {code}
> java -jar wildfly-elytron-tool.jar vault --bulk-convert bulk-vault-conversion-desc
> Vault (enc-dir="./test";keystore="server.store") converted to credential store "null"
> {code}
> # omitting "enc-dir" leads to incorrect tool output where is "null" value for "enc-dir" and there is created empty converted.jceks file in current directory.
> {code}
> java -jar wildfly-elytron-tool.jar vault --bulk-convert bulk-vault-conversion-desc
> Vault (enc-dir="null";keystore="server.store") converted to credential store "converted.jceks"
> {code}
> * there are more choices how to solve it:
> ## error message, because each VAULT in description file should have different value.
> ## set it to current directory
> ## other solution
> # omitting "keystore-password" leads to NullPointerException
> * There is expected better error message.
> # There must be defined at least one "keystore", because it is separator between
> *How to reproduce*
> Download all attachments to same location as wildfly-elytron-tool.jar update *bulk-vault-conversion-desc* file and run this command
> java -jar wildfly-elytron-tool.jar vault --bulk-convert bulk-vault-conversion-desc
> Here is example of correctly defined one vault store for convert in description file
> {code}
> # Bulk conversion descriptor
> keystore:server.store
> keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
> enc-dir:./test
> salt:12345678
> iteration:34
> location:converted.jceks
> alias:jboss
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Arkady Syamtomov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1386?page=com.atlassian.jira.plugi... ]
Arkady Syamtomov commented on DROOLS-1386:
------------------------------------------
[~mfusco] thanks for your comment. We are already working on adding the test case to the application I used to reproduce the ProjectClassLoader problem. I'll reopen the ticket or just create the new one once we are done.
Thanks again for having followed this up.
A dopo
> NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
> --------------------------------------------------------
>
> Key: DROOLS-1386
> URL: https://issues.jboss.org/browse/DROOLS-1386
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final, 7.0.0.Beta4
> Reporter: Arkady Syamtomov
> Assignee: Mario Fusco
> Priority: Critical
>
> In our integration tests which were perfectly running with drools 6.3.0.Final, now we have failures with the following exception during the rules evaluation:
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowRemoved(QueryElementNode.java:444) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftDeletes(PhreakQueryTerminalNode.java:154) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:46) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1364) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1355) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1346) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (ELY-1186) Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1186?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1186:
---------------------------------------
I think it is in one of the RFCs if you have no real assume the server name - but we do need to fix with with Elytron as I think we should be able to avoid that.
> Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side
> ---------------------------------------------------------------------------------------------------------
>
> Key: ELY-1186
> URL: https://issues.jboss.org/browse/ELY-1186
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> When a default configuration is used for DIGEST-MD5 SASL mechanism, then server suggest hostname as a realm name, but authentication fails because ServerAuthenticationContext checks mechanism configuration and fails with following exception:
> {code}
> @Message(id = 1092, value = "Invalid mechanism realm selection \"%s\"")
> IllegalArgumentException invalidMechRealmSelection(String realmName);
> {code}
> *Suggested fix:*
> If the server suggests realm name, then it should be able to consume it. Or if the realm name is really mandatory, then server should not suggest such a default value. IMO allowing such a default and simplifying configuration would have positive impact on user experience.
> The full stacktrace (hidden):
> {noformat}
> javax.security.sasl.SaslException: ELY05053: [DIGEST-MD5] Callback handler failed for unknown reason [Caused by java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"]
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:105)
> at org.wildfly.security.sasl.digest.AbstractDigestMechanism.getPredigestedSaltedPassword(AbstractDigestMechanism.java:482)
> at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:259)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:470)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897)
> 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:748)
> Caused by: java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"
> at org.wildfly.security.auth.server.ServerAuthenticationContext$InitialState.setMechanismRealmName(ServerAuthenticationContext.java:1615)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setMechanismRealmName(ServerAuthenticationContext.java:712)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:927)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:101)
> ... 15 more
> {noformat}
> Attached also server configuration and WireShark log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month