Ive found the same thing and currently do not have a workaround, it seems
that browsers cache this. one method Ive thought of and never tested is to
set a session variable, cross reference that SessionID, PHP_AUTH_PW,
PHP_AUTH_USER are all valid, if not then your not loged in correctly. to log
out just unset SessionID. any future pages will not load. even if the
PW/USER are valid the Session wouldnt.

If the browser has cookies disabled, you have compiled php with --trans-sid,
and the user uses the back button the user would still be able to view
cached pages. you might want to put some fancy no-cache headers in there
somewhere and hope the browser supports them.

you might even want to impliment a time based system, set the SessionID =
time() on every header; but first check if the current SessionID < 30min old
then invalid login vs updateing SessionID to equal current time()

This would prevent anyone from viewing cached pages more then 30min old and
force them to re-login....

--


Chris Lee
Mediawaveonline.com

em. [EMAIL PROTECTED]

ph. 250.377.1095
ph. 250.376.2690
fx. 250.554.1120





""Toby Miller"" <[EMAIL PROTECTED]> wrote in message
006901c0969f$cfcf2700$[EMAIL PROTECTED]">news:006901c0969f$cfcf2700$[EMAIL PROTECTED]...
> Sorry, I meant common header, not footer.
>
> Inside my common "header" on my site ......
> (which also includes the same "header") .......
>
> ----- Original Message -----
> From: "Toby Miller" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 14, 2001 10:37 AM
> Subject: [PHP] HTTP Authentication not getting unset
>
>
> Hey all,
>
> New problem. I really hope there's something simple to do to fix it. Check
> out this scenario and tell me if there's a step that I'm missing.
>
> Inside my common footer on my site the very first call is to an include
> called UserAuth.inc.php.
>
> UserAuth.inc.php checks $REQUEST_URI to see if the present directory or
URL
> is protected or not.
>
> If it is protected then it checks to see if $PHP_AUTH_USER is set. If it
is
> then it runs through the usual HTTP Authentication. If it fails it goes to
a
> failure page, if it succeeds then it logs the user in.
>
> Now I can surf around on the site and that same authentication will
continue
> to be used for the rest of the site where ever another protected directory
> or file is found (as to be expected).
>
> Now to logout I have a page called logout.php. If you go to this page
(which
> also includes the same footer) there is another action that takes place.
>
> If the $REQUEST_URI contains logout.php then I print the same "401" header
> that I print for authentication and unset $PHP_AUTH_USER, $PHP_AUTH_PW and
> $AUTH_USER. $AUTH_USER is the user authentication object in my class file
> UserAuth.class.php. I'm just unsetting this so that no code will still
have
> record of the old authentication object to do anything with.
>
> Now if I try to read the $PHP_AUTH_USER or $PHP_AUTH_PW variables anyplace
> on the site they don't exist, until I go back to one of the protected
pages.
> Then they miraculously re-appear and are readily available once again
> without requiring the user to log back in.
>
> If you've got any ideas, suggestions, guesses or references, please reply.
> I've run out of ideas. I can also provide the code that I'm using if you
> think it might just be a problem with my logic. I don't think this is the
> case as I shouldn't be able to read any variable that has been unset, but
> like I said, I'm running out of ideas.
>
> System: RedHat 6.1-6 i686 Kernel 2.2.13
> Server: Apache 1.3.12
> PHP: 4.0.3pl1
>
> Thanks,
> Toby
>
>
>
>
> --
> 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]
>



-- 
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