[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:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 901248|https://bugzilla.redhat.com/show_bug.cgi?id=901248] from NEW to ASSIGNED
> Incorrect callback handler used during authentication (SASL)
> -------------------------------------------------------------
>
> Key: WFLY-4376
> URL: https://issues.jboss.org/browse/WFLY-4376
> Project: WildFly
> Issue Type: Bug
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
>
> 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
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Jonhny Jonhny (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Jonhny Jonhny commented on SECURITY-784:
----------------------------------------
I've already tried this way, but it is still not working.
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4423) ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4423?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-4423:
-------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/7252 (was: https://github.com/wildfly/wildfly/pull/create)
> ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
> ----------------------------------------------------------------------------
>
> Key: WFLY-4423
> URL: https://issues.jboss.org/browse/WFLY-4423
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> To reproduce this issue follow the steps:
> - setup JMS bridge between two WildFly instances
> - once JMS bridge is running, login into jboss-cli and stop the bridge
> - restart the bridge fro jboss-cli
> The following exception appears in the serve log file.
> 10:12:59,414 INFO [org.hornetq.jms.server] (pool-9-thread-1) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 60,000 ms
> 10:13:59,416 WARN [org.hornetq.jms.server] (pool-9-thread-1) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:126)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_75]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_75]
> at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55)
> at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1236)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1474)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2200(JMSBridgeImpl.java:79)
> at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2082)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_75]
> at java.lang.Class.forName(Class.java:274) [rt.jar:1.7.0_75]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:121)
> ... 17 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-608) Using ? as control character in .inputrc causes CLI to terminate immediately.
by Jay Kumar SenSharma (JIRA)
Jay Kumar SenSharma created WFCORE-608:
------------------------------------------
Summary: Using ? as control character in .inputrc causes CLI to terminate immediately.
Key: WFCORE-608
URL: https://issues.jboss.org/browse/WFCORE-608
Project: WildFly Core
Issue Type: Bug
Components: CLI
Environment: Linux
Reporter: Jay Kumar SenSharma
Assignee: Alexey Loubyansky
- When using *[wildfly-8.2.0.Final]* When user has a '.inputrc' in the user home directory with the following content:
{code}
# Control characters
"\C-?": backward-delete-char
{code}
- The it fails with the the following Stack Trace:
{code}
./jboss-cli.sh
java.lang.RuntimeException: ERROR parsing ? keys to aesh. Check your inputrc.
at org.jboss.aesh.edit.mapper.KeyMapper.convertRandomControlKeys(KeyMapper.java:161)
at org.jboss.aesh.edit.mapper.KeyMapper.mapRandomKeys(KeyMapper.java:138)
at org.jboss.aesh.edit.mapper.KeyMapper.mapKeys(KeyMapper.java:108)
at org.jboss.aesh.edit.mapper.KeyMapper.mapQuoteKeys(KeyMapper.java:49)
at org.jboss.aesh.console.Config.parseInputrc(Config.java:127)
at org.jboss.aesh.console.Console.reset(Console.java:150)
at org.jboss.aesh.console.Console.<init>(Console.java:105)
at org.jboss.aesh.console.Console.<init>(Console.java:101)
at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:85)
at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:78)
at org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole(CommandContextImpl.java:349)
at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:296)
at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:312)
at org.jboss.modules.Main.main(Main.java:460)
{code}
- Expectation is that CLI should not have terminated suddenly rather the exception should have been handled in a proper way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-608) Using ? as control character in .inputrc causes CLI to terminate immediately.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-608?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-608:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1203997
> Using ? as control character in .inputrc causes CLI to terminate immediately.
> ------------------------------------------------------------------------------
>
> Key: WFCORE-608
> URL: https://issues.jboss.org/browse/WFCORE-608
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: Linux
> Reporter: Jay Kumar SenSharma
> Assignee: Alexey Loubyansky
>
> - When using *[wildfly-8.2.0.Final]* When user has a '.inputrc' in the user home directory with the following content:
> {code}
> # Control characters
> "\C-?": backward-delete-char
> {code}
> - The it fails with the the following Stack Trace:
> {code}
> ./jboss-cli.sh
> java.lang.RuntimeException: ERROR parsing ? keys to aesh. Check your inputrc.
> at org.jboss.aesh.edit.mapper.KeyMapper.convertRandomControlKeys(KeyMapper.java:161)
> at org.jboss.aesh.edit.mapper.KeyMapper.mapRandomKeys(KeyMapper.java:138)
> at org.jboss.aesh.edit.mapper.KeyMapper.mapKeys(KeyMapper.java:108)
> at org.jboss.aesh.edit.mapper.KeyMapper.mapQuoteKeys(KeyMapper.java:49)
> at org.jboss.aesh.console.Config.parseInputrc(Config.java:127)
> at org.jboss.aesh.console.Console.reset(Console.java:150)
> at org.jboss.aesh.console.Console.<init>(Console.java:105)
> at org.jboss.aesh.console.Console.<init>(Console.java:101)
> at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:85)
> at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:78)
> at org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole(CommandContextImpl.java:349)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:296)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
> - Expectation is that CLI should not have terminated suddenly rather the exception should have been handled in a proper way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2429) Support JBeret JDBC job repository
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2429?page=com.atlassian.jira.plugin.... ]
Cheng Fang resolved WFLY-2429.
------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
> Support JBeret JDBC job repository
> ----------------------------------
>
> Key: WFLY-2429
> URL: https://issues.jboss.org/browse/WFLY-2429
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Cheng Fang
> Fix For: 8.0.0.Final
>
>
> At the moment, Wildfly only supports JBeret's InMemoryRepository. Some work already seems to have been done to support JDBC, because wildfly-batch_1_0.xsd mentions the jdbc repository. JBeret's JDBC repository has seem quite some development since the comment was added in the xsd. I think it's time to enable it in the configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2429) Support JBeret JDBC job repository
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2429?page=com.atlassian.jira.plugin.... ]
Cheng Fang reassigned WFLY-2429:
--------------------------------
Assignee: Cheng Fang
> Support JBeret JDBC job repository
> ----------------------------------
>
> Key: WFLY-2429
> URL: https://issues.jboss.org/browse/WFLY-2429
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Cheng Fang
>
> At the moment, Wildfly only supports JBeret's InMemoryRepository. Some work already seems to have been done to support JDBC, because wildfly-batch_1_0.xsd mentions the jdbc repository. JBeret's JDBC repository has seem quite some development since the comment was added in the xsd. I think it's time to enable it in the configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months