views:

1242

answers:

1

I have the following code that creates a serverside object of the xmlhttp class. I am trying to connect to a site that requires basic authentication. I am able to get this to work with the code below.

What's the problem? Well I'm passing the credentials using the open call. That alone is not enough. I must also set the authorization header with the manually calculated base64 encoded username:password combination. If I try to set the header without passing the credentials to the open call, it fails. Call me crazy, but when I pass the credentials to the open, that's all I should have to do. If I set the header, that's all I should have to do. Right? Doing both seems like something isn't right. Right?

Is this a bug or a glitch?

Additional background is: IIS 5 & ASP Classic The error received when one of the two items is ommitted is an HTTP Status 401: "You are not authorized to view this page You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept."

Since IIS is making the request I'm not able to inspect it with Fiddler :-(

Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")
xmlhttp.setTimeouts 5000, 5000, 10000, 10000 'ms - resolve, connect, send, receive
xmlhttp.open "GET", "http://example.com/", False, "username", "password"
xmlhttp.setRequestHeader "Authorization", "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
xmlhttp.send
+2  A: 

I believe you're hitting this known limitation (or bug) that can be boiled down to msxml2 lacking (or having incorrect) support for "negotiated" authentication mechanisms, which means you have to force the issue (bypass the incorrectly-conducted negotiation) exactly by adding the authorization header yourself as you're doing.

Alex Martelli
Thanks, this link summarizes what I'm experiencing perfectly. I thought this is what was going on, I just wanted to make sure I wasn't fouling things up.
Ben
Using the WinHTTP COM object directly has this same problem. I can't believe this hasn't been fixed long ago.
Bob Riemersma