Anyways, I can't get it to work properly. I took Adobe's script, which is intended to work with xinetd (the standalone script btw works fine, but I really want xinetd to handle this). After some small changes it seems to run fine now, but the Flashplayer complains about "malformed" XML. I changed the XML now a 1000 times, but it's always the same, and I begin to wonder, if maybe xinetd might be the problem?
Here's the perl script that takes this file and delivers it to Flash:
#!/usr/bin/perl
#
# in.flashpolicyd.pl
# Simple socket policy file server
#
# Usage: in.flashpolicyd.pl -file=FILE
# Logs to stderr
#
use strict;
my $NULLBYTE = pack( 'c', 0 );
my $filePath;
my $content;
### READ ARGS
while ( my $arg = shift @ARGV )
{
if ( $arg =~ m/^--file=(.*)/ )
{
$filePath = $1;
}
}
unless ( $filePath )
{
die "Usage: in.flashpolicyd.pl --file=FILE\n";
}
### READ FILE
-f $filePath or die "No such file: '$filePath'\n";
-s $filePath < 10_000 or die "File probably too large to be a policy file: '$filePath'\n";
{
local $/ = undef;
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n";
$content = <POLICYFILE>;
close POLICYFILE;
}
$content =~ m/cross-domain-policy/ or die "Not a valid policy file: '$filePath'\n";
### HANDLE CONNECTIONS
local $/ = $NULLBYTE;
my $request = <STDIN>;
chomp $request;
if ( $request eq '<policy-file-request/>' )
{
print STDERR "Valid request received\n";
}
else
{
print STDERR "Unrecognized request: $request\n\n";
exit;
}
print STDOUT $content;
#print STDOUT '<?xml version="1.0"?><cross-domain-policy><site-control permitted-cross-domain-policies="master-only"/><allow-access-from domain="mytld.com" to-ports="#####"/></cross-domain-policy>';
print STDERR "Sent policy file\n\n";
# End of file.
As you can see I also tried not to send the file's content, but a string, to make sure there are no extra bytes involved. However, Flash keeps saying that it will ignore the XML because it's malformed.
So, is it possible that xinetd adds something to the result?
Or does anyone sees another thing that might be wrong? I'm fighting with this for 2 days now, so any help is very appreciated.
Have you used a packet sniffer to ensure that the bytestream returned is exactly as expected? Also, the XML you returned as string, you are sure it is valid?
Last, try force auto flush and see if that helps (put it at the beginning of the script):
no, I didn't use a packetsniffer (yet). I also tried the auto flush, but it made no difference.
The XML has to be valid, because when I run the standalone script (also from Adobe) with the same XML file, it all works fine.
The scripts, standalone and xinetd service, are basically the same, except that the standalone handles all the socket stuff itself, where the xinetd service script just reads from STDIN and writes to STDOUT. The other parts (handling the rquest, reading the file) are identical.
That's why I'm pretty sure now that it has something to do with the xinetd. Maybe I'll try a packetsniffer when I have some spare time. Meanwhile I use the standalone daemon and have a cron job watching over it. One more service constantly running... well, if Adobe thinks this is safer than an XML served by my webserver... sigh.
Hm, I don't think so. The connection is made by a so called XMLSocket in Flash, it's a socket that sends and receives string data (XML mainly, but any string is fine, as long as you don't let Flash parse it, but here it is automated because the request gets out before you actually use your socket connection).
So, what I have is
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n";
$content = <POLICYFILE>;
close POLICYFILE;
...
print CONNSOCK $content;
print CONNSOCK $NULLBYTE;
close CONNSOCK;
in the standalone script versus
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n";
$content = <POLICYFILE>;
close POLICYFILE;
...
print STDOUT $content;
in the xinetd script.
I guess that xinetd is supposed to push the output into the socket and add the terminating NULL byte. I don't know how xinetd works, but I've read that you just have to give your output into STDOUT when you're doing a xinetd service, so I guess this is the way to do it.
I have no idea how xineted works either, never even heard of it myself. I now see there are two scripts., one using sockets and one not, which must be the xineted version.
Then you should use it now. As you have a static version that works but a version served from Perl does not, that makes a good control experiment to find out what is the difference. Make sure the XML used is identical in both cases.