Flash Sandbox Security error just started popping up in the last day. Dead in water.

[RoyceSimpson]

I've got a suite of Flex/AGS based apps hosted locally that have been running for years.

In the past day or so, I've been getting the following sandbox security error ONLY in IE browsers:

SecurityError: Error #3769: Security sandbox violation: Cannot send HTTP headers when using navigateToUrl().

Here is our crossdomain.xml file: http://maps.larimer.org/crossdomain.xml

The error only occurs when you try to use our alivepdf printing process (which again has worked with no issues for years). I realize this isn't an esri issue but I'm hoping there is some expertise on board here that could lend a hand. As it is, all my pdf creation capabilities are dead in the water for IE until I can resolve this issue.

If you go to maps.larimer.org/lil and click the "pdf" button, then "create pdf", the progress bar will either just hang or you'll get the above flash error.

The pdf creation process works just fine in Firefox and works occasionally on Chrome (but chrome has a separate pdf issue not related to this).

Any tips or help would be greatly appreciated. I've exhausted all my resources on this one.
Thanks,
-Royce

[RoyceSimpson]

UPDATE:  Looks like the culprit is the newest Flash Player (13.....214).

Looking to see if I can add anything to the crossdomain.xml file to fix this.  Any ideas big or small are welcome.  😉

Also, this isn't just IE but Firefox as well.  Chrome has it's own built in Flash player so it may or may not be affected.

[GISDev1]

Are you sure you need to be sending custom HTTP headers when using navigateToUrl() in your flex widget? There might be a way to do it without using those HTTP headers? Mind posting the relevant code where you are using navigateToUrl() with AlivePDF?

[RoyceSimpson]

Are you sure you need to be sending custom HTTP headers when using navigateToUrl() in your flex widget? There might be a way to do it without using those HTTP headers? Mind posting the relevant code where you are using navigateToUrl() with AlivePDF?

Here is more of the error:

SecurityError: Error #3769: Security sandbox violation: Cannot send HTTP headers when using navigateToUrl().
at global/flash.net::navigateToURL()
at org.alivepdf.pdf::PDF/save()[/Users/adobe/Desktop/AlivePDF/src/org/alivepdf/pdf/PDF.as:3495]
at components.printing::PrintSetupWindow/sendPrint()

The line in my code at 319 is:

myPDF.save(Method.REMOTE, pdfGeneratorURL, Download.ATTACHMENT, "lcGisMap.pdf");

The alivepdf code at line 3495 is not available to me as that is within the alivepdf binary library.

As far as i can tell, I'm not explicitly sending custom headers but that doesn't mean something isn't going on within the alivepdf code.

[GISDev1]

Here is more of the error:  

SecurityError: Error #3769: Security sandbox violation: Cannot send HTTP headers when using navigateToUrl().
at global/flash.net::navigateToURL()
at org.alivepdf.pdf::PDF/save()[/Users/adobe/Desktop/AlivePDF/src/org/alivepdf/pdf/PDF.as:3495]
at components.printing::PrintSetupWindow/sendPrint()

The line in my code at 319 is:  

myPDF.save(Method.REMOTE, pdfGeneratorURL, Download.ATTACHMENT, "lcGisMap.pdf");

The alivepdf code at line 3495 is not available to me as that is within the alivepdf binary library. 

As far as i can tell, I'm not explicitly sending custom headers but that doesn't mean something isn't going on within the alivepdf code.

I see.
This might be the code that is causing the issue in PDF.as in AlivePDF.

public function savePDF( pMethod:String, pURL:String='', pDownload:String='inline', pName:String='generated.pdf' ):*
  {
   finish();
   if ( pMethod == Method.LOCAL ) return this.buffer;
   var header:URLRequestHeader = new URLRequestHeader ("Content-type", "application/octet-stream");
   var myRequest:URLRequest = new URLRequest ( pURL+'?name='+pName+'&method='+pDownload );
   myRequest.requestHeaders.push (header);
   myRequest.method = URLRequestMethod.POST;
   myRequest.data = savePDF( Method.LOCAL );
   navigateToURL ( myRequest, "_blank" );
   return null;
  }

Looks like this line might be the culprit

(var header:URLRequestHeader = new URLRequestHeader ("Content-type", "application/octet-stream");)

I'm not sure of an easy fix for this one, but I am going to do some more reading on it when I get a chance.

[RoyceSimpson]

Really appreciate it. 

On a different tack, could I have the pdf saved to the server somehow and thenhave the file be made available to the user as any pdf file would be (as if they had clicked a link to a pdf download)?

UPDATE: that wouldn't work either.

[RoyceSimpson]

Now we are getting somewhere. 

https://forums.adobe.com/thread/1474415

I really hope Adobe fixes this.

[AaronNash1 · Accepted solution]

prompting the user to save the file locally will work.

var file : FileReference = new FileReference() file.save(myPDF.save(Method.LOCAL),"my.pdf");

I too am looking for a better workaround, everyone likes to see the PDF before they print or save. I would encourage everyone who is experiencing the issue to vote on the bug

[RoyceSimpson]

prompting the user to save the file locally will work.

var file : FileReference = new FileReference()
file.save(myPDF.save(Method.LOCAL),"my.pdf");

I too am looking for a better workaround, everyone likes to see the PDF before they print or save. I would encourage everyone who is experiencing the issue to vote on the bug

nasha001, THANK YOU!

The below code solves this issue for me. Good riddance!

Alert.show("PDF creation complete. Please choose a destination folder for your PDF file.", "Success!", Alert.OK | Alert.CANCEL, this, alertListener, null, Alert.OK);

private function alertListener(e:CloseEvent):void {
if (e.detail==Alert.OK) {
var file:FileReference = new FileReference;
file.save(_pdf.save(Method.LOCAL),"mypdffile.pdf");
}
}

[CarmenDurham]

Anyone else doing anything differently since May? 

We discovered the same thing here.  I still have FP 11.x so I wasn't noticing any issues, but others with 13.x are.

Will try the above just to have *something* work but I agree with Aaron - people like to see what they are downloading before downloading!

Just trying to keep our Flex app going for a while longer as-is.....

Thanks,

Carmen