On Tuesday, April 3, 2018 at 10:20:41 AM UTC-4, AlighaThor wrote: > > I would do not perform the database check in every request (and I think > Massimo did'nt mean that :)), only during the the second (or more) attempt > to log in with the same user. > > Let's say you have the X user logged in. You stored the uuid in the > auth_user.uuid field as mentioned. Then in another session there is an > attempt to log in with those same credentials. You generate a second uuid, > and validate that new uuid against the older stored in the user record. > > If the auth_user.uuid field is blank, there have been no session with that > user. So you proceed to log in. > If it exists, but it is different from the stored one, the user is already > logged in, so you must prevent the second one. >
That is a possible alternative approach, but could create problems. Someone can log in on one machine and not explicitly log out. It will then be impossible to log in from any other machine at least until login expires on the first one. If you allow extended logins (e.g., 30 days), you would have to wait 30 days. Massimo's approach avoids this problem by letting the second login take precedence and force the first login to become invalidated. Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
