Logging out of a SSL / https:// site using PHP? (or JS?), Client Side Cache

[scubak1w1]

Hello,

I have a series of web sites which use https:// authentication (using AD
integration to 'check the credentials' as it were) - all seems to be working
well...

I have been Googling et al. for a way to log the user off the site
"fully"...

I can do a series of things on the server side per Dreamweaver's Server
Behaviour / User Authentication | Log Out User, etc - but the client's
browser cache (?) still keeps the credentials, and so if they return to the
site (say, with their back button) they can get right back in... the only
sure fire way that I can see, simply, is to close and reopen the browser.


Any thoughts on how to clear the user's browser's cache of a https:// site's credentials and then send them on to a non-secure page?


I thought of:

a.. closing and reopening the browser with some JS, if this is indeed
possible - buT I would need to somehow keep track of what other pages the
user had open, their security settings might now allow it, the user would
likely get annoyed (!), etc, etc

b.. "forcing" a 401 or 403 - but my attempts at 'coding' this were
unsuccessful - and also how do you get the page to redirect on to something
like www.adobe.com or something (because seeing a 403 'standard page
message' would likely be "alarming" to the average user

c.. I have some code in ASP that will do this, but the user would be have
to be limited to using Internet Destroyer - ugh! :-)

Thanks In Advance:
GREG...

Note: cross-posted to the JavaScript in case this is better solved using that, being client side and all... trust this is OK etiquette?

[gregerly]

I think this is going to depend on how exactly your tracking that your user is "logged in". SSL shouldn't have anything to do with your users logged in status. Typically, a user would log in and a flag of some sort would be set that says the user is logged in. Cookies and sessions come to mind. When the user logs out, simply kill the cookie and or session. Validate the credentials each time the page loads. You should be able to avoid the browser cache problems this way.

[Markus]

Greg's right. Every page should be checking that the user is logged in, via a cookie, or whatever.

Even if the user were to hit the back button, they could do nothing malicious because any activity would cause the page to reload or a new page to be loaded, which would then check for a cookie that has been deleted via your logout.

- mark.

[scubak1w1]

OK, I will go back and reread...

My understanding was that SSL aka https was taking care of the credential checking using, in our case, Active Directory user entries - and that PHP was just grabbing the UID from that source - for instance, what I do is:

//grab the logged on user, depending on whether they logged on with the domain prepended
  if(substr_count($_SERVER['REMOTE_USER'],"\\") != 0)
   {
    //the logon has a domain prepended before the 'actual' UID
    list($logged_on_domain, $logged_on_user) = split('\\\\', $_SERVER['REMOTE_USER']); //grab the logged on user off the IIS server variable/s, and split off the (presumed) "[domain]\" portion and essentially discard <--NOTE USE OF FOUR(4)backslashes as needs to be *double escaped*
   }
   else
   {
    //no domain (assume) prepended before the back slash, so just the 'actual' UID
    $logged_on_user = $_SERVER['REMOTE_USER'];
   };

I can set $_SERVER['REMOTE_USER'] = 'baddomain\baduser' of course - but when I return to the secure page the user's browser cache (?) has reset $_SERVER['REMOTE_USER'] to be their previously logged on user name - so they are still logged in...

So maybe my "logging off" question is not really PHP-specific? Hmmm....

I will go back and reread various pages (paper and online) with your suggestion/s as the context - so thank you...

Regards,
GREG...

[gregerly]

The $_SERVER variable is a bad way of doing any kind of authentication. I would suggest you really look into how you authenticate your users and overhaul your existing system. The $_SERVER variable can be manipulated on the client site believe it or not, which makes it an unsuitable choice for authentication.

Maybe I'm not understanding how you arrived at your current system. You need to know that SSL (https) is simply a way of encrypting a page as it travels from the server to your browser. Nothing more. It has nothing to do with a users current "logged in" state.

The typical progression is a user has a record in some sort of user table. When a user tries to login by providing the username and password, the system checks is a user with that username and that password exist. If it does, it means the user is valid and some sort of flag is set usually with a session.

session_start();
$_SESSION['logged_in'] = true;

Then on each page you want to be only available to a logged in user you need to run a routine that checks to ensure the logged in flag is set:

if($_SESSION['logged_in'] == true){
    //show them the protected page
    //this could be an ssl page, or not, example
    header('Location:https://mydomain.com/protected_page.php');
}else{
    //redirect somewhere else
}

As you see above, the SSL only comes into play if you want the page encrypted, but has nothing to do with how the logged in status works. The above example is overly simple, but illustrates the point. Tweak it for your own site.

Hope I'm on the right track, if not post back here and we'll get you moving in the right direction.

Greg

[scubak1w1]

Thanks Greg for the background... Sorry about the delay in replying, it has been a busy week...

(FYI - I am a geologist/scientist who has moved into data management, GIS, web mapping, etc, etc - hence my need to learn all of this as I go, the IT staff being so overwhelmed, and also mainly Windows network admins - so bear with any "silly questions"... <smile>)

Regarding SSL - That distinction is useful to know / be reminded about, thank you - since IIS integrates SSL and AD transparently to me as a non-IT-admin person, I guess I was not making that distinction clearly enough mentally...

I am writing functionality for the company intranet - and am using AD, as so I don't have to sync credentials on "my" system with the 500± users in the AD... (i.e., when someone leaves the company, new hires, password changes, etc, etc) - and not forgetting that users may use the intranet site from the company internet site on PCs not logged on to the network... (say when they are on the road and suing an internet cafe? (sic))

AD has been in use on the intranet for site logon verification (sic) since before I got here - but the network admins did not look into how to log some one off as the site was a simple & clean one... (i.e., there was not much of value there, so the risk was low as they perceived...)

Now HERE is where I think I have having the issues... Using a "log off" link, I can use PHP to log them off "my" site, server side, and hence "demand" to see their AD credentials again...

BUT from my reading and understanding (and inexpert (!) experimentation), the browser seems to be caching the "previous" AD credential info - and so when it "sees" the request for AD credentials from the server (?), it 'says' "oh, I have those from a few minutes ago, here you go..." (i.e., the same browser session on the clients side if they haven't closed their browser in the
meantime...), thereby re-logging them on server side directly (i.e, the user is NOT asked for their credentials again...)

So (assuming I have this right) is there a way to have PHP clear the user's
browser cache of the appropriate AD credentials if the user is in the same
browser session and then move to, say, www.google.com? Or should I be looking at some JS? (if they have closed the browser it is of course a moot point...)

I thought about "forcing" a 401, 403 or similar, but (i) how to so this programmatically?, and (ii) how to send them on to, say, the aforementioned www.google.com directly?

Or expending my efforts on other 'projects'? <smile>