Porter,
I haven't come up with a solution yet, but here's some more info on
how this should work, to try and inspire some more ideas...
SUMMARY: In my tests of authenticated content, read url works, but
read [block] doesn't. I'm not using IIS, however...
SUGGESTION: Try using a browser on a different box than the one IIS
is running on, or check your proxy settings and try using
http://webuser:letmein@localhost/mysite/
instead of 127.0.0.1 or, if you have DNS, try using your box's
hostname for your box.
Because of my proxy settings, Netscape referrs 127.0.0.1 to my
configured proxy server (which obviously failed!), but would
allow me to use localhost or the DNS hostname.
None of this gets in the way if you just use a browser on another
box, as you'll have to identify your web server box with a real IP
address or hostname.
-jn-
[EMAIL PROTECTED] wrote:
>
> here's the results of turning on the trace...
>
> >> trace/net on
> >> do %getsecurepage.r
> Script: "Secure Page Retreival" (25-Jan-2000)
> http://webuser:[EMAIL PROTECTED]/mysite/
> URL Parse: webuser letmein 127.0.0.1 none mysite/ none
> Net-log: ["Opening tcp for" HTTP]
> connecting to: 127.0.0.1
> Net-log: {GET /mysite/ HTTP/1.0
> Accept: */*
> User-Agent: REBOL 2.2.0.3.1
> Host: 127.0.0.1
> Authorization: Basic d2VidXNlcjpsZXRtZWlu
>
> }
> Net-log: "HTTP/1.1 401 Access Denied"
> ** User Error: Error. Target url: http://127.0.0.1/mysite/ could
> not be retrieved. Server r
> esponse: HTTP/1.1 401 Access Denied.
> ** Where: print read http_file
>
> To me - it looks like REBOL simply parses out the username:password
> from the URL. But I'm not sure what the results of the trace mean.
>
Here's what happens:
1) If a browser tries to hit a page/directory/site requiring user
ID authentication (and it doesn't know that in advance), the
server returns a 401 error message.
2) Without telling you of the failure (yet), the browser pops up
the normal userid/password dialog.
3) When you OK that dialog, the browser simply hits the server
for the same page again, but adds to the request headers an
"Authorization" header. In your example from trace/net, we
can see that REBOL appears to be doing this correctly. The
request, complete with headers (and the required blank line
at the end of the header block), is the multi-line string
contained in
Net-log: {GET /mysite/ HTTP/1.0
Accept: */*
User-Agent: REBOL 2.2.0.3.1
Host: 127.0.0.1
Authorization: Basic d2VidXNlcjpsZXRtZWlu
}
The BASIC authorization scheme is the one defined in HTTP/1.0;
it calls for header keywords "Authorization: BASIC " followed
by the base64 encoding of a string containing userID, colon,
and password. This is clearly working correctly as well;
>> to-string debase "d2VidXNlcjpsZX
== "webuser:letmein"
If you get a 401 at this point, the browser keep asking you
to try again until you cancel, at which point you get the
401 error message.
4) Once your browser has authenticated you to a site, it knows to
keep doing so without bothering you to rekey the userID/password
for every page -- until you shut the browser down, that is.
>
> I can see that the Authorization chalenge comes up - the little box
> that pops up in your browser when accessing a password protected
> resource is referred to as "Basic Authentication" - not just in
> Microsoft's parlance.
>
Actually, what you're seeing is the authentication header that REBOL
knows to include (without waiting for a 401 from the server) because
you included a userID/password in the URL. You're correct that
"Basic Authentication" is HTTP standard terminology, not dependent
on the browser vendor.
>
> So - I'd say the server is responding appropriately - but that
> REBOL isn't reacting to it correctly, and not handing it the
> username and password...
>
The server is balking. For some reason the authentication header
(which REBOL *did* include, according to your trace/net output)
was not accepted.
I've just used REBOL to hit a secured page I can access. With
names changed to protect the innocent, the trace/net output was
>> myurl: make url! "http://USER:[EMAIL PROTECTED]/admin/"
== http://USER:[EMAIL PROTECTED]/admin/
>> trace/net on print read myurl trace/net off
URL Parse: USER PASSWORD neely.FOO.com none admin/ none
Net-log: ["Opening tcp for" HTTP]
Net-log: {GET http://neely.FOO.com/admin/ HTTP/1.0
Accept: */*
User-Agent: REBOL 2.2.0.3.1
Host: neely.FOO.com
Authorization: Basic VVNFUjpQQVNTV09SRA==
}
Net-log: "HTTP/1.0 200 OK"
Net-log: ["low level read of " 4132 "bytes"]
<HTML>
<HEAD><TITLE>Xitami Administration</TITLE></HEAD>
<BODY onLoad="focus()"
BGCOLOR="#87CEFA" LINK="#FFFF99" VLINK="#CCFFFF" ALINK="#FF9900">
.
. several yards of HTML source deleted for space...
.
<TD ALIGN=CENTER><FONT SIZE=-1>Copyright © 1996-99 iMatix
Corporation
<BR>Powered by iMatix Studio 1.0
<TD ALIGN=RIGHT><FONT SIZE=-1>25 January, 2000 12:25
<BR>Xitami v2.4d3
</TABLE>
</BODY></HTML>
>>
OTOH, when I tried to use the second technique you mentioned, I got
>> trace/net on
>> print read [
[ scheme: 'http
[ user: "USER"
[ pass: "PASS"
[ host: "neely.FOO.com/admin"
[ ]
Net-log: ["Opening tcp for" http]
Net-log: {GET http://neely.FOO.com/admin/ HTTP/1.0
Accept: */*
User-Agent: REBOL 2.2.0.3.1
Host: neely.FOO.com/admin
}
Net-log: "HTTP/1.0 401 Unauthorized"
** User Error: Error.
Target url: http://neely.gos.fedex.com/admin/ could not be
retrieved. Server response: HTTP/1.0 401 Unauthorized.
** Where: print read [
scheme: 'http
user: "USER"
pass: "PASS"
host: "neely.FOO.com/admin"
]
Looking at the trace/net output, it appears that REBOL did NOT add
the authentication header for this technique. Therefore, the 401
was correct.
We're using the same version of REBOL, so I don't think that's
the problem. See the suggestions above re using localhost or a
real hostname instead of the generic 127.0.0.1 IP address.
-jn-
