Can't access URL protected with Digest Authentication using URLLoader

Copy link to clipboard
Copied
Hi there, I'm hoping that I can find some more help on a problem that I'm seeing with my script. I'm new to Flash, so there might be an obvious solution, but I can't see it, here's my problem.
I have a pretty simple embedded flash script within an HTML page. My server protects the page using digest authentication, so the browser asks the user for username/password before displaying the page. So far, so good.
Within the script that's playing on that page, after the user clicks a button, the script attempts to POST to another URL on the same server. This other URL is also protected by the server with digest authentication. (The purpose of the flash is to essentially replace a sort of file upload form.)
Well, the attempt to POST fails and actually in IE7, the username/password dialog appears again, but entering a correct username/password still does not allow access to the other URL. What's happening?
To perform the POST, I am using URLLoader, here's the code, it's very basic:
var request:URLRequest = new URLRequest("/uploadmydata.cgi");
request.contentType = "application/octet-stream";
request.method = URLRequestMethod.POST;
request.data = partialdata; //my data
//create the loader and handle the listeners
var loader = new URLLoader();
loader.addEventListener(IOErrorEvent.IO_ERROR, errorHandler);
loader.addEventListener(Event.COMPLETE, loaderCompleteHandler);
loader.addEventListener(HTTPStatusEvent.HTTP_STATUS, loaderResponseStatus);
loader.dataFormat = URLLoaderDataFormat.BINARY;
loader.load(request);
Well, I debugged the server-side and confirmed that the POST headers do contain an Authorized header with all of the appropriate username, realm, nonce, response, etc elements. When my server computes the MD5 digest and compares it the one sent, it does not match and access is denied.
It sure looks like the computed Authorized header elements are somehow wrong and those are created for me by URLRequest, right? It's just a guess, but if the user's password is not accessible to the VM, then it could not possibly create a valid digest, right?
I also tried to lower the protection to BASIC authentication, but that also failed because the password was never sent to the server, even though the browser prompted for it repeatedly.
The purpose of using a protected URL, in this case, is to require only authorized users to the CGI URL; nothing special or unusual about that. If I use HTTP forms instead of Flash, the server has no problem authenticating access.
Of course, removing the protection on the POSTed URL allows the upload to occur.
So to summarize:
1) How can I use ActionScript 3.0 URLLoader and URLRequest to access a digest authentication protected URL?
2) Alternatively, is there another technique not using digest authentication that I can use in my script to protect access to the POSTed URL?
Thanks for any help you can provide,
Bob
Details:
1) Using Flash CS4 professional v10.0, ActionScript 3.0
2) GoAhead webserver (2.1.8; embedded)

Copy link to clipboard
Copied
I have continued to pursue this issue on my own and have unfortunately not been able to get any relief. I even tried to buy a support plan only to ultimately get referred back to there form where, supposedly, adobe dev staff looks at these issues. Help, anyone?
Ok, at this point, I am convinced that there is a bug in the player but no one else seems to do what I would like to do. Reiterating, I need to use URLLoader to POST data to a URL that the server protects using DIGEST authentication. The AS used to do this is embedded in an HTML page (from the same server and realm), this to even get to this HTML page, the user already logged in and has been authenticated.
I have confirmed that the request sent to the server from the URLLoader request contains digest authorization information. I do not have my AS script compute anything, the authorization header is computed for me automatically. The problem is that the digest information is wrong and thus does not authenticate in the server! This is a huge bug! I have tried IE7,8 and FF (linux) with the same results.
Again, if all I do is lower the protection (of both pages) in the server to BASIC authentication, the same AS code works perfectly. Meaning, that the basic authorization header is automatically generated for my request to the server and it authenticates. (Previously, I said that when I tried this, it didn't work, however, since then, there was a update to the player, so the issue with BASIC authentication may have been fixed, unless I incorrectly performed this test the first time.)
Similarly, rather than try an upload, the same failure happens if you just try to navigateToURL that is protected using digest authorization. The digest data is wrong and the server rejects it.
So, here we are. I wish I could upload a useful example, but this is a combination client/server issue. It should be simple to reproduce:
1. Create a HTML page with an embedded SWF that has a button that does a navigatetoURL to another page on the server. The content of the second page does not matter.
2. In the server, configure those two pages with digest authentication (creating an appropriate username/password for this test also)
3. Test it.
Now, granted that I am using an embedded server (GoAhead), and that might call into question the authentication algorithm, but since only for AS-based objects (URLLoader,etc.) requests fail to authenticate, the conclusion must be that whatever is computing the authorization header for the request is wrong.
I hope that someone with more intimate knowledge of how this header is generated for the URLLoader (or navigateToURL) object can help with this issue. Atleast, some confirmation that it is an issue would be a relief.
Thanks.
Copy link to clipboard
Copied
I was trying to resolve the same issue a few months ago with no success. The main reason is that latest Flash players, with current security sandbox, do not allow authentication header. In previous versions it was possible.

Copy link to clipboard
Copied
Well, after my last post, I tried one last time and inspiration struck. I was able to reproduce the rejected request without using ActionScript. Thus, this test case eliminated the AS or the player as the cause of the problem. Knowing that AS was not the problem, I focused on the authentication mechanism and found a bug in the server. I fixed the bug and now the POST works as well as the redirection.
So, it looks like the player is working just fine within an authentication environment. It is a huge relief to finally know that it's not a problem with the ActionScript or the player, but just a bug in the server.
Now, here's some details about the bug. The issue within my server (GoAhead) was incorrect parsing of the digest authentication header. Specifically, the URI field of the header. Possibly due to legacy browser issues, the server manually parsed the field value, discarding 'invalid' characters. Well, in my case, all of the failures were of requests containing query fields in the URL. Thus, when my server was extracting the URI field, it misinterpreted the query delimiters in the URI and used only a partial content of that field, thus computing an incorrect digest. So, after a simple fix, the server computes the digest correctly now and it all works.

