views:

92

answers:

1

Let's picture a django powered service that bills its customers monthly. The owner doesn't want his customers to share the account with people that did not pay. Of course, he understand that some may want to work collaboratively on an account, and don't want to restrain the use of shared accounts to the same IP address.

How would you let log in, with the same username / password, no more than 3 persons at the same times with django ?

I was thinking of implementing a counter in the User class but don't really know how good this idea is.

E.G :

Paul logs in using

Bonus question : what issues multi login can imply and what measures should I take to avoid conflicts between account users.

+3  A: 

You could use cookies and store a GUID inside this cookie. If a user doesn't have a GUID, give him a new one. Otherwise, check the GUID in his cookie with the one in your database. If it's one of the three most recently assigned GUIDs then it's valid usage.

Example: User logs in, gets GUID A. Clears cookies. Logs in again, gets GUID B. Clears cookies. Logs in again, gets GUID C. Clears cookies again. Logs in again, gets GUID D. All valid. He could even log in again with an existing cookie containing the GUID B or C but if he visits with GUID A then he's probably sharing the account. (Or using four or more web browsers.)

Example 2: User 1 logs in, gets GUID A. User 2 logs in, gets GUID B. User 3 logs in, gets GUID C. User 4 logs in, gets GUID D. At this moment, GUID A would become invalid and you'd kick out user 1.

To do this, all you need is to keep track of the three most recent GUIDs that you assigned to the user, replacing the oldest one with a new GUID whenever the user has cleared his cookie. If you check this with every web request, you would effectively block every fourth (and more) user.

Workshop Alex
Interesting. But isn't a severe overheat to check 3 GUID at each request, with a time contact ? Isn't there a method to check only at log in ?
e-satis
Since the cookie gets returned with every request, all it adds is a single validation with a single table. Adding an index on the GUID would even speed this up. Technically, it's related to the user record thus you could check for it whenever you're checking user information.
Workshop Alex
I see. Adding a request to the database for each page loading is not such a lite issue, especially if the website delivers 100 000 pages / day. But for a low traffic website, that seems to be what I need. Cheers.
e-satis
When serving 100.000 pages per day, you'd be needing more servers with additional load balancing. Even then, if you already have to access the user data to e.g. display his full name then it's no big problem to also query the top 3 GUIDs. Worst case, add three fields to the to contain the GUIDs, named GUID1, GUID2 and GUID3. Add a fourth field called GUIDIndex which keeps track of the last generated GUID. (Either 1, 2 or 3.) It's not perfect but can be included to the User record which you already need to display his name...
Workshop Alex
But adding a more normalized table that links GUIDs to User ID's with additional timestamps would be more practical. :-) Thus, you'd have a record with UserID, GUID and Timestamp in a table called GUIDs and you select the top-3 records where UserID is linked to the web user. The Cookie GUID must be in this set. (Also makes it easier to e.g. change to the last 5, last 10 or last one.)
Workshop Alex