Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSocketSite serves also the flash policy file. #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kowalski
Copy link

This removes the necessity of having aditional server listening on port 843, which required root priviliges. It can be done like this according to the article: http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html.

This is something you might consider adding or not. Or maybe it should be optional? In any case I need to support the flash fallback and running the process with root privileges is not an option for me.

This removes the necessity of having aditional server listening on port 843, which required root priviliges. It can be done like this according to the article: http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html.
@wulczer
Copy link
Owner

wulczer commented Feb 18, 2012

Considering it's just example code I would leave it as is (and to make it easier to eventually merge this fork back into the original repo).

It's good to have the example work out of the box with Flash fallbacks like web-socket-js. For production deployments you can use WebSocket.loadFlashPolicyFile('xmlsocket://hostname:port') when using web-socket-js to make it request the policy file from a different port.

I think I like the idea that WebSocketSite is not responsible for serving the policy file - it's better to have a separate protocol for that (or subclass WebSocketSite in your code if you really want it to serve both Websockets and Flash policy files).

@wulczer
Copy link
Owner

wulczer commented Feb 19, 2012

Oh, by the way I think that the implementation proposed is not safe, although it might not matter in practice. Data can come fragmented from the wire, so checking for <policy-file-request/> in dataReceived won't work if you get two separate calls: dataReceived('<policy-file') and dataReceived('-request/>').

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants