Without cookies

[freelance84]

Hi,

 

I have a question relating to security. I have created a site so far without the use of any cookies as I am trying to avoid them.

 

The login procedure:

1. The user enters their details

2. If correct they are redirected to their relevant home page depending on user type.

3. When they are logged in, a value changes in the members mysql table indicating that the user is logged in.

4. The user then uses the site, when logging out the said value reverts back to the original, indicating that the user is no longer logged in.

 

Duplicate login.

1. If a user is already logged in and their details are used again on another machine, on this other machine a message appears saying this user is already logged in on another machine.

2. At the same time another value is changed in the mysql members table, so the next time the logged in member refreshes their page or clicks somewhere else within the site a message pops up to them saying "somebody else has just tried to log in as you, you should change your password"

 

My problem.

As I am trying my hardest not to use cookies, if a member logs in but then simply closes the browser, this doesn't revert the "logged in" value, so the next time they do try to login they cant as the site thinks they are already logged in.

 

Is there a way around this without using cookies? Or is this really as far as i can get without using cookies? I haven't really seen many if any good answers so far on the net.

 

My initial thought:

I was thinking maybe add another entry in the members table which updates a new time value upon each reload of any php script on the site.

The login page would then check the time difference between "now" and the last activity

If the time dif is over say 10mins the user can log in. If not a message pops up "You appear to be already logged in on another machine. If you closed the browser without logging out please wait x mins and try again. In future please press the logout button to avoid this message again"

 

This would also mean that it could potentially log out the user after ten mins automatically.

 

Any thoughts?

[MatthewJ]

Maybe you could fire an ajax update when the window closes that would log them out?

[freelance84]

Hmm, i'll look into client side scripting. I just assumed that as soon as the window closed it would cut all connections with the server, therefore making any attempts to logout futile.

[Psycho]

Of course, that requires that the user has JS enabled. This is an old problem. Personally I think relying upon the user to "log out" of a web application is a poor implementation.

 

I would follow the functionaity that Messenger used to have before it supported multiple, concurrent logins. That is, when a user attempts to log in again, log them out of the first session. If people are giving out their username/password to others that is their problem. That way if a user moves from machine A to machine B, they will be able to log in without waiting. The session at machine A could provide an alert that "You have been logged out because another user logged in at another machine". If it is due to a security breach, the user could log back in and immediately change their password.

[freelance84]

 

Genius! That is the answer I was looking for!

 

Thanks a lot mjdamato. Brilliant!

[MatthewJ]

If it is due to a security breach, the user could log back in and immediately change their password.

 

That is if the user that logged you out didn't already change it before you get back in.

 

On a side note, when are we going to stop coding for a world where the random security curmudgeon may have turned Javascript off?

 

As of 2008, the w3c stats were at 95% or better having Javascript on, but yet everytime it is mentioned someone has to trot out "that will rely on JS being on"

 

I mean no disrespect, but it seems like that horse is pretty dead

 

[Psycho]

That is if the user that logged you out didn't already change it before you get back in.

Well, if they already have your password you were screwed anyway. You could always have a reset password function that will send a temp passwrd to your email. Of course, that requires that the other user doesn't change that before you get the opportunity. But, all of this is about trying to correct the problem AFTER it occurs.

 

On a side note, when are we going to stop coding for a world where the random security curmudgeon may have turned Javascript off?

 

As of 2008, the w3c stats were at 95% or better having Javascript on, but yet everytime it is mentioned someone has to trot out "that will rely on JS being on"

 

I mean no disrespect, but it seems like that horse is pretty dead

 

The primary reason for coding for users without JavaScript is not because of "random security curmudgeon" it is to protect against malicious users that want to do harm. I would say the vast majority of the JavaScript I use is for form validation. I would be a fool to rely upon javascript validation alone.

 

However, I believe there are situations where trying to make something work for a non JS user is counter productive - such as UI functionality that is highly dynamic like moving objects on screen. In those situations that functionality might be adding a lot of value to the application. When that happens a business decision needs to be made as to whether it makes sense to try and build a non JS solution or if that functionality can be restricted from some user. In a previous application we required that JS be enabled for the administration tools because we could state that as a requirement to the people buying the application. But, we made the necessary modifications so normal users without JS could use the application because our clients would not want to restrict any possible customers.