Thanks for the reply, glad someone is around.
I have spent the past few hours figuring this out, and have gone through basically all the documentation of the socket updates made in version 124 and 115.
And well the conclusion is best explained in a quote from their site.
“These two rules can be summed up in a simple statement: under the strict socket rules, every socket connection requires permission from a socket policy file.”
Those rules are as follows:
1 ) A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.
- HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.
Extra Notes:
If a host serves a socket policy file from port 843 (a socket master policy file), strict socket rules will be applied for the entire host. This is true regardless of the contents of the policy file; even if the socket master policy file is empty, or declares the meta-policy all, the host will still use strict socket rules. All socket connections to this host will require permission from a socket policy file, which will most likely be the same socket master policy file that is triggering the transition to strict socket rules. This is the usual mechanism that host administrators should use to opt into strict socket rules.
If an HTTP server on port 80 declares a URL meta-policy in its master policy file at /crossdomain.xml, then that master HTTP policy file will not authorize socket connections to the same host. This configuration activates only one of the two strict socket rules for its host—the rule about SWF files connecting to their own hosts is unaffected.
If a non-master socket port serves a socket policy file, strict socket rules will be applied for that particular port. All socket connections to this port will require permission from a socket policy file, which will most likely be the same socket policy file that is being served from this port. An occasional unintended consequence of this rule is described in the section on immediately strict sockets: if a socket port 1024 or higher serves a socket policy file that does not list its own domain, then SWF files from that domain, which previously were permitted to connect without a policy file, will be unable to connect.
Anyway you kinda get the point. Luckily for openfire users I understand it serves xmlsocket//: policy files no problem now.
As for my ejabberd server…haven’t explored that yet…
Cheers
G
