ejabberd - Comments for "Flash to Ejabberd XML Socket serving policy file"

Excellent Patch

MikeDunne — Thu, 03 Jul 2008 23:59:19 +0000

The patch is available now for 2.0.1.

Badlop had sent me a version of the patch for a newer release (which I couldn't use). I don't know if will be included in newer release as a patch or in the main branch.

This patch should also work for Flash 8.

To use the patch, I only had to recompile ejabberd_c2s.beam and not ejabberd. After compile of patched ejabberd_c2s.hrl, copied new ejabberd_c2s.beam to
ejabberd-2.0.1\lib\ejabberd-2.0.1\ebin directory (Windows version).

Naturally, if you are not using change control software, make back-up copies of any files that will change.

Excellent patch!

philipj — Thu, 03 Jul 2008 19:26:05 +0000

Yeah, it makes me stop using previous patch from monsieur Badlop (adopted by myself)... and have to recompile ejabberd again :).

But... Can I make a humble suggestion?
Maybe, it will be better and more useful, to combine to patches (flash-hack and flash-policy) in one patch ?

And... even a more humble proposal :) Maybe it worth to include these patches in main branch, adopt for new versions, etc ?

If somebody likes, let them just configure ejabberd with --enable-flash-hack, if they want? Or even a simple option in ejabberd.cfg ?

The reason of my advocacy... is - it will be, first of all, just additional competitive advantage (I know, You understand, what I mean...)

Also, as I know, the situation is following - not all flash-developers correctly understands and can use ActiveScript3 (Flash 9), also, maybe some people want their flash-clients can be run also in Flash 8 computers....

You can check this patch

mfoss — Tue, 01 Jul 2008 15:03:59 +0000

You can check this patch recently updated: Serve cross domain policy file for Flash

You can find solution

philipj — Fri, 27 Jun 2008 18:08:51 +0000

for this (for ejabberd, including latest version, 2.0.1_2) here -

http://www.ejabberd.im/node/2833#comment-53343

Flash to Ejabberd XML Socket serving policy file - hack

MikeDunne — Fri, 30 May 2008 15:05:37 +0000

I agree with Mickael R. that this is a hack, however, just like the Flash non-convention of NULL terminator for internet apps, Flash has introduced another problem for developers.

Given that a large number of sites do not allow ports other than 80, 443, 20, 21, etc. developers are severely limited in creating innovative applications across the WWWeb.

I recognize that this may be a "slippery slope", but, that is another conversation.

Openfire addressed the reality of current requirements. If someone can address the same with a module vs. modification to the core, that would be great.

I personnaly think this is

mremond — Fri, 30 May 2008 07:13:13 +0000

I personnaly think this is quite ugly hack.
Using different port for different usage is clean, but imagine the code for a system serving on the same port: XMPP, HTTP, FTP, IMAP, SMTP, etc. This feel really hackish...

--
Mickaël Rémond
Process-one

Flash to Ejabberd XML Socket serving policy file

MikeDunne — Thu, 29 May 2008 22:42:08 +0000

I "solved" the problem to which the author refers, for the author.

For the record, I just put a small perl script in background on the same machine that's running the ejabberd server that responds with a cross domain socket policy to properly formatted requests coming in over port 843.

That doesn't really solve the author's problem, just allows him to continue with his testing pending a better resolution.

Ignite's openfire programming addresses the requirement quite handily. They went through a few iterations and finally went down to stanza parsing level and and added code that if &ltpolicy-file-request/&gt followed by a NULL byte is the entirety of the stanza, the content of an identified flash socket policy file is served up (enhanced crossdomain.xml, for example).

This is a great implementation since the same port is used for xmpp and socket policy service.

There are a number of points in the ejabberd code where this could be inserted with a minimum impact, but, would probably be addressed better in a module.

Anyone have any ideas?

For reference, the author

mfoss — Thu, 29 May 2008 22:14:56 +0000

For reference, the author posted the same question in the XIFF forum and finally solved the problem, but didn't publish the solution.