Agreed on all points. The solution I would prefer is for the sf_guard_user table to have a "is_disabled" field in addition to its "is_active" field. The disabled field would always be checked in an appropriate filter.
I am just surprised there isn't a solution within the framework or the standard plugins. Steve On Oct 23, 2:54 pm, david <da...@inspiredthinking.co.uk> wrote: > As Alex suggests - this should be implemented via a filter which ensures > the rule is always applied and cannot be bypassed. > You'll also get the option of being able to lock out accounts that have an > active session. > > Removing permissions isn't a bright idea - just because an account is > locked - you shouldn't lose any data. > A digital trail is important as it allows forensics later if needed - and > as you mention it's an extra admin overhead. > > Linking it to permissions isn't a good idea as it's only effective if > you're 100% certain ACL's have been applied correctly to resources and > then checked. It just takes 1 typo for declarative security to fail. > > On Fri, 23 Oct 2009 18:07:30 +0200, Steve Sanyal <steve.san...@gmail.com> > wrote: > > > > > > > I've already overloaded signin for a few other reasons, but the > > solution you suggest would would only be part of the solution, because > > if I disable a user I would have to remove all of the user's > > permissions also. Otherwise, the user could manually navigate to a > > page to which he/she had access. If the user has a remember cookie to > > bypass signin they could also avoid the disabled status. > > > Ideally I'd rather not have to remove all the ACL permissions because > > this creates an additional maintenance tasks, for example if I were to > > later re-enable the user. It would be much more user friendly if I > > could simply disable at which point ACL permissions would be ignored, > > but the user would get sent to a page explaining the user has been > > disabled. > > > To be comprehensive, this needs to hook into whenever permissions are > > checked, almost an "allow_disabled_access" in the security.yml, so > > public pages would be visible by the user but secure pages would not. > > > Steve > > > On Oct 23, 3:07 am, Alexandre SALOME <alexandre.sal...@gmail.com> > > wrote: > >> Overload the signin action, and make your test in it : if the account is > >> disabled, redirect to your special page, else, login. > > >> Which ORM/symfony version are you using ? > > >> 2009/10/23 Steve Sanyal <steve.san...@gmail.com> > > >> > Hi, > > >> > Has anyone come across any good solutions for having a disabled user > >> > in symfony? Ideally, I'd like a person whose account has been > >> > disabled to be sent to a special page. I'm using sfguard for my login > >> > and ACL. Currently, I just change the user's active status to false, > >> > but this merely prevents the user from logging in. > > >> > Regards, > >> > Steve > > >> -- > >> Alexandre Salomé -- alexandre.sal...@gmail.com > > -- > Using Opera's revolutionary e-mail client:http://www.opera.com/mail/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
