The UNIX and Linux Forums  

Go Back   The UNIX and Linux Forums > Top Forums > Shell Programming and Scripting
Google UNIX.COM


Shell Programming and Scripting Post questions about KSH, CSH, SH, BASH, PERL, PHP, SED, AWK and OTHER shell scripts here.

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
Unix as fileserver KBalquis UNIX for Dummies Questions & Answers 7 02-16-2007 02:43 PM
how to get cvs pserver work with xinetd victorvvk UNIX for Advanced & Expert Users 1 05-27-2005 12:25 AM
uninstall xinetd byblyk Linux 5 04-01-2004 10:39 AM
Fileserver?????????? with windows XP and unix akari IP Networking 2 08-14-2002 08:00 AM
xinetd.conf lealyz Security 2 01-21-2002 11:23 AM

Reply
 
Submit Tools LinkBack Thread Tools Search this Thread Display Modes
  #1  
Old 05-05-2008
Registered User
 

Join Date: May 2008
Posts: 4
Fileserver in Perl via xinetd - bad XML output

Hello there,

I hope I took the right forum...

I never worked with Perl, but now I have to get a simple fileserver running. The goal is to deliver an XML file (it's part of a new security model in the Flashplayer, see Adobe - Developer Center : Setting up a socket policy file server for more on that).

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?

This is the XML:
Code:
<?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>
Here's the perl script that takes this file and delivers it to Flash:
Code:
#!/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.

cheers
Reply With Quote
Forum Sponsor
  #2  
Old 05-05-2008
Moderator
 

Join Date: Sep 2002
Location: Hong Kong, China
Posts: 1,477
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):

Code:
$| = 1;
Reply With Quote
  #3  
Old 05-06-2008
Registered User
 

Join Date: May 2008
Posts: 4
Hi,

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.
Reply With Quote
  #4  
Old 05-06-2008
Registered User
 

Join Date: Jan 2008
Posts: 327
Do you need to print anything before the XML code itself is printed to STDOUT? Some type of protocol header maybe?

Should you be using a socket to send the data?

The Adobe sample script is using a socket.
Reply With Quote
  #5  
Old 05-06-2008
Registered User
 

Join Date: May 2008
Posts: 4
Quote:
Originally Posted by KevinADC View Post
Do you need to print anything before the XML code itself is printed to STDOUT? Some type of protocol header maybe?
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
Code:
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
Code:
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.

However what xinetd does after that is beyond me.
Reply With Quote
  #6  
Old 05-06-2008
Registered User
 

Join Date: Jan 2008
Posts: 327
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.
Reply With Quote
  #7  
Old 05-06-2008
Moderator
 

Join Date: Sep 2002
Location: Hong Kong, China
Posts: 1,477
Quote:
Originally Posted by blemmo View Post
no, I didn't use a packetsniffer (yet).
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.

Wireshark is a good sniffer.
Reply With Quote
Google The UNIX and Linux Forums
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes




All times are GMT -7. The time now is 12:11 PM.


Powered by: vBulletin, Copyright ©2000 - 2006, Jelsoft Enterprises Limited.
The UNIX and Linux Forums Content Copyright ©1993-2008. All Rights Reserved.Ad Management by RedTyger Visit The Complex Event Processing Blog

Content Relevant URLs by vBSEO 3.2.0