HTTP scripts not authenticating through IIS6/Win2k3

We are migrating a site involved with a few account types to Windows 2003 from Windows 2000. The problem I am having is that HTTP scripts always fail (with a 401 in the logs...just :Error contacting: <theurl>" in the Optigold debugger).

It seems that no matter how I set these permissions, if Optigold is challenged on the billing-cycle script, it fails (even though I can copy the line from the Optigold debugger into IE or firefox and when I get the login box enter the username and password from the script fields and it works fine).

If I turn off the challenge in IIS and remove the name and password from the OG script, it works fine.

Anyone got insight?

Sam - FSI

 

Shawn, have you seen this before?

Basically I have a couple of http scripts that run for certain billing cycle items. These login with the name/pass field in OG and are IIS/Windows set-up not to allow anonymous access.

In Windows 2003/IIS6 it seems that no matter what combination of permissions (local user/domain user, full control) or IIS security (basic/NT/integrated/default domain, etc..) the http action always fails from Optigold.

Visiting the website from the error mail prompts for a username and password, and copying and pasting them from the scripts field works fine....I just can't seem to get Optigold to do it.

Some known IIS6 compatibility issue?

Sam

 

Any update to this?

 

Would it be ridiculous to ask that you obtain a copy of Windows 2003/IIS6 and test Optigold for compatibility? We have just put in for another 1000 license so are not casual testers of Optigold. According to Microsoft's website, mainstream support for Windows 2000/IIS5 expired this summer and we are already feeling pressure to move what is left on that platform over to Windows 2003. (This includes the server that processes http scripts, whose authentication appears not to work with Optigold.) If this part of Optigold specifically will not be supported for IIS6, we will need to know that.

Or perhaps you could scrounge up a friend, forum user, or development partner to confirm that this should be working and I just have not found the magic combination of checkboxes and permissions?

Thanks.

Sam - FSI

 

Yes, I can use web browsers to authenticate (tested in IE and firefox).

For a demonstration, try this:

http://users.pullman.com/samnaugler/auth/

username: shawnhogan
password: Optigold

(there is nothing here but a one word file that says "Success")

This is opposed to:

http://users.pullman.com/samnaugler/noauth/

which has the same file but no authentication.

Using Optigold, with two Generic scripts, I can visit the noauth site (with Debugger turned on) and my HTTP Failure message is "Success"), visiting the auth site without a name and password in the script fields in Optigold I get the text of a standard "you are not authorized" error in the debugger window, but visiting the site with a name and password in the script fields in Optigold I get < h1> Bad Request </h1 > message in the debugger window.

Looking at the server directly I see standard behaviors:

(the noauth one)

telnet users.pullman.com 80

GET /samnaugler/noauth/ HTTP/1.1
Host: users.pullman.com

<enter> <enter>

HTTP/1.1 200 OK
Content-Length: 7
Content-Type: text/html
Last-Modified: Wed, 30 Aug 2006 16:06:51 GMT
Accept-Ranges: bytes
ETag: "cdd7254e4eccc61:2f3"
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
Date: Wed, 30 Aug 2006 17:23:49 GMT

Success


(the auth one)

telnet users.pullman.com 80

GET /samnaugler/auth/ HTTP/1.1
Host: users.pullman.com
Authorization: Basic c2hhd25ob2dhbjpPcHRpZ29sZA==

<enter> <enter>

HTTP/1.1 200 OK
Content-Length: 7
Content-Type: text/html
Last-Modified: Wed, 30 Aug 2006 16:06:51 GMT
Accept-Ranges: bytes
ETag: "cdd7254e4eccc61:2f3"
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
Date: Wed, 30 Aug 2006 17:28:57 GMT

Success


(The same base64 username/password converter works against a Windows 2000 web server, as, of course, do my Optigold http scripts.)

 

Well...I got a packet sniffer going on my box too and I am sending the exact same string.

I upgraded to the lastest java and was able to change the error to:

ERR: Error loading URL: Server returned HTTP response code: 400 for URL

...different from < h1> Bad Request </h1 > but still no joy.

Some chance you are using an XP box for your test and can discern the java version?

 

The download file is called jre-1_2_2_007-win.exe for Bad Request and j2re-1_4_2_12-windows-i586-p.exe for "Error loading URL".

Sam - FSI