[JBoss JIRA] (DROOLS-2129) Lock the rule validation button
by Petr Farmakovsky (JIRA)
Petr Farmakovsky created DROOLS-2129:
----------------------------------------
Summary: Lock the rule validation button
Key: DROOLS-2129
URL: https://issues.jboss.org/browse/DROOLS-2129
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.5.0.Final
Reporter: Petr Farmakovsky
Assignee: Edson Tirelli
Our business users often use rules with a large number of lines. After saving, they validate the rules. Due to large size of rules, the validation process takes a lot of time. The validation button in the Drools interface is not blocked, so users have time to press it 5-10 times before receiving a response. In this case, the server does not manage to process such a large number of requests due to lack of resources.
We learned how to diagnose a lack of resources and tried to restart the server. However, the javascript that performs the validation continues to load the server after the restart. Therefore, the only way that helps us with a lack of resources is to stop the tomcat server, and start it in a few minutes.
Can you make a lock the rule validation button when it is in process?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3406) find-non-progressing-operation doesn't return the blocking operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3406?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3406:
------------------------------------------
It sounds like this one should be Rejected, since it works. Using it to track a TS enhancement that proves it works is fine, but it looks like doing that enhancement isn't trivial. If you decide to keep it open please change it to an Enhancement and change the description so it's described as a TS enhancement and not something broken.
> find-non-progressing-operation doesn't return the blocking operation
> --------------------------------------------------------------------
>
> Key: WFCORE-3406
> URL: https://issues.jboss.org/browse/WFCORE-3406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Chao Wang
> Attachments: helloworld.war
>
>
> The find-non-progressing-operation operation of /core-service=management/service=management-operations doesn't return the operation id of a blocking operation on standalone. It works on domain mode.
> To simulate the blocking operation, install the BlockingExtension from testsuite and call
> {code}
> /subsystem=blocker-test:block(block-point=MODEL,block-time=50000}
> {code}
> Open another jboss-cli.sh and call
> {code}
> /core-service=management/service=management-operations:find-non-progressing-operation
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3185:
-------------------------------------
Description:
Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
-Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.-
Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
was:
Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
> Run parallel boot tasks in coarser grained chunks
> -------------------------------------------------
>
> Key: WFCORE-3185
> URL: https://issues.jboss.org/browse/WFCORE-3185
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
> The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
> My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
> The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
> Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
> -Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.-
> Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3185:
-------------------------------------
Fix Version/s: (was: 4.0.0.Alpha3)
> Run parallel boot tasks in coarser grained chunks
> -------------------------------------------------
>
> Key: WFCORE-3185
> URL: https://issues.jboss.org/browse/WFCORE-3185
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
> The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
> My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
> The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
> Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
> Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
> Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3185:
-------------------------------------
Comment: was deleted
(was: https://github.com/wildfly/wildfly-core/compare/master...bstansberry:par-... shows the work on this.)
> Run parallel boot tasks in coarser grained chunks
> -------------------------------------------------
>
> Key: WFCORE-3185
> URL: https://issues.jboss.org/browse/WFCORE-3185
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
> The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
> My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
> The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
> Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
> Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
> Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9552) Enable JBTM-2955
by Tom Jenkinson (JIRA)
Tom Jenkinson created WFLY-9552:
-----------------------------------
Summary: Enable JBTM-2955
Key: WFLY-9552
URL: https://issues.jboss.org/browse/WFLY-9552
Project: WildFly
Issue Type: Enhancement
Components: Transactions
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 12.0.0.Alpha1
Enable the new SubordinationManager orphan detection check added in JBTM-2955
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest mapper
by Martin Choma (JIRA)
Martin Choma created ELY-1444:
---------------------------------
Summary: Jdbc-realm with simple digest mapper
Key: ELY-1444
URL: https://issues.jboss.org/browse/ELY-1444
Project: WildFly Elytron
Issue Type: Bug
Components: Passwords
Affects Versions: 1.2.0.Beta9
Reporter: Martin Choma
This is inspired by ELY-1435, but in this case trying simple digest hash.
In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
I get these values by http://passwordsgenerator.net/sha256-hash-generator/
{noformat}
17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser].
17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm]
17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser
17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser
17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed.
17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9551) Ability to add Properties binding in Naming subsystem
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-9551:
----------------------------------
Summary: Ability to add Properties binding in Naming subsystem
Key: WFLY-9551
URL: https://issues.jboss.org/browse/WFLY-9551
Project: WildFly
Issue Type: Feature Request
Components: Naming
Affects Versions: 11.0.0.Final
Reporter: Brad Maxwell
Priority: Minor
Something like this whee multiple properties can be specified and then looked up as a java.util.Properties object:
{code}
Properties properties = (Properties) new InitialContext().lookup("java:global/myProperties");
{code}
{code}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<properties name="java:global/myProperties">
<property name="environment" value="production"/>
<property name="size" value="100"/>
...
</properties>
</bindings>
</subsystem>
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (ELY-1443) Jdbc-realm with scram mapper
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1443?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1443:
------------------------------
Description:
This is follow up on ELY-1435, but in this case trying scram hash.
Salt: c2FsdA==
Password: YywoEuRtRgQQK6dhjp1tfS+BKPYma0oDJk0qBGC33LM=
Salt: 1000
I get these values by
{code:java|name=ScramDigestPasswordTest.java}
digest = ScramDigestPasswordImpl.scramDigest(ALGORITHM_SCRAM_SHA_256, "password".getBytes(StandardCharsets.UTF_8), "salt".getBytes(StandardCharsets.UTF_8), 1000);
assertEquals("632c2812e46d4604102ba7618e9d6d7d2f8128f6266b4a03264d2a0460b7dcb3", ByteIterator.ofBytes(digest).hexEncode().drainToString());
spec = new IteratedSaltedHashPasswordSpec(digest, "salt".getBytes(StandardCharsets.UTF_8), 1000);
impl = new ScramDigestPasswordImpl(ALGORITHM_SCRAM_SHA_256, spec);
assertTrue(impl.verify("password".toCharArray()));
assertFalse(impl.verify("bad".toCharArray()));
Encoder encoder = Base64.getEncoder();
String elytronSalt = encoder.encodeToString( impl.getSalt() );
String elytronHash = encoder.encodeToString( impl.getDigest() );
int itertationCount = impl.getIterationCount();
{code}
{noformat}
17:05:40,723 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
17:05:40,723 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
17:05:40,727 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
17:05:40,813 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
17:05:40,817 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
17:05:40,865 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /elytron-app/protected/printRoles: java.lang.IllegalArgumentException: Empty key
at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:96)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.getMacInstance(ScramDigestPasswordImpl.java:281)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.scramDigest(ScramDigestPasswordImpl.java:240)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.verify(ScramDigestPasswordImpl.java:195)
at org.wildfly.security.password.impl.PasswordFactorySpiImpl.engineVerify(PasswordFactorySpiImpl.java:755)
at org.wildfly.security.password.PasswordFactory.verify(PasswordFactory.java:209)
at org.wildfly.security.credential.PasswordCredential.verify(PasswordCredential.java:116)
at org.wildfly.security.credential.Credential.verify(Credential.java:79)
at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.verifyEvidence(JdbcSecurityRealm.java:199)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1052)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:76)
at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
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)
{noformat}
was:
This is follow up on ELY-1435, but in this case trying scram hash.
Salt: c2FsdA==
Password: YywoEuRtRgQQK6dhjp1tfS+BKPYma0oDJk0qBGC33LM=
Salt: 1000
I get these values by
{code}
digest = ScramDigestPasswordImpl.scramDigest(ALGORITHM_SCRAM_SHA_256, "password".getBytes(StandardCharsets.UTF_8), "salt".getBytes(StandardCharsets.UTF_8), 1000);
assertEquals("632c2812e46d4604102ba7618e9d6d7d2f8128f6266b4a03264d2a0460b7dcb3", ByteIterator.ofBytes(digest).hexEncode().drainToString());
spec = new IteratedSaltedHashPasswordSpec(digest, "salt".getBytes(StandardCharsets.UTF_8), 1000);
impl = new ScramDigestPasswordImpl(ALGORITHM_SCRAM_SHA_256, spec);
assertTrue(impl.verify("password".toCharArray()));
assertFalse(impl.verify("bad".toCharArray()));
Encoder encoder = Base64.getEncoder();
String elytronSalt = encoder.encodeToString( impl.getSalt() );
String elytronHash = encoder.encodeToString( impl.getDigest() );
int itertationCount = impl.getIterationCount();
{code}
{noformat}
17:05:40,723 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
17:05:40,723 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
17:05:40,727 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
17:05:40,813 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
17:05:40,817 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
17:05:40,865 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /elytron-app/protected/printRoles: java.lang.IllegalArgumentException: Empty key
at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:96)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.getMacInstance(ScramDigestPasswordImpl.java:281)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.scramDigest(ScramDigestPasswordImpl.java:240)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.verify(ScramDigestPasswordImpl.java:195)
at org.wildfly.security.password.impl.PasswordFactorySpiImpl.engineVerify(PasswordFactorySpiImpl.java:755)
at org.wildfly.security.password.PasswordFactory.verify(PasswordFactory.java:209)
at org.wildfly.security.credential.PasswordCredential.verify(PasswordCredential.java:116)
at org.wildfly.security.credential.Credential.verify(Credential.java:79)
at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.verifyEvidence(JdbcSecurityRealm.java:199)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1052)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:76)
at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
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)
{noformat}
> Jdbc-realm with scram mapper
> ----------------------------
>
> Key: ELY-1443
> URL: https://issues.jboss.org/browse/ELY-1443
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Passwords
> Affects Versions: 1.2.0.Beta9
> Reporter: Martin Choma
>
> This is follow up on ELY-1435, but in this case trying scram hash.
> Salt: c2FsdA==
> Password: YywoEuRtRgQQK6dhjp1tfS+BKPYma0oDJk0qBGC33LM=
> Salt: 1000
> I get these values by
> {code:java|name=ScramDigestPasswordTest.java}
> digest = ScramDigestPasswordImpl.scramDigest(ALGORITHM_SCRAM_SHA_256, "password".getBytes(StandardCharsets.UTF_8), "salt".getBytes(StandardCharsets.UTF_8), 1000);
> assertEquals("632c2812e46d4604102ba7618e9d6d7d2f8128f6266b4a03264d2a0460b7dcb3", ByteIterator.ofBytes(digest).hexEncode().drainToString());
> spec = new IteratedSaltedHashPasswordSpec(digest, "salt".getBytes(StandardCharsets.UTF_8), 1000);
> impl = new ScramDigestPasswordImpl(ALGORITHM_SCRAM_SHA_256, spec);
> assertTrue(impl.verify("password".toCharArray()));
> assertFalse(impl.verify("bad".toCharArray()));
> Encoder encoder = Base64.getEncoder();
> String elytronSalt = encoder.encodeToString( impl.getSalt() );
> String elytronHash = encoder.encodeToString( impl.getDigest() );
> int itertationCount = impl.getIterationCount();
> {code}
> {noformat}
> 17:05:40,723 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
> 17:05:40,723 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
> 17:05:40,727 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
> 17:05:40,813 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
> 17:05:40,817 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
> 17:05:40,865 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /elytron-app/protected/printRoles: java.lang.IllegalArgumentException: Empty key
> at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:96)
> at org.wildfly.security.password.impl.ScramDigestPasswordImpl.getMacInstance(ScramDigestPasswordImpl.java:281)
> at org.wildfly.security.password.impl.ScramDigestPasswordImpl.scramDigest(ScramDigestPasswordImpl.java:240)
> at org.wildfly.security.password.impl.ScramDigestPasswordImpl.verify(ScramDigestPasswordImpl.java:195)
> at org.wildfly.security.password.impl.PasswordFactorySpiImpl.engineVerify(PasswordFactorySpiImpl.java:755)
> at org.wildfly.security.password.PasswordFactory.verify(PasswordFactory.java:209)
> at org.wildfly.security.credential.PasswordCredential.verify(PasswordCredential.java:116)
> at org.wildfly.security.credential.Credential.verify(Credential.java:79)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.verifyEvidence(JdbcSecurityRealm.java:199)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1052)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:76)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months