"A lighter alternative could be to add an _after_delete/_after_update callback to auth_table that would search and delete any sessions owned by the user" isn't that what cascade does?
On Wednesday, 15 April 2015 16:12:01 UTC+1, Leonel Câmara wrote: > > I think we have to take the performance hit. Hopefully the database will > be smart enough to keep the records for the users in cache so the slowdown > won't be that big. Right now this is sort of a security issue: > > 1. Add @auth.requires_login() to the welcome index function. > 2. Register and login, check that you can access index. > 3. Remove the user created in 2 from the database. > 4. Verify that you can still access login even though your user was > removed (possibly by the website administrator who doesn't want you to be > able to see the contents anymore) > > If you want you can replace step 3 with: > 3. In appadmin set the registration_key to 'blocked' which supposedly > would block the user. > > > A lighter alternative could be to add an _after_delete/_after_update > callback to auth_table that would search and delete any sessions owned by > the user which would be slow but would not happen very often, this of > course would only detect and fix this bug if you use the DAL to delete the > row and not some external database tool. > -- 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.
