SitePoint Sponsor

User Tag List

Results 1 to 11 of 11
  1. #1
    SitePoint Addict
    Join Date
    Jun 2005
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    how to prevent two users from logging in with same id and password?

    How can I prevent two users from logging in with same id and password....
    [COLOR=SlateGray]
    Web Developer @ VeriQual

  2. #2
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,027
    Mentioned
    65 Post(s)
    Tagged
    0 Thread(s)
    Check their IP in $_SERVER['REMOTE_ADDR'] (If I recall correctly)

  3. #3
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    You could place a flag in the system to indicate whether or not the user is active, then just deny any new attempts to login with an active account.

    The hard work is going to be how you distinguish active / inactive logins.
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  4. #4
    SitePoint Addict
    Join Date
    Jun 2005
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Check their IP in $_SERVER['REMOTE_ADDR'] (If I recall correctly)
    wot if they are form different machines and but using same id and password.
    This is wot I want to prevent..
    [COLOR=SlateGray]
    Web Developer @ VeriQual

  5. #5
    SitePoint Addict
    Join Date
    Jun 2005
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SilverBulletUK View Post
    You could place a flag in the system to indicate whether or not the user is active, then just deny any new attempts to login with an active account.

    The hard work is going to be how you distinguish active / inactive logins.
    Sounds good!

    Now look at the scenerio,

    on the login of 2nd user I will check the inactivity of 1st user, if inactive, will allow the 2nd user to enter, but how can I destroy the session of first one?
    The reason is, I don't want to allow two users with same id and password work same time.
    [COLOR=SlateGray]
    Web Developer @ VeriQual

  6. #6
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,027
    Mentioned
    65 Post(s)
    Tagged
    0 Thread(s)
    The relationship between Client and Server is Stateless - that is there is no true way to verify the client is what it says it is - so keep in mind anything we provide you in this tact is going to defeatable if someone *really* puts their mind to it.

    That said, when you started the session with session_start() a session id was created. That id is going to be different for each browser that accesses your server even if they are from the same machine. Since browsers provide a random seed I *think* the PHP session ID will be different for two machines sharing the same IP address behind a modem but I'm not sure.

    Sessions will expire on their own after about 15 minutes to an hour of inactivity depending both on the server's settings (which you control) and the browsers (which you of course don't). If either causes an expire of the session a new one is started.

    To prevent multiple log ins for the same user you will can store the session id - but relying on it entirely creates the problem of expired sessions locking your user out.

    The IP address I mentioned above is more reliable since it typically doesn't change during a session - but two users could share an IP especially if they are in the same computer lab at a school. This said some ISP's use proxy servers resulting in revolving IP's.

    So that's the long answer - doing what you seek is possible but difficult and opens up into the fun, fun world of cross-site scripting attacks et al.

    Before you sink all that time into coming up into a solution though, why is it important that the user not access the site from more than one location simultaneously? Worth considering cause you're looking at a good day or two of work.

    With that in mind I'd recommend creating a session table and logging the timestamp of the log in, the PHP Session id (stored in $_REQUEST['PHPSESSID'] ), and the userid. During each page access done by that user renew the timestamp to "now". Refuse login to any user who's PHP Session id doesn't match the one on the session table. Run a query on each page load cleaning up any session on the table more than 5 minutes old. If the user doesn't have an entry on the session table log them out.

  7. #7
    SitePoint Addict wibble wobble's Avatar
    Join Date
    Dec 2008
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Michael Morris advice is good -- but it is pretty much impossible (or at least very very difficult) to 100% accurately differentiate between users. There was a big discussion on SP about this a while ago IIRC which you might want to search for.

    Also, you might want to reconsider doing this. If I go to the library or visit home and log into your website, I dont want to go back to my flat and be logged out.
    Find freelance jobs from all the major sites in one place:
    on twitter / on the web / twitter rss feed

  8. #8
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,027
    Mentioned
    65 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wibble wobble View Post
    Michael Morris advice is good -- but it is pretty much impossible (or at least very very difficult) to 100% accurately differentiate between users. There was a big discussion on SP about this a while ago IIRC which you might want to search for.

    Also, you might want to reconsider doing this. If I go to the library or visit home and log into your website, I dont want to go back to my flat and be logged out.
    I'm guessing this is for an admin backend, in which case the added security trumps convenience.

  9. #9
    SitePoint Guru mmarif4u's Avatar
    Join Date
    Dec 2006
    Location
    /dev/swat
    Posts
    619
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As discussed above, this type of system are very hard to implement.
    I will give another scenario:
    create a new table and store username and IP(if you want), time,curtime.
    After successful login they will be redirected to index page. Now in time field you have to store current time and date. Of course you have to be a LOGOUT button somewhere there. On logout clean that specific username form the table.
    your login script will check on each login for the username(OR user id), if it is there, then tell the user that you are accessing the website from this IP OR redirect HIM/HER to home page.some thing like that.

    Now the question is if user close browser without logout, so a good solution for this is to run cron job on a specific time to clean the values from the table, lets say if user is not active for last 15min, 30 min etc.

    But you have to store current time and date in field curtime in the table in every page of your site user is accessing.(update curtime)

    Some how it is another way to do it, but sincerely it will need some time.
    and some hard work to implement.

    May be there are some flaw in this scenario, but this is what i came up.

  10. #10
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    That said, when you started the session with session_start() a session id was created. That id is going to be different for each browser that accesses your server even if they are from the same machine.
    For different browsers on the same machine, yes... but for a second instance of the same browser, it isn't quite as clear cut. They probably share the session cookie (some browsers don't, but most do), so the second instance would share the session of the first.
    And tabbed browsers always share the session cookie across all tabs.
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  11. #11
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Your requirements may not need it, but consider a user who's browser crashes, or they accidently close it, or they intentionally close it and then realize they aren't really done and need to log back on. If you have a 15min timeout, this will frustrate them, assuming you use a typical session cookie with zero for the expiration. They must wait 15 min to log in again.

    A quick solution is to set the cookie with the session id to have an expiration 15 minutes in the future, and keep setting it on every http request, extending thier time. Bad thing here is this isn't great for users who may be using a public computer, where they may close the browser and walk away. Someone else has X minutes to just reopen the browser and goto the website, and bam, they're logged in.

    You can have the browser maintain two cookies to solve this. The cookie which carries the session id has a normal expiration time of zero, so it goes away if the browser is closed. But maintain a seperate unique id, call it login_access, which carries another random id which you store in your database. A client who attempts to log in(presenting valid user/pass), will be allowed to log in at any time if this login_access id is valid for the user they're attempting to authenticate for. If they successfully log in via this exception circumstance, then the other session for this user which the system thinks is still active, will be booted, as the system assumes the user crashed/closed browser accidently. Obviously this cookie, along with its entry in the database, need to be leashed with an expiration time as well.

    Heh, now you've got me wanting to build such a system


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •