Forum Moderators: coopster
Then I have a script which checks for that cookie.
Called from target pg:
include('functions.php');
$USERNAME = AuthorizationCheck("pagename.php");
Located in the functions page:
function AuthorizationCheck($page)
{
$USERNAME = $_COOKIE["authorized"];
if(!$USERNAME)
{ if($page=='some_text')
//redirect to login page in appropriate directory relative to the $page location
}
return $USERNAME;
}
This seems to work pretty well for me in IE. I have problems with the cookie being destroyed through my logout function (below) in FireFox and Safari. Also, the cookie isn't destroyed if the person closes the window without closing the browser application entirely. Closing the browser application entirely always seems to destroy the cookie.
function Logout()
{ $authorized = $_COOKIE["authorized"];
if($authorized)
setcookie("authorized", "", time()-60000,"/"); //this just sets the cookie to a negative time value thus destroying it
//redirect to login page
}
Because of this inability to destroy the cookie, the next person who logs in will see the information from the last person who was logged in on that computer.
Is this a decent way of user authentication? Can you suggest ways in which I can handle the cookie better in general, or specific fixes for FireFox and Safari. I don't know if they just handle cookies differently or if IE just guesses well in this area.
Maybe some discussions about $_SESSIONS would be helpful as well? I honestly don't know how to use that superglobal, and the information that it can provide.
Thanks for any help you can provide,
Josh
PS How do you get the 'code' section to work on my posting (instead of showing the code as normal black text)?
$_SESSIONS can use cookies too. So, you'll still be in the same boat. If the user doesn't LOGOFF so you can do a session_destroy(), and they don't close their browser, then the next user can walk up and use their LOGGED IN status to do as they please. Workarounds may be something like a timestamp monitor to allow inactivity for certain periods of time, etc. As a matter of fact, PHP has a configuration directive specifically for this in it's Session Handling functions [php.net].
P.S. I don't usually use the *code* tags. I use *pre*, but if the text is too long it will cause the side scroll to kick in, so when that occurs I'll use *fixed*. Also, anytime there are whitespaces between sentences, the formatting seems to get a little quirky, so I tend to not have any whitespaces (empty lines) between paragraphs -- if I do, I close the previous *pre* block and start a new one.
As usual, thanks for your cross reference. I haven't yet read it, but I will.
One further point of clarification: my login page first calls the logout function upon loading. So in theory, the lingering cookie should be destroyed before the next user successfully logs in and creates a new cookie.
This works like a charm in IE. But, what I don't understand is why the cookie is still available in FireFox and Safari. I don't do a check_browser function or anything, so the logout code should will be called the same in all browsers. This is what made me think that maybe those browsers handle the cookie destruction differently.
I will read up on those links you gave me. Thanks again,
Josh
...my login page first calls the logout function upon loading. So in theory, the lingering cookie should be destroyed before the next user successfully logs in and creates a new cookie.
But! If the old user didn't logout, and the new user doesn't go to the login page, your logout function isn't doing any good and the new user will be using the lingering cookie.
Side note: I'd put my money on the other browsers before trusting IE to be doing anything correctly ;)