[haXe] HaXE remoting failed to retrieve URL - solved

[Ron Wheeler]

We got into some really heavy debugging with the Flash debugging Player.

This was the output in the flashlog.txt

Error: Request for resource at 
http://ecard.artifact-software.com/logging/server.n by requestor from 
http://www.artifact-e-metrics.com/demos/1/controller/compiledClasses.swf 
is denied due to lack of policy file permissions.
*** Security Sandbox Violation ***
Connection to http://ecard.artifact-software.com/logging/server.n halted 
- not permitted from 
http://www.artifact-e-metrics.com/demos/1/controller/compiledClasses.swf

 From the policy file log:

OK: Root-level SWF loaded: 
http://www.artifact-e-metrics.com/demos/1/ecard.swf
OK: Searching for <allow-http-request-headers-from> in policy files to 
authorize header sending to URL 
http://ecard.artifact-software.com/logging/server.n by requestor from 
http://www.artifact-e-metrics.com/demos/1/controller/compiledClasses.swf
OK: Policy file accepted: http://ecard.artifact-software.com/crossdomain.xml
Error: Request for resource at 
http://ecard.artifact-software.com/logging/server.n by requestor from 
http://www.artifact-e-metrics.com/demos/1/controller/compiledClasses.swf 
is denied due to lack of policy file permissions.


http://ecard.artifact-software.com/crossdomain.xml that it found.

<?xml version="1.0"?>
   <!DOCTYPE cross-domain-policy SYSTEM 
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
   <cross-domain-policy>
      <site-control permitted-cross-domain-policies="master-only"/>
     <allow-access-from domain="www.artifact-e-metrics.com" />
     <allow-access-from domain="artifact-e-metrics.com"/>  
</cross-domain-policy>

 From the log error message, it looked like it found and parsed the 
crossdomain.xml file but does not think that www.artifact-e-metrics.com 
is allowed to access ecard.artifact-software.com


S O L U T I O N

We added

<allow-http-request-headers-from domain="www.artifact-e-metrics.com" headers="*" />

to the crossdomain.xml and this seems to have fixed the problem.
It is not exactly clear why we needed both "allow-access-from" and 
"allow-http-request-headers-from" but it seems to be working.
Policy log says

OK: Searching for <allow-access-from> in policy files to authorize data 
loading from resource at 
http://ecard.artifact-software.com/logging/server.n by requestor from 
http://www.artifact-e-metrics.com/demos/1/controller/compiledClasses.swf
OK: Request for resource at 
http://ecard.artifact-software.com/logging/server.n by requestor from 
http://www.artifact-e-metrics.com/demos/1/controller/compiledClasses.swf 
is permitted due to policy file at 
http://ecard.artifact-software.com/crossdomain.xml

and the Neko server is getting the transactions.


BTW   
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html 
is a great reference document for Flash 9 security and
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14213&sliceId=2 
was the source of the "allow-http-request-headers-from" idea.

Thanks to everyone who expressed an interest in our problems.

Ron



Nicolas Cannasse wrote:
> Ron Wheeler a écrit :
>> Still fighting with remoting.
>> Although the results are repeatable, the pattern is still pretty random.
>> For some people it works fine. For others, it only works with 1 
>> browser, and for others, it works with the other browser (IE7 or 
>> Firefox are our 2 targets).
>> In all cases, I can see the request for the crossdomain file and then 
>> either no further access to the server or a remoting request that get 
>> processed correctly.
>> It is something getting blocked inside the PC since in the case where 
>> it does not work, I can see from the router that no TCP/IP message is 
>> sent from the PC.
>>
>> Any suggestions about how to track down the root cause?
>
> If you're using HTTP-based remoting (i.e not-socket remoting), then 
> the request is directly handled by the browser, not by flash itself. 
> Datas are sent using POST so there should not be browser cache issues...
>
> If the request is not sent to the server, then I'm out of answers...
> Maybe in some cases with many concurrent requests some might be 
> dropped, but I don't think that's your case here.
>
> Nicolas
>