Re: BASIC authentication Issues with IE - Part II - Solved but WHY?
From: Ken Schaefer (kenREMOVE_at_THISadOpenStatic.com)
Date: 03/27/04
- Next message: Ken Schaefer: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Previous message: Ohaya: "Re: IIS5 - Is CRL checking enabled by default - do I need it?"
- In reply to: hector: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Next in thread: Ken Schaefer: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Reply: Ken Schaefer: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Reply: hector: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 27 Mar 2004 13:03:49 +1100
Hi,
"hector" <nospam@nospam.com> wrote in message
news:%23LvMZq0EEHA.4080@TK2MSFTNGP09.phx.gbl...
: Ken,
:
: > b) Some of the stuff you have posted is a little incoherent. I suggest
you
: > download Ethereal (www.ethereal.com), and put a trace on the network to
: > see what's going on.
:
: Not necessary. We have complete control of the Request and Response
: logging. The only think the packet sniffer will offer is possibly looking
: at a TCP reset issue, but that is not whats going on here. See the HTTP
: REQUEST and RESPONSE logging below to show you whats going on.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The benefit of a network trace is that the network sniffer is independant of
the applications, and thus can tell you what's actually going across the
network, not what the application thinks it's sending. however, this does
not seem to be an issue here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: > c) What should happen: if you authenticate to a website, then IE should
: > continue to send your username/password to the website until the browser
: > is closed -or- the website says that those credentials are not
acceptable.
: > Some users check the "remember password" option, but forget that
: > they did so.
:
: Doesn't apply. Do you get a moment to try what I did? I just got a
: report from beta tester saying this is known problem with ASP when you
: switch domains, local machine (default file home page) to a web domain.
He
: said he reported to Microsoft last year.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the beta tester told you this, then I think he/she doesn't know what he's
talking about:
a) it is up to the browser to send the credentials. ASP has nothing to do
with it. ASP runs internally on the server. If the browser is not sending
credentials to IIS, then I don't see how ASP has anything to do with it. The
browser doesn't know anything about ASP (or CF, of PHP, or anything).
b) Switching domains? The browser will only continue to send credentials to
a server where it has already been required to provide credentials. Not to
all servers. So, if I go to server1.com and I need to enter credentials, the
browser will not send the credentials to server2 automatically. It'll only
send them for subsequent requests for resources on server1. Now:
- I don't see what the default homepage has to do with the local machine
security zone. The default homepage can be anywhere, including webpage on a
webserver in the Internet zone.
- When switching from a domain to another domain (nothing to do with IE
security zones), IE will not automatically send credentials.
OK, now's where things get a bit interesting. I tried doing what I think
you're doing:
a) create a page on myserver.com (page1.asp) which requires Basic
authentication.
b) create some links on the page - one link points to page2.asp on the same
server. Page2.asp also requires Basic Authentication
c) Goto page1.asp, enter username/password, get access to page1.asp
d) Click on the link to page2.asp, but choose "Open in New Window". IE
automatically sends credentials, and I'm giving access.
e) Now, I close the second window, and return to my first window. I click
the link to page2.asp again (but without choosing "open in new window"). IE
sends by credentails, and I'm logged in fine.
I verified this using Ethereal, to see the actual HTTP requests. I used IE
v6.0.2800.1106.xpsp2.030422-1633
Now, I looked at your request logging, and it seems something is going on -
the second request should maintain the credentials assuming you are using
the same browser window as before.
Now, you seem certain that this is a bug. I would call Microsoft PSS
(Product Support Services), and open a call to debug the issue. Certainly
it's a not common problem (otherwise lots of people be having problems with
Basic Authentication), and it doesn't manifest itself on my copy of IE, nor
any other copy of IE that I've had before. If there is a bug in IE that you
are using, then you will not have to pay - it'll be fixed for free by
Microsoft.
Cheers
Ken
: Here is the summary of the request and response (I cut out what is not
: necessary). using my local machine web server.
:
: -------Request-----------
: GET / HTTP/1.1
: Host: hdev1
: Connection: Keep-Alive
:
: -------Response----------
: HTTP/1.0 302 Found
: Server: Wildcat/v6.0.451.1
: Location: http://hdev1/public/
: X-Powered-By: Wildcat.Net
: Content-Type: text/html
:
: Here the unauthenticate request come in and the web server redirect it to
a
: public folder home page with a login link.
:
: -------Request-----------
: GET /login?mode=HTML HTTP/1.1
: Referer: http://hdev1/public/default.htm
: Host: hdev1
: Connection: Keep-Alive
:
: Here I clicked on the LOGIN link.
:
: -------Response----------
: HTTP/1.0 401 Unauthorized - user not logged in
: Server: Wildcat/v6.0.451.1
: Cache-Control: no-cache
: X-Powered-By: Wildcat.Net
: Content-Type: text/html
: WWW-Authenticate: basic realm="Santronics Research"
: Date: Fri, 26 Mar 2004 05:02:30 GMT
:
: A 401 response is sent with a WWW-Authenticate header. This will tell the
: browser to popup the login dialog.
:
: -------Request-----------
: GET /login?mode=HTML HTTP/1.1
: Referer: http://hdev1/public/default.htm
: Host: hdev1
: Connection: Keep-Alive
: Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
:
: The browser pops up the dialog and I log in. The authorization line is set
: by the browser and then it reissues the login request back to the server.
:
: -------Response----------
: HTTP/1.0 302 Found
: Expires: Mon, 01 Jan 1990 00:00:00 GMT
: Last-Modified: Fri, 26 Mar 2004 15:39:12 GMT
: Server: Wildcat/v6.0.451.1
: Location: http://hdev1/default.wct
: X-Powered-By: Wildcat.Net
: X-BBS-Name: Santronics Research
: Content-Type: text/html
: Date: Fri, 26 Mar 2004 10:39:12 GMT
:
: The server now redirects the user to the authenticated login folder,
: /hdev/default.wct which it will request from the server. No need to show
: these details.
:
: However, at this point I am logged in and I have lots of links, one is a
: "who is online" link client?who.wcn, which I will open this up in a second
: window.
:
: -------Request-----------
: GET /client?who.wcn HTTP/1.1
: Referer: http://hdev1/default.wct
: Host: hdev1
: Connection: Keep-Alive
: Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
:
: The authorized request is made for /hdev1/who.wcn
:
: -------Response----------
: HTTP/1.0 200 OK
: Last-Modified: Fri, 26 Mar 2004 15:41:05 GMT
: Server: Wildcat/v6.0.451.1
: Cache-Control: no-cache
: X-Powered-By: Wildcat.Net
: X-BBS-Name: Santronics Research
: Content-Type: text/html
: Date: Fri, 26 Mar 2004 10:41:06 GMT
:
: The request came in for the who.wcn and the response was a successful 200
: response.
:
: What is important here is the the WHO.WCN request was authorized!
:
: Now I am going to close the WHO IS ONLINE window and try the request
again.
:
: -------Request-----------
: GET /client?who.wcn HTTP/1.1
: Referer: http://hdev1/default.wct
: Host: hdev1
: Connection: Keep-Alive
:
: Notice that this time there is no authorization and the request was made
: from the original authenticated login page at /hdev1/default.wct. This is
: IMPOSSIBLE state to be in unless the credentials was lost.
:
: -------Response---------- size: 335 time: 70
: HTTP/1.0 401 Unauthorized
: Expires: -1
: Last-Modified: Fri, 26 Mar 2004 15:43:52 GMT
: Content-Length: 230
: Server: Wildcat/v6.0.451.1
: Cache-Control: no-cache
: X-Powered-By: Wildcat.Net
: Pragma: no-cache
: Content-Type: text/html
: WWW-Authenticate: basic realm="Santronics Research"
: Date: Fri, 26 Mar 2004 10:43:52 GMT
:
: and the server sends once again the 401 response because the request for
: who.wcn was not authenticated!
:
: This is a IE bug that has continued for many years. Why can't Microsoft
: come straight once and for all with this? What in the hell is going on?
: There is no consistency.
:
: Anyway, thanks for your input.
- Next message: Ken Schaefer: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Previous message: Ohaya: "Re: IIS5 - Is CRL checking enabled by default - do I need it?"
- In reply to: hector: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Next in thread: Ken Schaefer: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Reply: Ken Schaefer: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Reply: hector: "Re: BASIC authentication Issues with IE - Part II - Solved but WHY?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|