[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4376:
-----------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 901248|https://bugzilla.redhat.com/show_bug.cgi?id=901248] from ASSIGNED to CLOSED
> Incorrect callback handler used during authentication (SASL)
> -------------------------------------------------------------
>
> Key: WFLY-4376
> URL: https://issues.jboss.org/browse/WFLY-4376
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
> Fix For: 10.0.0.CR5
>
>
> Cluster topology messages are not using the proper callbackhandler when the connection is being established.
> {code}
> 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
> ... 7 more
> {code}
> Before that, this log is produced:
> {code}
> DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7851) Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-7851:
------------------------------------
Summary: Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
Key: WFLY-7851
URL: https://issues.jboss.org/browse/WFLY-7851
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Environment: Wildfly 10.1.0.Final
Reporter: Kálmán Szalai
Assignee: Stuart Douglas
Priority: Minor
Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final. I saw WildFly 2.2.0.Final is the Wildfly Core version.
Additionally the admin interfacde shows:
Product name: WildFly Full
Product version: 10.1.0.Final
Profile: COMMUNITY
HAL version: 2.8.27.Final
Core version: 2.8.27.Final
Wildfly 8 is produced Wildfly 8 version sting on getServerInfo() call.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1394) Use Maven for compiling the workbench projects
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1394?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1394:
----------------------------------
Affects Version/s: 7.0.0.Beta5
6.5.0.Final
> Use Maven for compiling the workbench projects
> ----------------------------------------------
>
> Key: DROOLS-1394
> URL: https://issues.jboss.org/browse/DROOLS-1394
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.5.0.Final, 7.0.0.Beta5
> Reporter: Toni Rikkola
> Assignee: Mario Fusco
>
> We currently use the kie-maven-plugin internally to compile the kjar's and only use Maven to provide the information about parent projects and dependencies for the project.
> Yet we have the power of Maven underneath and we do not use it. It is impossible to use simple features like ignoring folders or moving code. Or more complicated, for example if you have your own rule asset format and need a Maven plugin to generate the DRL out of it.
> However it is possible to set this functionality up. This causes problems:
> * Same git tag built in the workbench produce different results depending on the Workbench version that is being used. This means that if you want to rebuild a lost kjar, you need to install the same workbench version that was originally used to create the first one
> * Projects build in command line/build server can produce different kjars than the ones built with the workbench
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1394) Use Maven for compiling the workbench projects
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1394?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1394:
---------------------------------------
[~Rikkola] sorry, I am confused. Does this change need to be done in the workbench or in core?
> Use Maven for compiling the workbench projects
> ----------------------------------------------
>
> Key: DROOLS-1394
> URL: https://issues.jboss.org/browse/DROOLS-1394
> Project: Drools
> Issue Type: Feature Request
> Reporter: Toni Rikkola
> Assignee: Edson Tirelli
>
> We currently use the kie-maven-plugin internally to compile the kjar's and only use Maven to provide the information about parent projects and dependencies for the project.
> Yet we have the power of Maven underneath and we do not use it. It is impossible to use simple features like ignoring folders or moving code. Or more complicated, for example if you have your own rule asset format and need a Maven plugin to generate the DRL out of it.
> However it is possible to set this functionality up. This causes problems:
> * Same git tag built in the workbench produce different results depending on the Workbench version that is being used. This means that if you want to rebuild a lost kjar, you need to install the same workbench version that was originally used to create the first one
> * Projects build in command line/build server can produce different kjars than the ones built with the workbench
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1394) Use Maven for compiling the workbench projects
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1394?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1394:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> Use Maven for compiling the workbench projects
> ----------------------------------------------
>
> Key: DROOLS-1394
> URL: https://issues.jboss.org/browse/DROOLS-1394
> Project: Drools
> Issue Type: Feature Request
> Reporter: Toni Rikkola
> Assignee: Mario Fusco
>
> We currently use the kie-maven-plugin internally to compile the kjar's and only use Maven to provide the information about parent projects and dependencies for the project.
> Yet we have the power of Maven underneath and we do not use it. It is impossible to use simple features like ignoring folders or moving code. Or more complicated, for example if you have your own rule asset format and need a Maven plugin to generate the DRL out of it.
> However it is possible to set this functionality up. This causes problems:
> * Same git tag built in the workbench produce different results depending on the Workbench version that is being used. This means that if you want to rebuild a lost kjar, you need to install the same workbench version that was originally used to create the first one
> * Projects build in command line/build server can produce different kjars than the ones built with the workbench
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1386?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1386:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> 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)
9 years, 5 months
[JBoss JIRA] (WFLY-7840) elytron: authentication-context validation errors
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7840?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7840:
----------------------------------
[~brian.stansberry] https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai...
> elytron: authentication-context validation errors
> -------------------------------------------------
>
> Key: WFLY-7840
> URL: https://issues.jboss.org/browse/WFLY-7840
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Jan Kalina
>
> elytron resource authentication-context has attribute match-rules marked as required=false and nillable=true, but fail to add an authentication-context with no match-rules attribute
> {code}
> /profile=default/subsystem=elytron/authentication-context=test123:add
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'match-rules' may not be null"},
> "rolled-back" => true
> }
> {code}
> Resource description snippet
> {code}
> "match-rules" => {
> "type" => LIST,
> "description" => "The match-rules for this authentication context.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7840) elytron: authentication-context validation errors
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7840?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7840:
----------------------------------------
[~honza889] Can you give me a github link to the relevant subsystem code where this attribute is configured?
> elytron: authentication-context validation errors
> -------------------------------------------------
>
> Key: WFLY-7840
> URL: https://issues.jboss.org/browse/WFLY-7840
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Jan Kalina
>
> elytron resource authentication-context has attribute match-rules marked as required=false and nillable=true, but fail to add an authentication-context with no match-rules attribute
> {code}
> /profile=default/subsystem=elytron/authentication-context=test123:add
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'match-rules' may not be null"},
> "rolled-back" => true
> }
> {code}
> Resource description snippet
> {code}
> "match-rules" => {
> "type" => LIST,
> "description" => "The match-rules for this authentication context.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months