Re: Cached Logon
From: Roland Hall (nobody_at_nowhere)
Date: 12/23/04
- Next message: Roland Hall: "Re: Cached Logon"
- Previous message: Roland Hall: "Re: Cached Logon"
- In reply to: Roger Abell: "Re: Cached Logon"
- Next in thread: Ken Schaefer: "Re: Cached Logon"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 22 Dec 2004 19:35:46 -0600
"Roger Abell" wrote in message
news:%23yW0kBD6EHA.2124@TK2MSFTNGP15.phx.gbl...
:
: "Roland Hall" <nobody@nowhere> wrote in message
: news:OqNjkx%235EHA.3736@TK2MSFTNGP10.phx.gbl...
: > "Ken Schaefer" wrote in message
: > news:Oo7Cj695EHA.2608@TK2MSFTNGP10.phx.gbl...
: > :
: > : "Roland Hall" <nobody@nowhere> wrote in message
: > : news:uaDiFu95EHA.1596@tk2msftngp13.phx.gbl...
: > : > "Ken Schaefer" <kenREMOVE@THISadopenstatic.com> wrote in message
: > : > news:uBfCwRi5EHA.3756@TK2MSFTNGP14.phx.gbl...
: > : > : Hi,
: > : > :
: > : > : Your browser is caching the credentials, and resending them for
each
: > : > : subsequent page request to that server (until the browser is
: closed).
: > : >
: > : > The cache was cleared and the browser was closed and still it failed
: but
: > I
: > : > was prompted each time for credentials but only for the first page.
: > :
: > : I think you are completely missing the point, or I am not
understanding
: > what
: > : you are saying.
: > :
: > : When the browser connects to "firstpage.asp", it first attempts to
: connect
: > : anonymously (sending no credentials). The webserver sends back a 401
: > header
: > : (Access Denied) and lists available authentication mechanisms via
: > : WWW-Authenticate HTTP headers.
: > :
: > : The browser then prompts the user to supply credentials (or, in the
case
: > of
: > : IE, if the website is in the local intranet security zone, will
attempt
: to
: > : send the current logged on user's credentials automatically). The user
: > : supplies their credentials, and the browser sends them to the server.
If
: > the
: > : credentials are acceptable, the server sends back a 200 OK status.
: > :
: > : The browser then continues to reuse those credentials for subsequent
: > : requests for pages on that site. This is why (I suspect) you are not
: > seeing
: > : credential prompts on subsequent pages. You can not "clear" this cache
: per
: > : se. Instead, when you close the browser completely, the browser
: "forgets"
: > : the credentials it has been using. When you open the browser again
: (well,
: > : technically you need to start a new iexplore.exe process) and hit the
: site
: > : again, you will once again be prompted for credentials
: > :
: > : > : In terms of the login failure - can we see the exact error message
: > that
: > : > : you are seeing please?
: > : >
: > : > Error Type:
: > : > Microsoft OLE DB Provider for SQL Server (0x80040E4D)
: > : > Login failed for user 'sa'.
: > : > /msft/StraightASP.asp, line 7
: > :
: > : Well, for some reason SQL Server thinks that the password being
supplied
: > by
: > : your ADO connection object is not correct for the "sa" account.
: > :
: > : This doesn't have anything to do with IIS caching a logon (for the
: > purposes
: > : impersonating an NT account for processing an ASP page), or with HTTP
: > : authentication between the client and server, which is what your
: original
: > : post seemed to be talking about. This seems to be an authentication
: issue
: > : between your ADO components and SQL Server.
: > :
: > : That said, if you've cut-n-pasted the code from one working page to
: > another
: > : page, that does seem "out of the norm". Just as a trial, could you put
: the
: > : connection string into an include file, and include that into your two
: > : pages, and then use the connection string from the include file? That
: > would
: > : probably eliminate some odd non-printable character (or something
: similar)
: > : being in the connection string. Both pages should either work, or not
: > work.
: >
: > Ken...
: >
: > I provided the link at MSFT where I got the files. You can see for
: yourself
: > there are no non-printable characters. Again, this is not my code.
Also,
: I
: > cannot reproduce the problem now that the server has been rebooted.
: You're
: > also apparently excluding the other particulars.
: >
: > If the sa logon fails, it should fail no matter which file is trying to
: > authenticate as long as that code is the same. Renaming the file, makes
: it
: > work. Renaming it back to the original name makes it fail once again.
:
: This is the most perplexing part. And, as you mentioned in post of the
: other
: subthread, you could close all IE processes, start again, and see the same
: pattern (prior to the rebooting). That the file name should be so
important
: is not simple to understand, and makes it sound as if there was a
corruption
: in IIS's caching of the file involved.
Is bouncing the box the only way to clear the IIS cache?
-- Roland Hall /* This information is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. */ Technet Script Center - http://www.microsoft.com/technet/scriptcenter/ WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp MSDN Library - http://msdn.microsoft.com/library/default.asp
- Next message: Roland Hall: "Re: Cached Logon"
- Previous message: Roland Hall: "Re: Cached Logon"
- In reply to: Roger Abell: "Re: Cached Logon"
- Next in thread: Ken Schaefer: "Re: Cached Logon"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
