Make SocketReader more configurable

Openfire Openfire Dev
1

Hi all,

I’'ve got the following problem:

due to the “weird” flash sandbox and new firewalls you get with adsl accounts the connecting to the wildfire server on port 80 is difficult, flash actually needs a cross-domain-policy policy file hosted on the same server (dns name) loadanle with a http request or an xml socket request.

So i started looking into the way content switches could forward http request to server x and xmpp sockets to server y, but no luck there (for now)

anyway, if the SocketReader could be made “pluggabel” (or ClientSocketReader) and the method createSession split up in a few overridable methods I dont have to rewrite that class everytime there is a new release

thanx, bram

2

Bram,

Is there something that we could do to make better support for flash automatic? What port would the crossdomain.xml file need to be served on?

Regards,

Matt

3

Hi,

the xml is serverd on the same port as the socket, else you still have to use an port (either for serveing the crossdomain.xml or the jabber socket) that might be firewalled.

The safest assumption is that port 80 is available in most cases. The xml is then loaded using :

System.security.loadPolicyFile(“xmlsocket://socks.mysite.com:80”);

that sends a

request over a socket and after receiving the crossdomain.xml over the socket disconnects.

To be able to use this in Wildfire now i’‘ve hacked it into the SocketReader.createSession() method, but im pretty sure its not the place to put it. (i’'d like to make a FlashClientSocketReader that would take care of it and maybe even listen to a different port)

Anyways, looking somewhat further i’'ve also noticed that just telnetting to the server and typing some non whitespace text does not returns an error and disconnects me.

Regards.

Bram

ps

some docs about crossdomain.xml

http://www.macromedia.com/devnet/flash/articles/fplayer_security_03.html

4

So, it looks like we should serve up:

<?xml version="1.0"?>

In response to a request of on ports 5222 or 5223. It’'s a bit of a hack to our XMPP parsing code, but seems like the best option:

  1. It improves Flash support in Wildfire.

  2. No new ports to open in Wildfire or in the firewall since either 5222 or 5223 will obviously already be open.

What do you think? For Flash 7 or greater you’'d use the following code:

System.security.loadPolicyFile(“xmlsocket://example.com:5222”);

mySocket.connect(“exacmple.com”, 5222);

Regards,

Matt

5

Yep,

but then we can use the contentswitch to forward port 80 to 5222 on the wildfire server (still can get used to the new name)

anyway, an other option we are looking into is using a http header so the content switch can use its build in understanding of http to use the host header to forward xmpp to port 5222 and all other request to port 80

regards

bram

6

I filed this issue as JM-537. Please read it over and add comments if I’'ve gotten any of the details wrong.

Thanks,

Matt

7

only thing i have to add is that befor version 7.19 the “sub” domains within flash are trusted and can be used as a workaround, eg

www server = www.example.com port 80

xmpp server = xmpp.example.com ports 80, 443, 5222, 5223

with that its possible to host the crossdomain.xml for the xmpp server on the www server since they are both part of example.com…

and it prolly needs an update when 8.5 hits

regards,

Bram

8

I’'ve modified the createSession function:

String tagCheck = xpp.getName();

if(tagCheck.equals(“policy-file-request”)) {

StringBuilder sb = new StringBuilder(250);

sb.append("<?xml version=\"1.0\"?>");

sb.append("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">");

sb.append("<allow-access-from domain="" to-ports="" />");

// Deliver stanza

connection.deliverRawText(sb.toString());

// Close the underlying connection

connection.close();

/code

This way Wildfire can listen to port 80 on a reserved IP. I use

System.security.loadPolicyFile(“xmlsocket://” + server + “:80”);

/code

to connect and it works fine. The only problem is an exception gets thrown each time I connect; “connection closed before session was created”. But there should be an easy way around this.

A FlashClientSocketReader would probably be a better idea.

Rob

9

Robbie,

If you modified createSession, shouldn’'t you be connecting on port 5222 to get the cross-domain response?

System.security.loadPolicyFile(“xmlsocket://” + server + “:5222”);

Regards,

Matt

10

I can do that. But I want Wildfire to listen to port 80 because of firewall issues.

This way Wildfire works through most of our clients firewalls while satisfying the Flash crossdomain policy.

I’'ve reserved 1 IP address especially for Wildfire so I can run a webserver on that machine aswell. If I want to.

Greets,

Rob