[JBoss JIRA] (ELY-383) Update ServerAuthenticationContext to carry an identity from start to end
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-383?page=com.atlassian.jira.plugin.sy... ]
David Lloyd updated ELY-383:
----------------------------
Fix Version/s: (was: 1.1.0.Beta4)
> Update ServerAuthenticationContext to carry an identity from start to end
> -------------------------------------------------------------------------
>
> Key: ELY-383
> URL: https://issues.jboss.org/browse/ELY-383
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: David Lloyd
> Attachments: Blank Flowchart - ServerAuthenticationContext.png
>
>
> The {{ServerAuthenticationContext}} should capture the identity in force for its domain when it is constructed. Any authorization attempt should always apply to the current identity - either the captured identity, or whatever the last successfully authorized identity was in the context.
> The attached state diagram should accurately summarize how authorization identity flows through. Authentication identity is only available during the "NAME ASSIGNED" state; once authorization occurs, the authentication identity is no longer useful and is disposed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-4769:
-------------------------------------
No, it is not the server making a call to another server. It is a JNDI client making a call from outside a firewall to a server.
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6501) EJB with AroundConstruct interceptor with Object return type fails to deploy
by Dmitrii Tikhomirov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6501?page=com.atlassian.jira.plugin.... ]
Dmitrii Tikhomirov edited comment on WFLY-6501 at 4/19/16 11:27 AM:
--------------------------------------------------------------------
According to specs, @AroundConstruct must support two kinds of methods:
@AroundConstruct
public void <METHOD>(InvocationContext ctx) { ... }
@AroundConstruct
public Object <METHOD>(InvocationContext ctx) throws Exception { ... }
but for some reason, wildfly works only with the first one. That fix makes both of them acceptable. I am not sure about Class names in the test (AroundConstructWithReturnSLSB and AroundConstructInterceptorWithReturn ), maybe someone has better ideas ?
One more thing, Weld Validator writes to log :
WELD-001471: Interceptor method aroundConstruct defined on class ...AroundConstructInterceptorWithReturn
is not defined according to the specification. It should not throw java.lang.Exception, which is a checked exception.
If we need to fix this, I think we should create an additional issue, because it's in Weld.
was (Author: treblereel):
According to specs, @AroundConstruct must support two kinds of methods:
@AroundConstruct
public void <METHOD>(InvocationContext ctx) { ... }
@AroundConstruct
public Object <METHOD>(InvocationContext ctx) throws Exception { ... }
but for some reason, wildfly works only with the first one. That fix makes both of them acceptable. I am not sure about Class names in the test (AroundConstructWithReturnSLSB and AroundConstructInterceptorWithReturn ), maybe someone has better ideas ?
> EJB with AroundConstruct interceptor with Object return type fails to deploy
> ----------------------------------------------------------------------------
>
> Key: WFLY-6501
> URL: https://issues.jboss.org/browse/WFLY-6501
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Tomas Remes
> Assignee: Dmitrii Tikhomirov
> Attachments: myintercepter.tar.gz
>
>
> Having:
> {code}
> @Stateless
> @Interceptors(AroundConstructInterceptor.class)
> public class AroundConstructSLSB {
> ...
> }
> {code}
> and
> {code}
> public class AroundConstructInterceptor {
> public static volatile boolean intercepted = false;
> @AroundConstruct
> private Object aroundConstruct(InvocationContext ctx) throws Exception {
> intercepted = true;
> return ctx.proceed();
> }
> }
> {code}
> fails with following exception:
> {noformat}
> 08:18:55,464 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."bcc899ab-39cf-44dc-a2ba-e364d53091cc.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."bcc899ab-39cf-44dc-a2ba-e364d53091cc.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "bcc899ab-39cf-44dc-a2ba-e364d53091cc.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0024: Could not configure component AroundConstructSLSB
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:96)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0175: No method found with id: Method aroundConstruct(javax.interceptor.InvocationContext) on class (or its super class) class org.jboss.as.test.integration.ejb.interceptor.aroundconstruct.returnObject.AroundConstructInterceptor
> at org.jboss.as.server.deployment.reflect.ClassReflectionIndexUtil.findRequiredMethod(ClassReflectionIndexUtil.java:79)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator$1.handleInterceptorClass(DefaultInterceptorConfigurator.java:177)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator$1.handle(DefaultInterceptorConfigurator.java:158)
> at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator.configure(DefaultInterceptorConfigurator.java:188)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:82)
> ... 6 more
> {noformat}
> I cannot see any statement in Interceptor spec forbidding this. Testcase is available at https://github.com/tremes/wildfly/tree/intercept_ejb. I think the problem is class description having this method return type as void. I guess it occurs at first at https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6538) https-listener does not support proxy-address-forwarding
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6538?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6538:
-----------------------------------
[~swd847] Wdyt? would SSLHeaderHandler mess with existing SSL connection already at play? Or is it safe to use it also with https listener
> https-listener does not support proxy-address-forwarding
> --------------------------------------------------------
>
> Key: WFLY-6538
> URL: https://issues.jboss.org/browse/WFLY-6538
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Emond Papegaaij
> Assignee: Tomaz Cerar
>
> HttpsListenerService explicitly passes false to its superclass for proxyAddressForwarding and certificateForwarding, making it impossible to enable these features. For a security-sensitive application, we need a secure connection from our proxy to WildFly and we need WildFly to respect the headers sent by our proxy. It seems easy to support these options by reading them in HttpsListenerAdd and passing them to HttpsListenerService, which can simply pass them to the super constructor.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6501) EJB with AroundConstruct interceptor with Object return type fails to deploy
by Dmitrii Tikhomirov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6501?page=com.atlassian.jira.plugin.... ]
Dmitrii Tikhomirov commented on WFLY-6501:
------------------------------------------
According to specs, @AroundConstruct must support two kinds of methods:
@AroundConstruct
public void <METHOD>(InvocationContext ctx) { ... }
@AroundConstruct
public Object <METHOD>(InvocationContext ctx) throws Exception { ... }
but for some reason, wildfly works only with the first one. That fix makes both of them acceptable. I am not sure about Class names in the test (AroundConstructWithReturnSLSB and AroundConstructInterceptorWithReturn ), maybe someone has better ideas ?
> EJB with AroundConstruct interceptor with Object return type fails to deploy
> ----------------------------------------------------------------------------
>
> Key: WFLY-6501
> URL: https://issues.jboss.org/browse/WFLY-6501
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Tomas Remes
> Assignee: Dmitrii Tikhomirov
> Attachments: myintercepter.tar.gz
>
>
> Having:
> {code}
> @Stateless
> @Interceptors(AroundConstructInterceptor.class)
> public class AroundConstructSLSB {
> ...
> }
> {code}
> and
> {code}
> public class AroundConstructInterceptor {
> public static volatile boolean intercepted = false;
> @AroundConstruct
> private Object aroundConstruct(InvocationContext ctx) throws Exception {
> intercepted = true;
> return ctx.proceed();
> }
> }
> {code}
> fails with following exception:
> {noformat}
> 08:18:55,464 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."bcc899ab-39cf-44dc-a2ba-e364d53091cc.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."bcc899ab-39cf-44dc-a2ba-e364d53091cc.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "bcc899ab-39cf-44dc-a2ba-e364d53091cc.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0024: Could not configure component AroundConstructSLSB
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:96)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0175: No method found with id: Method aroundConstruct(javax.interceptor.InvocationContext) on class (or its super class) class org.jboss.as.test.integration.ejb.interceptor.aroundconstruct.returnObject.AroundConstructInterceptor
> at org.jboss.as.server.deployment.reflect.ClassReflectionIndexUtil.findRequiredMethod(ClassReflectionIndexUtil.java:79)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator$1.handleInterceptorClass(DefaultInterceptorConfigurator.java:177)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator$1.handle(DefaultInterceptorConfigurator.java:158)
> at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator.configure(DefaultInterceptorConfigurator.java:188)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:82)
> ... 6 more
> {noformat}
> I cannot see any statement in Interceptor spec forbidding this. Testcase is available at https://github.com/tremes/wildfly/tree/intercept_ejb. I think the problem is class description having this method return type as void. I guess it occurs at first at https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-4769 at 4/19/16 11:02 AM:
-------------------------------------------------------------
In that case, have you tried to define a remote-destination-outbound-socket-binding that correspond to the client side of the firewall?
{noformat}
<outbound-socket-binding name="natted-activemq">
<remote-destination host="xxx.xxx.xxx.xxx" port="8080"/>
</outbound-socket-binding>
{noformat}
and use it in the http-connector in place of the http socket-binding?
{noformat}
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="natted-activemq"/>
{noformat}
was (Author: jmesnil):
In that case, have you tried to define a remote-destination-outbound-socket-binding that correspond to the client side of the firewall?
{noformat}
<outbound-socket-binding name="natted-activemq">
<remote-destination host="xxx.xxx.xxx.xxx" port="8080"/>
</outbound-socket-binding>
{noformat}
and use it in the http-acceptor in place of the http socket-binding?
{noformat}
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="natted-activemq"/>
{noformat}
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-4769:
-----------------------------------
In that case, have you tried to define a remote-destination-outbound-socket-binding that correspond to the client side of the firewall?
{noformat}
<outbound-socket-binding name="natted-activemq">
<remote-destination host="xxx.xxx.xxx.xxx" port="8080"/>
</outbound-socket-binding>
{noformat}
and use it in the http-acceptor in place of the http socket-binding?
{noformat}
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="natted-activemq"/>
{noformat}
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6538) https-listener does not support proxy-address-forwarding
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/WFLY-6538?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij edited comment on WFLY-6538 at 4/19/16 10:58 AM:
-----------------------------------------------------------------
I think certificateForwarding can still be relevant, without it, you cannot use client-authentication behind a proxy when using https between your proxy and WildFly. Like this:
{noformat}
Client <-- https with client certificate --> proxy <-- https --> WildFly
{noformat}
IMHO, in a situation like this, it is still relevant to get the certificates used by the client to authenticate to your proxy.
was (Author: papegaaij):
I think certificateForwarding can still be relevant, without it, you cannot use client-authentication behind a proxy when using https between your proxy and WildFly. Like this:
{{Client <-- https with client certificate --> proxy <-- https --> WildFly}} IMHO, in a situation like this, it is still relevant to get the certificates used by the client to authenticate to your proxy.
> https-listener does not support proxy-address-forwarding
> --------------------------------------------------------
>
> Key: WFLY-6538
> URL: https://issues.jboss.org/browse/WFLY-6538
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Emond Papegaaij
> Assignee: Tomaz Cerar
>
> HttpsListenerService explicitly passes false to its superclass for proxyAddressForwarding and certificateForwarding, making it impossible to enable these features. For a security-sensitive application, we need a secure connection from our proxy to WildFly and we need WildFly to respect the headers sent by our proxy. It seems easy to support these options by reading them in HttpsListenerAdd and passing them to HttpsListenerService, which can simply pass them to the super constructor.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6538) https-listener does not support proxy-address-forwarding
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/WFLY-6538?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on WFLY-6538:
---------------------------------------
I think certificateForwarding can still be relevant, without it, you cannot use client-authentication behind a proxy when using https between your proxy and WildFly. Like this:
{{Client <-- https with client certificate --> proxy <-- https --> WildFly}} IMHO, in a situation like this, it is still relevant to get the certificates used by the client to authenticate to your proxy.
> https-listener does not support proxy-address-forwarding
> --------------------------------------------------------
>
> Key: WFLY-6538
> URL: https://issues.jboss.org/browse/WFLY-6538
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Emond Papegaaij
> Assignee: Tomaz Cerar
>
> HttpsListenerService explicitly passes false to its superclass for proxyAddressForwarding and certificateForwarding, making it impossible to enable these features. For a security-sensitive application, we need a secure connection from our proxy to WildFly and we need WildFly to respect the headers sent by our proxy. It seems easy to support these options by reading them in HttpsListenerAdd and passing them to HttpsListenerService, which can simply pass them to the super constructor.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-4769:
-------------------------------------
No, it doesn't. My settings are bound to the host IP, not the 127.0.0.1. And the issue is that when a connection factory lookup occurs across a NAT firewall, it give back the address of the machine, NOT the address used on the client side of the firewall, thus the lookup of the JNDI topic name fails. We have a workaround where we modify the connection factory host value. But I have seen several example of setting up the TransportConfiguration BEFORE making the lookup calls, so that the CF comes back with the correct host value, instead of us doing it in code with our workaround.
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years