The main purpose for this would be to track login collisions and make sure users aren't sharing log in info.
If a user has a high number of collisions we can assume they are sharing their credentials and take the appropriate actions. -- Sent from my Palm Pre Tim Chase wrote: > So is there a viable django solution for this problem? To build on what Malcolm was saying, the problem you have is that the only things your server knows are (1) when a user last engaged in a transaction with your server and optionally (2) when a user has intentionally logged out. #2 is nice, but many users don't log out intentionally -- like Malcolm said, they just close the browser or shut down the computer. In theory, you could create your own session backend that tracks the user associated with a session token and last-activity timestamp, and ensure that the user is unique in your session-store. HOWEVER...this creates a world of hurt for pretty much everybody: - Testing on multiple browsers becomes a pain because you need to serialize your tests, or create a user for each browser to step through the processes in parallel. - Users get miffed because you break their expectations of how the web usually works. - You may have to support those miffed users who call to let you know they can't log in, peeving them even further when you tell them "oh, just wait 30 minutes and your session will expire". You might be able to mitigate this by having a JavaScript activity-ping on your page that makes a request every 30 seconds or every minute, and then shortening your timeout window to 5-minutes. However, this peeves the folks that disable JS (such as the FF NoScript plugin) because they now have to perform activity every 5 minutes or else re-login. This also puts notable load on the server (one request per user, every 30-60 seconds, just to update their "hey, I'm still here" timestamp) I'm sure there are other reasons not to do it, but those are what I can come up with before breakfast and in my mind, the list is already pretty convincing against the idea of trying to limit users to a single session. The only <sarcasm>value</sarcasm> I could see in this is for some service where you're charging on a per-user-seat licensing scheme. If this is your wish, take a hint from little companies like Salesforce.com -- just do your licensing per-named-user and stop worrying about how many machines they access it from. -tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
