• Registered: 2009-05-06
  • Posts: 81

Topic: 1.7 Flash security seems to be different

I have a widget that works perfectly under 1.6 but no longer works under 1.7.

The widget itself reads data from a second internal httpd server running on port 8080. This secondary httpd has a crossdomain file with the flowing content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cros … policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*"/>
</cross-domain-policy>

When I look at the player traces

2009-06-02 17:28:25 NetStreamRequest::ProcessHeaders(10) content-type: text/xml
2009-06-02 17:28:25 NetStreamRequest::Step(10) done, closing stream (277 of 277 bytes, avail=0) status=200 (ok)
2009-06-02 17:28:26 TRACE: -> API: Player.checkLicensingResponse( true )
2009-06-02 17:28:26 TRACE: isAllowed? 1

Trying to read crossdomain.xml
2009-06-02 17:28:26 NetStreamRequest::Open(1): Opening protocol 'http://' host 'localhost' port 8080 location '/crossdomain.xml'

2009-06-02 17:28:26 NetStreamRequest::Open(1) opened http object id 8
2009-06-02 17:28:26 NetStreamRequest::ProcessHeaders(1) content-type: application/octet-stream
2009-06-02 17:28:26 NetStreamRequest::Step(1) done, closing stream (214 of 214 bytes, avail=0) status=200 (ok)

These are my traces from onData() and onLoad() saying there was a problem
2009-06-02 17:28:26 TRACE: Error loading config content.
2009-06-02 17:28:26 TRACE: Config loaded with success=false


2009-06-02 17:28:26 TRACE: ExternalMusicSource.assignPlayer(): initializing pandora
2009-06-02 17:28:26 TRACE: -> Player.setMusicPlayer() _level0.controlPanel.instance46.callbacks , [type Function] ; 13150
2009-06-02 17:28:26 TRACE: -> Player.setGuid( 78FBE76F-AB2A-C6D4-D8F3-04AB3F074319 )
2009-06-02 17:28:26 TRACE: ExternalMusicSources.getNextItem() unqueuing iheartradio

I have verified that if I point my browser at any of the files hosted on the second httpd instance they load fine as well as issuing a wget on the chumby itself (as in wget localhost:8080/crossdomain.xml). At this point I am at a loss as to where to look. I was going to try and turn on loging on httpd but I could not get that to happen. The only thing I can think of is that something changed between 1.6 and 1.7 that is now restricting access from local to local but that would be a really odd thing to add/change.

Thanks
-Sam

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: 1.7 Flash security seems to be different

In your onLoad handler, trace the value of the "status" property - it might let us know what's going on.

Is the onData handler is getting "undefined" for the data parameter?

Can you paste the section of the log where the actual fetch for data is being made?

Duane's Website

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: 1.7 Flash security seems to be different

Ah, I think I know what the problem is - there *was* a change in Flash Lite 3.1 security policies that requires that the content-type for the crossdomain.xml file *must* be either "application/xml" or "text/xml".  Since this server is apparently returning a content-type of "application/octet-stream", FL 3.1 considers it invalid.

This change was due to an exploit where people would upload crossdomain.xml files as images or other content (in forums and such) and then referencing it to gain unintended access to the system.

Duane's Website

  • Registered: 2009-05-06
  • Posts: 81

Re: 1.7 Flash security seems to be different

Duane,

You are correct the param to onData is undefined also the onHTTPStatus is never called.

I am not sure which status property you are referring too?
The first NetStreamRequst in the log for localhost is for the corssdomain file. I don't see anything else before that.

Here are my handlers:

var config = new LoadVars();
config.onHTTPStatus = function(httpStatus)
{
    trace("Config HTTP Code: " + this.httpStatus);
}

config.onData = function(src)
{
    if (src == undefined)
        trace("Error loading config content.");
    else
        trace("Loaded config: " + src);
       
    this.onLoad(src != undefined);
}

config.onLoad = function(success)
{
    trace("Config loaded with success=" + success);

.... some other stuff here ...
}

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: 1.7 Flash security seems to be different

Sorry - I thought you were using an XML object, not LoadVars - XML object has a "status" property that can sometimes be helpful.

In any case, please see my previous post about "content-type" for the crossdomain file.

Duane's Website

  • Registered: 2009-05-06
  • Posts: 81

Re: 1.7 Flash security seems to be different

Duane,

I am not following. So the file is just sitting at the root of the httpd when I hit it with the browser it seems to recognize it as xml (though it is possible no content type is returned at all). So is the solution to configure httpd to force a content type? If so how do I do that? My previous attempts to have httpd use a httpd.conf failed as in it seems to ignore the conf file. Do you have an example of one that works with the version of httpd on the Chumby?

Thanks
-Sam

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: 1.7 Flash security seems to be different

According to your log:

2009-06-02 17:28:26 NetStreamRequest::ProcessHeaders(1) content-type: application/octet-stream

It appears that the built-in server serves up XML files as "application/octet-stream" - it appears you'll need to restart it with an httpd.conf file which overrides this behavior.

I *think* you need an http.conf file with the line:

.xml:application/xml

For instance, you could put this in /psp/httpd.conf, then do

killall httpd
/usr/sbin/httpd -h /www -c /psp/httpd.conf

Duane's Website

  • Registered: 2009-05-06
  • Posts: 81

Re: 1.7 Flash security seems to be different

Duane,

Spot on... That fixed it... I would have never found this without your guidance... way too obscure :-)...

Thanks for the help
-Sam

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: 1.7 Flash security seems to be different

I'm glad it worked for you.

Duane's Website

10 Reply by josep (edited by josep 2009-06-03 11:43:10)

  • josep
  • Busy Chum
  • Offline
  • Registered: 2008-05-09
  • Posts: 139

Re: 1.7 Flash security seems to be different

Hi Duane,

Any chance .xml files can be returned as application/xml for the next firmware? I think this is a pretty unintuative side effect of flash security protection when using the chumby's httpd.  I suspect this resolves my other thread on the subject: http://forum.chumby.com/viewtopic.php?tid=3775.

Ill check this tonight. Thanks to samkwitty for articulating what was wrong better than I could.

Regards,
Jose

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,200

Re: 1.7 Flash security seems to be different

I'll look into it - we may be able to supply a default httpd.conf in /etc that sets up this content-type

The httpd is built into Busybox - we don't patch it as part of our build, so we're inheriting that behavior from the default configuration.

Duane's Website

  • josep
  • Busy Chum
  • Offline
  • Registered: 2008-05-09
  • Posts: 139

Re: 1.7 Flash security seems to be different

Hi Duane,

That sounds reasonable. Your work around did indeed fix my other problem.

Regards,
Jose