|
Home > Archive > IIS Server Security > March 2004 > Re: BASIC authentication Issues with IE - Part II - Solved but WHY?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: BASIC authentication Issues with IE - Part II - Solved but WHY?
|
|
| hector 2004-03-26, 11:49 am |
| This is so odd.
I can see why this problem was not usually seen by others. On my personal
machine, I have a D:\HOMEPAGE.HTM that I use as a personal list of URLS
customized for me. In it, I have a URL that says:
<a href="http://www.winserver.com"> Support Site </a>
And when I visit my site and log in using Basic Authentication, I can right
click a LINK to open a new window.
Everything is cool until I close the second window, at which point any
further clicking on the main window will require a new basic authentication
login.
Now the weird thing!
If I by pass my local machine homepage menu and simply type the
http://www.winserver.com in the IE address bar, this entire problem goes
away! I can open second windows at the authenticated site with NO problem
of losing the credentials!
Again, my IE is setup so that the default HOME page is d:\homepage.htm and I
use this page as a menu for my custom links among other informative things I
add to it.
If I click the url from the homepage menu, I run into the browser
authentication problem when second windows are open from the authenticated
site.
But if I directly use the URL at the IE address bar, no problem. You don't
lose basic authentication!
Go figure!
Am I seeing things?
Can you repeat this? Just create a simple "c:\homepage.htm" with a few
links in it to an authenticated site, then login via this link and then open
and close a window to see if you have to login again. Then try it directly
from the address bar.
-- hector
"hector" <nospam@nospam.com> wrote in message
news:uYt0k6wEEHA.2088@TK2MSFTNGP10.phx.gbl...
>
> This is the chronological history as we experienced it:
>
> Originally, the only IE issue we had was......
>
> 1) Intermittently, a basic authenticated session is lost when a user
> finishes a download. The next URL clicked requires a re-login.
>
> 2) Intermittently, a basic authenticated session is lost when a user
closes
> a secondary popup window. The next URL clicked requires a re-login.
>
> ...
>
> But now we are about to release a new version of Web Server with new HTML
> pages layouts and I see #1 and #2 constantly.
>
> All we did was add a HELP button to our html pages and when you close the
> HELP window, the Basic Authentication is lost. The user has to relogin
> again! It is 100% repeatable!
>
> What gives? What's going on? I am throwing my hands up. You simply
can't
> kept up with Microsoft and their constantly "design behavior" changes.
>
> What is the basic rules now with IE's Basic Authentication behavior?
>
> thanks for any input you can provide
>
> Hector
>
>
>
>
| |
| Ken Schaefer 2004-03-26, 11:54 am |
| a) If different IE windows are running in separate IExplore.exe processes,
they will not share credential information. Check using Task Manager, and
Process Explorer etc to see what's going on.
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.
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.
Cheers
Ken
"hector" <nospam@nospam.com> wrote in message
news:%23WFow4xEEHA.3976@TK2MSFTNGP12.phx.gbl...
: This is so odd.
:
: I can see why this problem was not usually seen by others. On my personal
: machine, I have a D:\HOMEPAGE.HTM that I use as a personal list of URLS
: customized for me. In it, I have a URL that says:
:
: <a href="http://www.winserver.com"> Support Site </a>
:
: And when I visit my site and log in using Basic Authentication, I can
right
: click a LINK to open a new window.
:
: Everything is cool until I close the second window, at which point any
: further clicking on the main window will require a new basic
authentication
: login.
:
: Now the weird thing!
:
: If I by pass my local machine homepage menu and simply type the
: http://www.winserver.com in the IE address bar, this entire problem goes
: away! I can open second windows at the authenticated site with NO
problem
: of losing the credentials!
:
: Again, my IE is setup so that the default HOME page is d:\homepage.htm and
I
: use this page as a menu for my custom links among other informative things
I
: add to it.
:
: If I click the url from the homepage menu, I run into the browser
: authentication problem when second windows are open from the authenticated
: site.
:
: But if I directly use the URL at the IE address bar, no problem. You don't
: lose basic authentication!
:
: Go figure!
:
: Am I seeing things?
:
: Can you repeat this? Just create a simple "c:\homepage.htm" with a few
: links in it to an authenticated site, then login via this link and then
open
: and close a window to see if you have to login again. Then try it
directly
: from the address bar.
:
: -- hector
:
:
: "hector" <nospam@nospam.com> wrote in message
: news:uYt0k6wEEHA.2088@TK2MSFTNGP10.phx.gbl...
: >
: > This is the chronological history as we experienced it:
: >
: > Originally, the only IE issue we had was......
: >
: > 1) Intermittently, a basic authenticated session is lost when a user
: > finishes a download. The next URL clicked requires a re-login.
: >
: > 2) Intermittently, a basic authenticated session is lost when a user
: closes
: > a secondary popup window. The next URL clicked requires a re-login.
: >
: > ...
: >
: > But now we are about to release a new version of Web Server with new
HTML
: > pages layouts and I see #1 and #2 constantly.
: >
: > All we did was add a HELP button to our html pages and when you close
the
: > HELP window, the Basic Authentication is lost. The user has to relogin
: > again! It is 100% repeatable!
: >
: > What gives? What's going on? I am throwing my hands up. You simply
: can't
: > kept up with Microsoft and their constantly "design behavior" changes.
: >
: > What is the basic rules now with IE's Basic Authentication behavior?
: >
: > thanks for any input you can provide
: >
: > Hector
: >
: >
: >
: >
:
| |
| hector 2004-03-26, 11:54 am |
| Ken,
"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:%23IZcmOzEEHA.240@tk2msftngp13.phx.gbl...
> a) If different IE windows are running in separate IExplore.exe processes,
> they will not share credential information. Check using Task Manager, and
> Process Explorer etc to see what's going on.
Interesting.
Only one IEXPLORE.EXE instance when the second window was opened.
No problem!! Why???
Hmmmm, OH, I had OUTLOOK opened!!! Lets try closing OE and try it again.
Ok, I'm back... Yup! Same problem.
> 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.
> 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.
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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
| |
| Tom Kaminski [MVP] 2004-03-26, 11:54 am |
| "hector" <nospam@nospam.com> wrote in message
news:%23LvMZq0EEHA.4080@TK2MSFTNGP09.phx.gbl...
> -------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.
What are the NTFS permissions on http://hdev1/default.wct?
--
Tom Kaminski IIS MVP
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS
http://mvp.support.microsoft.com/
http://www.microsoft.com/windowsser...ty/centers/iis/
| |
|
|
| Ken Schaefer 2004-03-26, 9:40 pm |
| 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.
| |
| Ken Schaefer 2004-03-26, 10:34 pm |
| :
: 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.
Also, this appears to be a problem with IE, not IIS. From your request
logging, it is IE that's no sending the credentials. Either post the IE
version you are usng, or perhaps follow up this uestiono in one of the IE
newsgroups?
Cheers
Ken
| |
| hector 2004-03-27, 12:34 am |
|
"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:O5kX4c6EEHA.2076@TK2MSFTNGP09.phx.gbl...
>
> Also, this appears to be a problem with IE, not IIS. From your request
> logging, it is IE that's no sending the credentials. Either post the IE
> version you are usng, or perhaps follow up this uestiono in one of the IE
> newsgroups?
>
Hi Ken,
First, I appreciate your interest in providing input. Don't change. Don't
ever change :-)
Second, this is not all new stuff. Do a thorough google search and you will
see this is has been a long time issue with IE that has many ways of showing
up that isn't quite clear.
Third, I tried to be as detail as I can without going over board. That
tends to lose readers. I've very verse on this cyber area. We write mail
products and have more experience than Microsoft in the area. Disseminated
information is par for the course. What that means is the reason I posted
here in the first place was that a recent article in this forum discussion
and describing what same to be "same problem" and it seems that by now the
MVP were getting a good handle on the situation, talking about "Double Hops"
and related items.
Like I said, its a long time issue that has showed up in many ways.
Microsoft has been mum on the issue and there has been no consistency in
technical analysis which btw, also include many man-hours in network
sniffing.
So I was hoping to see if finally, Microsoft has come up with a final and
completely understood analysis on the problem and has finally solve it one
way or another. After all, as I also said, we have customers are now
reporting that the latest IE updates no longer supports the URL syntax of
providing the username:password on the URL. Is that true? If this is
true, then Microsoft has done this for a reason. I would like to know why,
not so much to continue to support it myself, but maybe to see how it
relates to the other Basic Authentication issues.
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
| |
| hector 2004-03-27, 1:34 am |
|
"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:eW33$%235EEHA.3064@tk2msftngp13.phx.gbl...
> Hi,
> 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.
In step c, how do you "Goto Page1.asp"?
Do this by creating a simple Default Home Page with a link to this page1.asp
If you type the url on the IE address bar, you will not see the problem.
> 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.
Ken, this is has been a long time issue. I've been down this route before,
including calling them on the matter and/or related issue where you are not
losing credentials but it was cached and used again automatically in the
Explorer "Previewing" logic. Like I said, this has been an issue for a long
time and I am not the only one. And you know perfectly well, Microsoft is
will be mum on the subject closed related with security. I am just trying
to figure it out once and for all. I'm not a USER, well yeah of course I
am, I am a user of my own creation as well as hundreds of thousands of
user/customers. So we have to satisfy their reports too. But like I
said, for this particular "lost of authentication", I was one of the few
within our own product reporting it and know I find out "how" it happens.
I am going to try one more thing and that is put the URL in the Favorites
likes instead. I can't do it know until I close Outlook and all Microsoft
software that has the IE logic integrated with the INETINFO.EXE credential
caching. PS: Do a search for this and you will see it how its all related,
and how there is difference with XP vs. others, how Microsoft solved the URL
shortcut automatic authentication security hole in XP but not others for
some "legacy reason." Yes, incoherent and all very inconsistent which is
what I am trying to get all straight once and for all.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
| |
| Wade A. Hilmo [MS] 2004-03-27, 12:36 pm |
| Hi Hector,
I've been following this thread for some time. From what I've seen, you
have been given good information and advice so far. I would like to clarify
a few points to try and help you narrow this down.
First and foremost, inetinfo.exe is not integrated with IE in any way. It
is the host process for the IIS web server core. It runs on the server side
and services requests from all HTTP clients without distinction. In other
words, it does not know the difference between a request from IE or from
some other HTTP client. In fact, we have many users of IIS that have
written their own custom HTTP clients that are not browsers in the
traditional sense at all.
Second, the way that IIS handles Basic authentiation is, well, basic. Per
the HTTP spec, a client authenticates by sending an "Authorization" header
in the request. If no authorization header is present, IIS authenticates
the request as anonymous. If an authorization header is present and it
specified Basic Authentication, and IIS is configured to accept Basic, then
IIS authenticates the request as the user in the base64 encoded part of the
authorization header. Some other authentication schemes are more
complicated, but Basic is just this simple.
Third, the credential cache that you keep mentioning has nothing to do with
this issue. The credential cache is a performance optimization. It turns
out that it can be very expensive (in terms of performance) to ask the
operating system to produce a token from user credentials. For this reason,
IIS can sometimes remember the token for a particular set of credentials so
that, if those same credentials come in on another request, we can reuse the
token instead of asking the operating system for a new one. This only
affects where we get the token from, and has no affect whatsoever on whether
we authenticate or not.
Given these three things, I can say with very high confidence that you are
looking at an issue with the client, and it has nothing to do with IIS. As
such, this post is off topic on this newsgroup. I just look a look at the
Microsoft newsgroups in hopes of pointing you to a better place, and
unfortunately, it doesn't look like there is one central IE newsgroup. It
looks like they are pretty well broken up by version. Lots of folks that
read this newsgroup probably have an interest in the client as well, so
hopefully somebody reading this can suggest an active newsgroup with a focus
on IE. In any case, you are not guaranteed a response by Microsoft on a
newsgroup anyway, so your best bet if you want this is to open a case with
product support.
That said, I can think of several scenarios where any client might not
persist - or appear to not persist - credentials between basic authenticated
requests. Note that I know nothing about the internals of IE. My only
experience with IE is as a user, and seeing the HTTP that it puts on the
wire. What follows is just my own personal speculation on this topic. For
definive answers, you should be talk to someone who specializes on IE.
First off, it's very important that the client not forward basic
authenticate credentials indiscriminately. The reason for this is that
basic authentication does not protect the password in any way. If you give
me your basic authorization header, I can base64 decode it in no time and
then I can become you. Because of this, I would expect that no client would
preauthenticate ("preauthenticate" is the term used to say that the client
forwards the credentials without first seeing a 401 from the server) without
having very good reason to believe that the request is going to the same
place as some previous request which successfully authenticated. I would
speculate that the client would consider the target server, and possibly
some part of the URL namespace to make this determination.
Also, the client could, if is chooses, implement some logic to authenticate
without prompting, based on the realm returned in the basic challenge from
the server. In other words, if the server respnse with a 401 and
www-authenticate header for basic, it will include a realm. The client
could then search its own credential cache and see if it has credentials for
that realm without asking the user. I have no idea if IE does this or not.
Finally, I can see some timing scenarios where you might get unexpected
authentication popups on the client. Specifically, if you make a request
that results in a bunch of other requests (ie. if there are frames involved,
if there are frames on the page, if there are 301 or 302 redirections, etc.)
it's possible that the client makes some number of those requests before it
gets back a 401 from any of them. In that case, there is no way that the
client could preauthenticate all of the requests. And even if the following
401 responses all contain the same realm (and the client uses this
information), it's possible that timing issues in a local credential cache
on the client could cause it to prompt for credentials more times that you
think it should.
I would guess that someone very familiar with HTTP could probably explain
the behavior that you are seeing by studying a sniffer trace of the traffic
between the client and server. Note that log files may not be sufficient.
A sniffer trace is going to show you the actual packets that are hitting the
wire, complete with timing information, how the packets are broken up, and
sequence numbers.
Thank you,
-Wade A. Hilmo,
-Microsoft
"hector" <nospam@nospam.com> wrote in message
news:ebwazA8EEHA.1228@TK2MSFTNGP11.phx.gbl...
>
> "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
> news:eW33$%235EEHA.3064@tk2msftngp13.phx.gbl...
>
>
> same
click[color=darkred]
> IE
>
> In step c, how do you "Goto Page1.asp"?
>
> Do this by creating a simple Default Home Page with a link to this
page1.asp
>
> If you type the url on the IE address bar, you will not see the problem.
>
Certainly[color=darkred]
> with
> nor
> you
>
> Ken, this is has been a long time issue. I've been down this route before,
> including calling them on the matter and/or related issue where you are
not
> losing credentials but it was cached and used again automatically in the
> Explorer "Previewing" logic. Like I said, this has been an issue for a
long
> time and I am not the only one. And you know perfectly well, Microsoft is
> will be mum on the subject closed related with security. I am just
trying
> to figure it out once and for all. I'm not a USER, well yeah of course I
> am, I am a user of my own creation as well as hundreds of thousands of
> user/customers. So we have to satisfy their reports too. But like I
> said, for this particular "lost of authentication", I was one of the few
> within our own product reporting it and know I find out "how" it happens.
>
> I am going to try one more thing and that is put the URL in the Favorites
> likes instead. I can't do it know until I close Outlook and all Microsoft
> software that has the IE logic integrated with the INETINFO.EXE credential
> caching. PS: Do a search for this and you will see it how its all
related,
> and how there is difference with XP vs. others, how Microsoft solved the
URL
> shortcut automatic authentication security hole in XP but not others for
> some "legacy reason." Yes, incoherent and all very inconsistent which
is
> what I am trying to get all straight once and for all.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
>
>
>
| |
|
|
|
|
|