I'm trying to request a HTTP resource that requires basic authorization headers from within an Adobe AIR application. I've tried manually adding the headers to the request, as well as using the setRemoteCredentials() method to set them, to no avail.
Here's the code:
<mx:Script>
<![CDATA[
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
private function authAndSend(service:HTTPService):void
{
service.setRemoteCredentials('someusername', 'somepassword');
service.send();
}
private function resultHandler(event:ResultEvent):void
{
apiResult.text = event.result.toString();
}
private function resultFailed(event:FaultEvent):void
{
apiResult.text = event.fault.toString();
}
]]>
</mx:Script>
<mx:HTTPService id="apiService"
url="https://mywebservice.com/someFileThatRequiresBasicAuth.xml"
resultFormat="text"
result="resultHandler(event)"
fault="resultFailed(event)" />
<mx:Button id="apiButton"
label="Test API Command"
click="authAndSend(apiService)" />
<mx:TextArea id="apiResult" />
However, a standard basic auth dialog box still pops up prompting the user for their username and password. I have a feeling I'm not doing this the right way, but all the info I could find (Flex docs, blogs, Google, etc.) either hasn't worked or was too vague to help.
Any black magic, oh Flex gurus? Thanks.
EDIT: Changing setRemoteCredentials() to setCredentials() yields the following ActionScript error:
[MessagingError message='Authentication not supported on DirectHTTPChannel (no proxy).']
EDIT: Problem solved, after some attention from Adobe. See the posts below for a full explanation. This code will work for HTTP Authentication headers of arbitrary length.
import mx.utils.Base64Encoder;
private function authAndSend(service:HTTPService):void
{
var encoder:Base64Encoder = new Base64Encoder();
encoder.insertNewLines = false; // see below for why you need to do this
encoder.encode("someusername:somepassword");
service.headers = {Authorization:"Basic " + encoder.toString()};
service.send();
}
Finally received some attention from Adobe and got an answer on this. The problem with long HTTP Authentication headers is that, by default, the Base64Encoder class will inject newline characters every 72 characters. Obviously that causes a chunk of the base-64 encoded string to be interpreted as a new header attribute, which causes the error.
You can fix this by setting (in the above example) encoder.insertNewLines = false; The default setting is true.
I've fixed the above code to work for arbitrarily long Authentication strings.
Ah. The pain, the suffering. The sheer misery.
While you've figured out how to add a header before making your call, the nasty truth is that somewhere deep down in the Flash/browser integration space your headers are being removed again.
From my blogpost last year at verveguy.blogspot.com
So I have unraveled the Truth. (I think)
It's more tortured than one would imagine
1/ All HTTP GET requests are stripped of headers. It's not in the Flex stack so it's probably the underlying Flash player runtime
2/ All HTTP GET requests that have content type other than application/x-www-form-urlencoded are turned into POST requests
3/ All HTTP POST requests that have no actual posted data are turned into GET requests. See 1/ and 2/
4/ All HTTP PUT and HTTP DELETE requests are turned into POST requests. This appears to be a browser limitation that the Flash player is stuck with. (?)
What this boils down to in practical terms is that if you want to pass headers in all requests, you should always use POST and you should find another way to communicate the semantics of the operation you "really wanted". The Rails community have settled on passing ?_method=PUT/DELETE as a work around for the browser problems underlying 4/
Since Flash adds the wonderful header stripping pain on GET, I'm also using ?_method=GET as a workaround for that. However, since this trips up on 3/,
I am passing a dummy object as the encoded POST data. Which means my service needs to ignore dummy posted data on a ?_method=GET request.
Crucial at this point to know about 2/. That wasted a bunch of my time.
I've built all of this handling into a new RESTService class with MXML markup support so it's possible to pretend this doesn't exist on the client side.
Hope this helps someone.
The setCredentials() & setRemoteCredentials() methods are intended for use with Flex/LiveCycle Data Services, so they probably don't apply in your case.
This ought to work for you. I was able to reproduce this behavior on my server, and this fix seems to have done the trick; it still seems a bit odd this isn't more API-user-friendly, considering how common a use case you'd think it were, but nonetheless, I've tested and verified this works, given a valid SSL cert:
private function authAndSend(service:HTTPService):void
{
var encoder:Base64Encoder = new Base64Encoder();
encoder.encode("someusername:somepassword");
service.headers = {Authorization:"Basic " + encoder.toString()};
service.send();
}
Hope it helps! And thanks for posting -- I'm sure I would've run into this one sooner or later myself. ;)
This really has helped me! Thanks!
I use Flex Builder 3
One note: WebService's property headers is read only.
So I tried to use httpHeaders. It works!
var encoder:Base64Encoder = new Base64Encoder();
encoder.insertNewLines = false;
encoder.encode("test:test");
sfWS.httpHeaders = {Authorization:"Basic " + encoder.toString()};
I had the same problem while consuming HTTP Basic Authenticated Webservice. This is my solution; it works fine:
private function authAndSend(service:WebService):void
{
var encoder:Base64Encoder = new Base64Encoder();
encoder.insertNewLines = false;
encoder.encode("user:password");
service.httpHeaders = { Authorization:"Basic " + encoder.ToString() };
service.initialize();
}
usage
authAndSend(WebService( aWebServiceWrapper.serviceControl));
Try using setCredentials rather than setRemoteCredentials and failing that, using Fiddler/Charles to find out what headers are being sent with the request.
Also, just so other people don't spend 10 minutes working out why the correct example doesn't quite work asis, you need to import the mx.utils.Base64Encoder package eg:
import mx.utils.Base64Encoder;
At the beginning or somewhere within the CDATA area. I'm new to flex so this wasn't quite obvious at first.
This is how its done.
import mx.utils.Base64Encoder;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.rpc.http.HTTPService;
var _oHttp:HTTPService = new HTTPService;
var sUsername:String = "theusername"
var sPassword:String = "thepassword";
var oEncoder:Base64Encoder = new Base64Encoder();
oEncoder.insertNewLines = false;
oEncoder.encode(sUsername + ":" + sPassword);
_oHttp.method = "POST";
_oHttp.headers = {Authorization:"Basic " + oEncoder.toString()};
Related
How do I get the BlobItem for which I know the full name/URI?
I have AccountName, AccountKey available to me; I can generate a SAS URI if needed.
The blobContainerClient.GetBlobs(prefix: $"{fullName}").Single(); seems the straightforward way but this is actually a query which (at scale) is costly
The BlobModelsFactory seems to be explicitly made for mocking purposes
BlobItem does not have a constructor nor publicly settable properties
You can try the code below to get the properties of a blob:
var blobClient = new BlobClient(new Uri("<Blob URI with sas token>"));
var blobProperties = blobClient.GetProperties().Value;
We're trying to send a signed, partially encrypted SOAP message to the IRS using CXF. We think we're following all their instructions but there are ambiguities. Some of the Signature and Encryption properties could be set in several ways, but none of the permutations I've tried get us past the dreaded "TPE1122" error (WS Security Header invalid). If anyone has done this successfully, is there some property we're failing to set? I'm especially unsure about the encryption algorithm setting and whether the whole element should be encrypted or just the 3 header elements within it. Thanks.
BulkRequestTransmitterService ss = new BulkRequestTransmitterService(wsdlURL, SERVICE_NAME);
BulkRequestTransmitterPortType port = ss.getBulkRequestTransmitterPort();
org.apache.cxf.endpoint.Client client = ClientProxy.getClient(port);
// set up MTOM
Binding binding = ((BindingProvider)port).getBinding();
((SOAPBinding)binding).setMTOMEnabled(true);
// set output properties
Map<String, Object> outProps = new HashMap<String, Object>();
outProps.put("action", "Timestamp Signature Encrypt");
outProps.put("passwordType", "PasswordDigest");
outProps.put("signatureUser", "[REDACTED]";
outProps.put(WSHandlerConstants.SIG_KEY_ID, "X509KeyIdentifier");
outProps.put("passwordCallbackClass", "UTPasswordCallback");
outProps.put("encryptionUser", "irs");
outProps.put("encryptionPropFile", "encryption.properties");
outProps.put("encryptionKeyIdentifier", "DirectReference");
outProps.put("encryptionKeyTransportAlgorithm", "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p");
// ENC_SYM_ALGO: what is the default? what should correct value be? and are these two lines equivalent?
outProps.put(WSHandlerConstants.ENC_SYM_ALGO, WSConstants.TRIPLE_DES);
outProps.put("encryptionSymAlgorithm", "http://www.w3.org/2001/04/xmlenc#tripledes-cbc");
// do we encrypt each of the three signed headers, or entire Signature element? have tried it both ways
outProps.put("encryptionParts",
//"{Element}{" + WSU_NS + "}Timestamp;"
//+"{Element}{urn:us:gov:treasury:irs:ext:aca:air:7.0}ACATransmitterManifestReqDtl;"
//+"{Element}{urn:us:gov:treasury:irs:ext:aca:air:7.0}ACABusinessHeader;");
"{Element}{http://www.w3.org/2000/09/xmldsig#}Signature;");
outProps.put("signaturePropFile", "signature.properties");
outProps.put("signatureAlgorithm", "http://www.w3.org/2000/09/xmldsig#rsa-sha1");
outProps.put("signatureParts",
"{Element}{" + WSU_NS + "}Timestamp;"
+ "{Element}{urn:us:gov:treasury:irs:ext:aca:air:7.0}ACATransmitterManifestReqDtl;"
+ "{Element}{urn:us:gov:treasury:irs:ext:aca:air:7.0}ACABusinessHeader;");
outProps.put(WSHandlerConstants.SIG_C14N_ALGO, "http://www.w3.org/2001/10/xml-exc-c14n#WithComments");
// is "Direct Reference" preferable? have tried it both ways
outProps.put(WSHandlerConstants.ENC_KEY_ID, "X509KeyIdentifier");
outProps.put("timeToLive", "600"); // = 10 min
outProps.put(WSHandlerConstants.MUST_UNDERSTAND, "false");
WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
client.getOutInterceptors().add(wssOut);
// add gzip interceptor
GZIPOutInterceptor gz = new GZIPOutInterceptor();
gz.setForce(true);
client.getOutInterceptors().add(gz);
[ create & populate Manifest Detail here]
Header detailHeader = new Header(new QName("urn:us:gov:treasury:irs:ext:aca:air:7.0", "ACATransmitterManifestReqDtl"), aCATrnsmtManifestReqDtlType,
new JAXBDataBinding(ACATrnsmtManifestReqDtlType.class));
headers.add(detailHeader);
Header businessHeader = new Header(new QName("urn:us:gov:treasury:irs:ext:aca:air:7.0", "ACABusinessHeader"), aCABulkBusinessHeaderRequestType,
new JAXBDataBinding(ACABulkBusinessHeaderRequestType.class));
headers.add(businessHeader);
// add headers to Request
client.getRequestContext().put(Header.HEADER_LIST, headers);
// add namespaces:
Map<String, String> nsMap = new HashMap<>();
nsMap.put("soapenv", "http://schemas.xmlsoap.org/soap/envelope/");
nsMap.put("urn", "urn:us:gov:treasury:irs:ext:aca:air:7.0");
nsMap.put("urn1", "urn:us:gov:treasury:irs:common");
nsMap.put("urn2", "urn:us:gov:treasury:irs:msg:acabusinessheader");
nsMap.put("urn3", "urn:us:gov:treasury:irs:msg:irsacabulkrequesttransmitter");
nsMap.put("urn4", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");
client.getRequestContext().put("soap.env.ns.map", nsMap);
// then transmit, get TPE1122 error in Response
Bulit in CXF security will not work in IRS submission. You need to code your interceptors for matching IRS requirements.
I have a sample project ready, which can do submission and status requests. This is by no means a production code, but can be a starting point
https://github.com/sangramjadhav/irsclient
Please see application.yml file. You need to provide keystore and other configuration for submission to IRS
Thanks to both responders for your feedback. We have it working now and the main problem was that we were not supposed to use encryption. Everything in the sample I posted worked (including using CXF to sign certain parts of the header), but the encryption had to be removed.
It is indeed quite difficult to get everything right when transmitting to the IRS AIR system. The next hurdle was solved by changing a namespace in one of the wsdl-generated files, and then it went through, but their Linux system's value for the file size was 2 chars smaller than our Windows system's value - the culprit was the trailing CRLF.
I would be happy to answer specific questions if anyone is trying to do this as we did, using Java, Apache-CXF, and Windows.
I'm building an AIR application. Basically, what I'm looking to do is using navigateToUrl() to open a browser window, assign it a "name" and then, send variables to that newly opened window using the POST method.
EDIT : I need the window to be visible, this is why I absolutely need to use the navigateToUrl() function
I already know that I CAN'T DO something like this, that the AIR application will send the variables using the GET method...
var vars:URLVariables = new URLVariables();
vars.myVar = "Hello my friend";
var req:URLRequest = new URLRequest("http://example.com/my-page.php");
req.method = "POST":
req.data = vars;
navigateToURL(req);
Considering the amount of variables I have to send (multiline texts) I absolutely need to send my variables using the POST method else Internet Explorer is truncating the query string... Works fine in Firefox and Safari but unfortunately, we will always have (hope not!) to deal with IE..
So I was thinking something like this :
import flash.net.navigateToURL;
private var _timer:Timer;
protected function loadPage():void
{
var req:URLRequest = new URLRequest("http://example.com/my-page.php");
navigateToURL(req, "myPageName");
_timer = new Timer(3000, 1);
_timer.addEventListener(TimerEvent.TIMER, postVars);
_timer.start();
}
protected function postVars(event:TimerEvent):void
{
// I'm looking to send variables using the POST method to "myPageName"
// and possibly using URLVariables()??
_timer.stop();
}
Any idea Flex coders? THANKS!
I think what you're going to need to do is open up a page you have control over, then use ExternalInterface to inject the values into a hidden form and then execute the post operation in that page form.submit(), etc.
This can happen almost instantly and it will all appear very seamless to the end user.
What I'm doing NOW:
Often multiple instances of the view component would be used in multiple places in an application. Each time I do this, I register the same mediator with a different name.
When a notification is dispatched, I attach the name of the mediator to the body of the notification, like so:
var obj:Object = new Object();
obj.mediatorName = this.getMediatorName();
obj.someParameter = someParameter;
sendNotification ("someNotification", obj);
Then in the Command class, I parse the notification body and store the mediatorName in the proxy.
var mediatorName:String = notification.getBody().mediatorName;
var params:String = notification.getBody().someParameter;
getProxy().someMethod(params, mediatorName);
On the return notification, the mediatorName is returned with it.
var obj:Object = new Object();
obj.mediatorName = mediatorName;
obj.someReturnedValue= someReturnedValue;
sendNotification ("someReturnedNotification", obj);
In the multiple mediators that might be watching for "someReturnedNotification," in the handleNotification(), it does an if statement, to see
if obj.mediatorName == this.getMediatorName
returns true. If so, process the info, if not, don't.
My Question is:
Is this the right way of using Multiton PureMVC? My gut feeling is not. I am sure there's a better way of architecting the application so that I don't have to test for the mediator's name to see if the component should be updated with the returned info.
Would someone please help and give me some direction as to what is a better way?
Thanks.
I checked with Cliff (the puremvc.org guy) and he said it's fine.
I have a Flex file upload script that uses URLRequest to upload files to a server. I want to add support for http authentication (password protected directories on the server), but I don't know how to implement this - I assume I need to extend the class somehow, but on how to I'm a little lost.
I tried to modify the following (replacing HTTPService with URLRequest), but that didn't work.
private function authAndSend(service:HTTPService):void{
var encoder:Base64Encoder = new Base64Encoder();
encoder.encode("someusername:somepassword");
service.headers = {Authorization:"Basic " + encoder.toString()};
service.send();
}
I should point out that I'm not knowledgeable when it comes to ActionScript / Flex, although I have managed to successfully modify the upload script somewhat.
[Edit] - here is an update of my progress, based on the answer below, although I still cannot get this to work:
Thank you for your assistance. I've tried to implement your code but I've not had any luck.
The general behaviour I'm experiencing when dealing with HTTP authenticated locations is that with IE7 all is well but in Firefox when I attempt to upload a file to the server it displays an HTTP authentication prompt - which even if given the correct details, simply stalls the upload process.
I believe the reason IE7 is ok is down to the the session / authentication information being shared by the browser and the Flash component - however, in Firefox this is not the case and I experience the above behaviour.
Here is my updated upload function, incorporating your changes:
private function pergress():void
{
if (fileCollection.length == 0)
{
var urlString:String = "upload_process.php?folder="+folderId+"&type="+uploadType+"&feid="+formElementId+"&filetotal="+fileTotal;
if (ExternalInterface.available)
{
ExternalInterface.call("uploadComplete", urlString);
}
}
if (fileCollection.length > 0)
{
fileTotal++;
var urlRequest:URLRequest = new URLRequest("upload_file.php?folder="+folderId+"&type="+uploadType+"&feid="+formElementId+"&obfuscate="+obfuscateHash+"&sessidpass="+sessionPass);
urlRequest.method = URLRequestMethod.POST;
urlRequest.data = new URLVariables("name=Bryn+Jones");
var encoder:Base64Encoder = new Base64Encoder();
encoder.encode("testuser:testpass");
var credsHeader:URLRequestHeader = new URLRequestHeader("Authorization", "Basic " + encoder.toString());
urlRequest.requestHeaders.push(credsHeader);
file = FileReference(fileCollection.getItemAt(0));
file.addEventListener(Event.COMPLETE, completeHandler);
file.addEventListener(HTTPStatusEvent.HTTP_STATUS, onHTTPStatus);
file.addEventListener(ProgressEvent.PROGRESS, onUploadProgress);
file.upload(urlRequest);
}
}
As stated above, I seem to be experiencing the same results with or without the amendments to my function.
Can I ask also where the crossdomain.xml should be located - as I do not currently have one and am unsure where to place it.
The syntax is a little different for URLRequest, but the idea's the same:
private function doWork():void
{
var req:URLRequest = new URLRequest("http://yoursite.com/yourservice.ext");
req.method = URLRequestMethod.POST;
req.data = new URLVariables("name=John+Doe");
var encoder:Base64Encoder = new Base64Encoder();
encoder.encode("yourusername:yourpassword");
var credsHeader:URLRequestHeader = new URLRequestHeader("Authorization", "Basic " + encoder.toString());
req.requestHeaders.push(credsHeader);
var loader:URLLoader = new URLLoader();
loader.load(req);
}
A couple of things to keep in mind:
Best I can tell, for some reason, this only works where request method is POST; the headers don't get set with GET requests.
Interestingly, it also fails unless at least one URLVariables name-value pair gets packaged with the request, as indicated above. That's why many of the examples you see out there (including mine) attach "name=John+Doe" -- it's just a placeholder for some data that URLRequest seems to require when setting any custom HTTP headers. Without it, even a properly authenticated POST request will also fail.
Apparently, Flash player version 9.0.115.0 completely blocks all Authorization headers (more information on this one here), so you'll probably want to keep that in mind, too.
You'll almost surely have to modify your crossdomain.xml file to accommodate the header(s) you're going to be sending. In my case, I'm using this, which is a rather wide-open policy file in that it accepts from any domain, so in your case, you might want to limit things a bit more, depending on how security-conscious you are.
crossdomain.xml:
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
<allow-http-request-headers-from domain="*" headers="Authorization" />
</cross-domain-policy>
... and that seems to work; more information on this one is available from Adobe here).
The code above was tested with Flash player 10 (with debug & release SWFs), so it should work for you, but I wanted to update my original post to include all this extra info in case you run into any issues, as the chances seem (sadly) likely that you will.
Hope it helps! Good luck. I'll keep an eye out for comments.
The FileReference.upload() and FileReference.download() methods do not support the URLRequest.requestHeaders parameter.
http://livedocs.adobe.com/flex/2/langref/flash/net/URLRequest.html
If you want to upload a file, you just need to send the correct headers and the content of file using URLRequest via UploadPostHelper class. This works 100%, i am using this class to upload generated images and CSV files, but you could upload any kind of file.
This class simply prepares the request with headers and content as if you would be uploading the file from a html form.
http://code.google.com/p/as3asclublib/source/browse/trunk/net/UploadPostHelper.as?r=118
_urlRequest = new URLRequest(url);
_urlRequest.data = "LoG";
_urlRequest.method = URLRequestMethod.POST;
_urlRequest.requestHeaders.push(new URLRequestHeader("X-HTTP-Code-Override", "true"));
_urlRequest.requestHeaders.push(new URLRequestHeader("pragma", "no-cache"));
initCredentials();
_loader.dataFormat = URLLoaderDataFormat.BINARY;
//this creates a security problem, putting the content type in the headers bypasses this problem
//_urlRequest.contentType = 'multipart/form-data; boundary=' + UploadPostHelper.getBoundary();
_urlRequest.requestHeaders.push( new URLRequestHeader( 'Cache-Control', 'no-cache' ) );
_urlRequest.requestHeaders.push(new URLRequestHeader('Content-Type', 'multipart/form-data; boundary=' + UploadPostHelper.getBoundary()));
_urlRequest.data = UploadPostHelper.getPostData("file.csv", param[1]);
_loader.load(_urlRequest);
I'm not sure about this but have you tried adding username:password# to the beginning of your url?
"http://username:password#yoursite.com/yourservice.ext"
var service : HTTPService = new HTTPService ();
var encoder:Base64Encoder = new Base64Encoder();
encoder.insertNewLines = false;
encoder.encode("user:password");
service.headers = {Authorization:"Basic " + encoder.toString()};
service.method = HTTPRequestMessage.POST_METHOD;
service.request = new URLVariables("name=John+Doe");
service.addEventListener(FaultEvent.FAULT,error_handler );
service.addEventListener(ResultEvent.RESULT,result_handler);
service.url = 'http://blah.blah.xml?'+UIDUtil.createUID();
service.send();
Seemingly similar problem was solved here. I urge you to also check the Flexcoders post linked to in the first post.
The problem was that FireFox uses a separate browser window instance to send the file upload request. The solution is to manually attach the session id to the request url. The session id is not attached as a regular GET variable, but with a semicolon (the reason for this syntax is unknown to me).
Flash is very limited in terms of what sort of headers you can pass with an http request (and it changes between browsers and OSes). If you get this to work on one browser/OS, make sure you test it on the others.
The best thing to do is not mess with HTTP headers.
We have the same issue (uploading to Picasa Web Albums from flash) and post through a proxy on our server. We pass the extra headers through as post parameters and our proxy does the right thing.
"http://username:password#yoursite.com/yourservice.ext"
This doesn't work in IE (http://www.theregister.co.uk/2004/01/30/ms_drop_authentication_technique/) and doesn't seem to work in Chrome either.
probably not usable in Flash
Here is a work-around when using ASP.Net based in part on the work here.
I built a component that dynamically writes Flex objects to the page so they can be used in UpdatePanels. Message me if you want they code. To solve the above problem in pages where authentication cookies will need to be sent by URLRequest, I add the values in as flashVars.
This code only works in my object, but you get the idea
Dictionary<string, string> flashVars = new Dictionary<string, string>();
flashVars.Add("auth", Request.Cookies["LOOKINGGLASSFORMSAUTH"].Value);
flashVars.Add("sess", Request.Cookies["ASP.NET_SessionId"].Value);
myFlexObject.SetFlashVars(flashVars);
Then in the Flex Object, check for the params
if (Application.application.parameters.sess != null)
sendVars.sess= Application.application.parameters.sess;
if (Application.application.parameters.auth != null)
sendVars.au= Application.application.parameters.auth;
request.data = sendVars;
request.url = url;
request.method = URLRequestMethod.POST;
Finally stuff the cookies in on global.asax BeginRequest
if (Request.RequestType=="POST" && Request.Path.EndsWith("upload.aspx"))
{
try
{
string session_param_name = "sess";
string session_cookie_name = "ASP.NET_SESSIONID";
string session_value = Request.Form[session_param_name]; // ?? Request.QueryString[session_param_name];
if (session_value != null) { UpdateCookie(session_cookie_name, session_value); }
}
catch (Exception) { }
try
{
string auth_param_name = "au";
string auth_cookie_name = FormsAuthentication.FormsCookieName;
string auth_value = Request.Form[auth_param_name];// ?? Request.QueryString[auth_param_name];
if (auth_value != null) { UpdateCookie(auth_cookie_name, auth_value); }
}
catch (Exception) { }
}
Hope this help someone avoid the 6 hours I just spent addressing this. Adobe has closed the issue as unresolvable, so this was my last resort.