Thanks for the idea, John.

I know about the auth logout.  Unfortunately, that means that when a user clicks 
"logout", he gets a "log in" prompt!  And, in IE, he has to deliberately blank out the 
password field, THEN hit enter, THEN the prompt will come again, and he has to hit 
escape.

There's another possible path than the above, but it, too, involves a prompt coming up 
when they hit logout, and they have to clear the password field.

If, when they click "logout", and they get the first confusing "log in" prompt, they 
click "cancel", then they won't be logged out.  The browser will continue to remember 
and report their username and password.

Try explaining how to follow these instructions to an inexperienced user!

The point of my system was to use, among other things, the session cookie to determine 
whether the user is in a new session or the same one as before.  The logout button 
sets a flag in the database.  In short, then I know, when the user's browser tries to 
log in again, if he's in the SAME session, and he had previously hit logout, then I 
will have to send an auth header, with a new realm.  But if he's in a NEW session, 
then I can assume his browser no longer remembers his user/pass, so the actual user 
must've typed it, so here I will let the user proceed without sending an auth header.

If IE 5.5 refuses to clear the user/password field, and refuses to clear the session 
cookie, then I can't think of any way of him getting to log out without making him go 
through an annoying second "enter your username and password" prompt...which is most 
disappointing.

It's sounding like, thanks to this terrible behavior of IE 5.5, I may have to switch 
to not using browser authentication at all, and instead deal with the nuisance or 
security risk of passing along authentication information in the session, and 
requiring the user to click "logout" when it's time to logout (forcing a destruction 
of the information stored in the session).

Any suggestions?

- Ken

At 09:45 PM 3/3/01 -0600, John Henckel wrote:
>I, too, am using PHP with authentication and IE 5.  However I am using .htaccess to 
>generate the headers instead of PHP.  I found this text...
>
>a quote from PHP manual.....
>>Both Netscape and Internet Explorer will clear the local browser window's 
>authentication cache for the realm upon receiving a server response of 401. This can 
>effectively "log out" a user, forcing them to re-enter their username and password. 
>Some people use this to "time out" logins, or provide a "log-out" button.
>
>This doesn't answer Ken's question, but at least perhaps you can use it to provide a 
>"log-out" button.  Let me know if it works or not.
>
>At 09:57 PM 3/3/01 -0500, kenzo wrote:
>>I'm experiencing strange behavior with my user authentication scheme in my PHP app, 
>with users using IE 5.5.
>>
>>I am using browser authentication (WWW-Authenticate and 401 headers), "no cache" 
>headers, and PHP 4 sessions.
>>
>>I am finding that even when the user totally quits IE, if he then restarts IE, one 
>or both (haven't isolated for sure yet) of the following happen:
>>
>>- The browser still knows the user and password, and so will send it to the server 
>upon an authentication request under the same realm, without prompting the user.  
>(The user does NOT have "save this password" checked on the user/password prompt when 
>it first comes up.)
>>- The session is still active.  A call to session_start() returns the pre-existing 
>session, instead of getting a new one.
>>
>>If the user restarts his machine, IE no longer remembers his user and password, and 
>so a prompt is displayed upon authentication headers being sent.  And I presume (not 
>100% certain) that a new session gets created.
>>
>>Both of these are behaving like IE is still running.  Is this a known issue with IE 
>5.5?  Does it just stay running?  These symptoms make it sound like this, and less 
>like a logic problem in my PHP app.  (I have verified that the username and password 
>are sent when the user gets an authentication prompt, without the user typing 
>anything.  I'm assuming there's no possible way that a PHP session can retain this 
>information; I am reading $PHP_AUTH_USER and $PHP_AUTH_PW...there's no way these can 
>be set unless the browser were already running and the user had previously entered 
>them into their prompts, right?)
>>
>>Has anyone else run into this?  My application works perfectly under Netscape 4, IE 
>4, and Opera 5.
>>
>>Thanks,
>>Ken


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to