Forum Moderators: coopster
Thank You All!
Scenario 1:
User "AA" is a valid user of the site. AA logs in and a cookie is set on his pc. The database is updated to "Logged In". AA then leaves the site by hitting the logout button provided. The database is then updated to "Logged Out". User "BB", having stole the cookie from AA somewhere along the line, comes to the site using the stolen cookie. However, the script checks the database and finds AA has logged out already and redirects BB to the login page. BB's attempt has been thwarted.
Scenario 2:
User "AA" is a valid user of the site. AA logs in and a cookie is set on his pc. The database is updated to "Logged In". AA then leaves the site by closing his browser. Now, there is no call to change his status in the database to "Logged Out". User "BB", having stole the cookie from AA somewhere along the line, comes to the site using the stolen cookie. This time the script finds that AA is "Logged In" and the cookie is a match as well. BB now has access to the site.
Question
Is there a way to tell when a browser is closed and update a database accordingly? It doesn't seem possible to me at this stage in my learning. The script has to be invoked by the user in some fashion. So, if the user closes the browser, the script simply stops. Am I correct in my assumptions?
If I am not correct, maybe someone could give me a breakdown of how php works in the situation of browser closing?
Or, if I am correct, thoughts on how best to stop scenario 2 from happening? I have been reading up on session hijacking and the like and have yet to develope a method that "I think" is safe. From what I have read, there needs to be something that is unique to the user stored in a session or cookie. And I fail to see anything that cannot be reproduced by a would be intruder. Maybe I just need my eyes opened. Or, at minimum, I need to look at this from a different perspective.
Anyway, thank you very much for taking the time to read this. And if you can help out in some fashion, all the better. And to the Gurus at this board, "Keep up the great work you folks are doing!"
IamStang
What comes to mind is a combination of technologies, including AJAX. How would it work?
Maybe a page with AJAX can make a regular call to a database. As long as the page is open that call can be checked. Now something else will have to monitor those database calls, and when one gets missed you can assume one of two things: the user has closed their browser or the connection has been interrupted. That monitor sounds like some sort of cron job to me..
As you can see I haven't worked out the details, and, I don't think anyone else has either. This could be your big chance! Otherwise, I don't think there is a work around for Scenario #2.
Grandpa:
That is an interesting perspective you have on this particular situation. I agree that everytime I think something can't be done by a computer, someone comes along and proves me wrong. LOL. I am still learning the ropes of course and AJAX is unfamiliar to me. I will have to do some research on the subject. Thanks for your thoughts!
Nutter:
Am I wrong to assume that if BB has the cookie of AA, that he can simply change the expiration date inside the cookie? Anyone can open a cookie in a text editor. Would this not nulify the expiration date of the cookie?
More thoughts of mine:
I guess, one could place an expiration date in a database and verify it against BB's cookie. Every page load that AA makes would update the expiration time, thus making BB's window of opporitunity smaller. But the window is still open, if only for a few minutes. I guess, until I (or someone else) comes up with a better solution, this is the method I will incorporate. I will set a reference id in a cookie with an expiration time. Then record the expiration time in the database. Along with a session that will expire at the same time. This way, BB would not only have to be timely in his attempt, but would also have to hijack a session in the same time period. Would this not make life difficult for BB? Not impossible, but difficult? And would this not help even if it were a coworker using the same pc?
I guess the more difficult a developer makes it for a would be intruder the better. Right? But, how severe of a burden would this put on a server having to update a database on every page load (we have over 2000 members and get roughly 30,000-50,000 page loads per day).
Thanks folks!
IamStang
you really cannot detect when a user simply closes their browser.
I have a site where when the user makes an edit, it trips a flag (DOM/JS scripting) saying "changes made". When the user either leaves the page (clicks a link) or closes the browser or the tab, it brings up an alert box and says "You have made changes. Do you wish to save them before the browser closes?". If the user presses yes, it submits the form before the browser dies.
I have only test it in IE and Firefox and no lives hang in the balance, but it seems to work. With a bit more scripting, you could have JS generate and submit the form. I suppose you could also set up links so that any outbound link gets an onclick attribute that also fires the function in much the same way that I do the onchange.
You could probably use JS to kill the cookie as well as record the "logout" in the DB.
That said, all of this depends on the complicity of AA. If AA wants to surf without JS or wants to give the cookie to BB, then none of these methods help at all.
Instead, I think you need to have a field that expires in your DB and track every request. If the users make no request in X minutes, you make them log back in whether they've left your site or just gone for a cup of coffee.
ergophobeInstead, I think you need to have a field that expires in your DB and track every request. If the users make no request in X minutes, you make them log back in whether they've left your site or just gone for a cup of coffee.
From further reading elsewhere on the web and from the help here, I am leaning toward this as a solution. It seems to be the only method where one KNOWS that the user will be logged out regardless of which method he uses to leave.
In fact, I am going to take this idea and run with it. LOL. Unless, of course, someone comes up with a better idea. It is doubtful though, or there would be more info out there on the "Better Method".
Thank you.
IamStang
P.S: it's just a question , might not be a suggestion.
AnyangoAlthough this might sound "not appropriate" but why don't you store user's ip adress in the session variables or database too?
From what I have read, IP's are unreliable in the sense that some ISP's change the IP of their users with nearly every page load (namely AOL). While, in other cases, you may have several users with the same IP.
The latter of the two isnt necessarily a huge concern. However, in the case of an IP changing every page load, those users cant stay logged in. Right?
Thanks for the idea/thought!
IamStang
your point is very solid. just got another idea, havent tested it yet, just got it on the fly. the idea basically is
as soon as any user logs in, you save "Last Visited Page" name in session variables or in database right, now every time a new page is requested by the "logged in" user, you update that variable with the filename of that requested page right.
Now, lets say logged in user "A" requested a page
showWidgetDetail.php?widget=1
you stored this value in your variable, now user A was reading that page and he requested another page
showWidgetDetail.php?widget=2
before serving him the page, you just run a check,
"If the page that is REFERRING to this url is the same as stored in Last_Visited_Page variable of that very session, then the request is from the same browser window as for the last page, otherwise browser was either closed or it's simply someone else"
fishy fishy?
let's say user B opens his browser, hacks a session and tries to request
showWidgetDetail.php?widget=2
your system will check last_visited_page for that session and definitely that will not match with the page from which user B sent this request.
sounds good? nah? nevermind ;)
P.S: This might help you answer this question atleast
is there a way to tell if a person closes the browser?
if it can't answer any security concern.
Edit:
Basically bird-eye wiew is to have an algo which determines "What he was doing? and then comparing it with 'what he wants to do?'"
Sounds like it would work in some cases. However, in my case, my entire site is one page. Although, it might still work.
Let me think about this a minute. Even though my site is only one page, the valid user is still going to click on valid urls which could be recorded. On the other hand, the main content page would be the most likely exit point and would be an easy guess for Mr. Bad Guy. Of course, one could always set a random $page_id in the script and record that.
Regardless, I will have to think on this some more.:)
Thanks!
IamStang
"If the page that is REFERRING to this url is the same as stored in Last_Visited_Page variable of that very session, then the request is from the same browser window as for the last page, otherwise browser was either closed or it's simply someone else
Let's look at the way I visit WebmasterWorld.
- Open the PHP forum
- Open all new threads in tabs
- Last_Visited_Page is now the last tab I opened.
- Start reading pages, possibly from the last, possibly from the first tab
Now if I click on a link, it says I'm not the same user anymore because I am not clicking from the last page I opened.
So this will wreak havoc with anyone using tabbed browsing.
Going to stick with the "setting a timeout in the database" idea. Seems the easiest way to handle the situation.
IamStang
