How to Block Same Time Login

Dear friends.
when member login to website. How to block new login using same account information?
Some people shares login information with other people and than other people and account holder login same time to web site.
How can i block this.

 

You could develop it so that it scans for multiple ip logins within a certain period. E.g if 1 person logs in from the UK and 1 from the USA within the space of 20 seconds the chances are its more than 1 person. My usersystems are developed so that only 1 session can be valid per user account at one specific time. Simply checking the PHPSESSID and users ip with the last person logged in. Which I store in a database.

 

Create a database column called "loggedin" for example. When the user logs in, set the value for that user as true. When the user logs out set that value as false. But if the user is idle, you need to know if his/her cookie has expired or not.

Create a column called "time" too. When the user logs in, set the "time" column value to the current time at log in. Every time the user loads a page on your site, update the "time" column with the current time. If the user clicked the "remember me" check box on login to remain logged in and avoid the cookie from expiring, then set the value for that user in the "time" column to some kinda infinite value or what ever your code will read as infinite.

So whenever someone tries to login, first check to see if their value in the "loggedin" column is true. If it is false, allow them to login (users who clicked "remember me" check box will always be true). If it is true, then check the "time" value for that user. If you allow your users a cookie period of 1 hr, then check to see if 1 hour has passed. If it has passed, you know that the user is really logged out on the other computer, cuz their cookie has expired. If 1 hour isn't gone since their last time was logged, they're still logged in on another computer so you'll present some kinda error message like "You are already logged in on another computer". If the user's time has the infinite value, then they'll always see that message on another computer until they first log out.


I just thought out that logic, but I think I implemented this system already so check for flaws. Also, you should ask the user if you want to log them out on the other computer first instead of denying them access, cuz that may cause huge problems. Of course there'll be more to it to do this.

 

That's a flawed approach. Dynamic and Shared IPs are still common. Also some visitors surf on proxies provided by their ISP. The AOL software uses PROXIES when surfing from their software and one of their IP addresses could be used by thousands of internet users. IP checking really isn't the way to go.

If you want 1 sessions per user at a single time it's much easier.... Have a Sessions table consisting of the following self-explanatory columns: sid (32 char), lastaction (datetime), created (datetime), and username. Store the sesionid (sid) in a cookie. With each page turn you can access the username and update the lastaction with using the sid from the cookie as the key.

Now to limit sessions... When a visitor attempts to sign in fetch their cookies. If a sid is present DELETE any records in Sessions matching their sid. Upon successfully logging in DELETE any records in Sessions matching their username before creating their new record. Wah-la.

 

If there is a lastaction column that does what you described, a created column won't be necessary. Unique ID's would be necessary only if you want to allow the user to log out of the remote system in order to log in on the one they're on.

 

for advice, i think session data should store in a memory table, if you have a lot of visitors..

 

A "created" column simply holds the creation date of the session whereas lastaction holds the date of the last page turn.

 

Why is the creation date necessary?

There is only to be one time data column. It's value is set on every session creation and changes with every page loaded.
After your "lastaction" column stores a value, the "created" data would be no longer needed relevant for anything right?

Though it's cool just to have it there and know when the session was created for showing info like "Last Logged in time" etc..... but for the OP's purpose, the time of the last activity is all that is necessary.

 

The created column allows you to access when the session was created which enables you to expire sessions server side.

For instance...you may want to force a user to sign in every 30 days and you may want to have that control server side rather than client side with a cookie expiration date. There's tons of uses for it..and even if you don't make use of it it's still a good thing to know when that user actually signed in.

 

Yea well like I said, for the purpose of what the OP wants, all those things you described there aren't necessary, but still great to include in your app for the same reasons you described. It'll be up to the OP if he wants to add those extra features or not.

 

Your preference vs mine is irrelevant. If the OP chooses not to use a column that is "great to include in your app" it is entirely up to him. With that said...I can't think of one valid reason not to keep track of the created session. In fact, I can't think of a good reason not to keep track of the created date/time of any record being logged whether you currently need to use it or not...

 

I'm guessing DP rewards users for "last say"...... right, wrong?

 

I reply to posts directed at me and choose to stop replying when I feel necessary. The unnecessary thought of trying to get the last word never crossed my mind.. Is that what you are trying to do? I'll give it to you. Reply again.

 

this is my reply