[ openjms-Bugs-1109259 ] Applet client connection to firewalled server

Bugs item #1109259, was opened at 2005-01-26 05:06
Message generated for change (Comment added) made by tanderson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1109259&group_id=54559

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: client
Group: v0.7.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ken Melms (whitegold)
>Assigned to: Tim Anderson (tanderson)
Summary: Applet client connection to firewalled server 

Initial Comment:
When an unsigned Applet attempts to connect to a server
that has been configured to be behind a Firewall (NAT
or Port Forwarding) and the
TcpConfiguration:internalHost attribute is used - any
client connection attempt from INSIDE the firewall
fails with:

SEVERE: Can not create TopicConnection.
javax.jms.JMSException: Failed to create connection:
java.security.AccessControlException: access denied
(java.net.SocketPermission 172.18.XX.XX:3030
connect,resolve)
    at
org.exolab.jms.client.mipc.IpcJmsServerStub.openConnection(IpcJmsServerStub.java:338)
    at
org.exolab.jms.client.mipc.IpcJmsServerStub.createConnection(IpcJmsServerStub.java:197)
    at
org.exolab.jms.client.JmsConnection.<init>(JmsConnection.java:189)
    at
org.exolab.jms.client.JmsTopicConnection.<init>(JmsTopicConnection.java:81)
    at
org.exolab.jms.client.JmsTopicConnectionFactory.createTopicConnection(JmsTopicConnectionFactory.java:113)
    at
org.exolab.jms.client.JmsTopicConnectionFactory.createTopicConnection(JmsTopicConnectionFactory.java:10


The root cause is that an unsigned Applet may only make
socket connections to the server it came from -
otherwise an AccessControlException is raised.  

org.exolab.jms.client.mipc.IpcJmsServerStub.openConnection()
only tests for "IOException" before trying the fallback
internalHost ip address - and thus the exception
bubbles up and the fallback is never used.

The solution I successfully found was to modify the
catch() clause to catch "Exception" and then attempt
the fallback 'internalHost' regardless of the cause.



----------------------------------------------------------------------

>Comment By: Tim Anderson (tanderson)
Date: 2005-12-02 23:17

Message:
Logged In: YES 
user_id=557161

Fixed in CVS. Fix will be available in 0.7.7-alpha-2

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1109259&group_id=54559


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click