Thanks a lot. I'll take a look. Do you write plugins for the framework? Cheers, Steve
On Oct 23, 3:17 pm, david <da...@inspiredthinking.co.uk> wrote: > My email with the attachment appears to have found itself stuck so you can > find it on Pastie:http://pastie.org/667060 > > If you don't need any support for it - then there's a filter attached you > can use. > > It's pretty self evident how it works and it needs to be in your > apps/<app>/lib folder for the app you wish it to be applied to. > > The entry for your filters is: > # insert your own filters here > AccountExpired: # Filters need a unique name > class: AccountExpiredFilter > param: > condition: %APP_ENABLE_EXPIRED_ACCOUNTS% > > You'll need: > 1) To be using Guard and GuardApply (it assumes the check field is on the > profile) > 2) an app.yml setting to turn it on/off (ENABLE_EXPIRED_ACCOUNTS) > 3) an isexpired field in your profile (boolean) > 4) you'll need to modify the filter with your own route should the > account be locked (not sure why we didn't use a routing rule) > 5) You'll need to ensure there is a profile or you may see unexpected > results - we do as a matter of policy > > As you can see from the attached code - it only works if the user is > logged in and should operate for each request. > A little extra overhead but the security policy on the project needed to > be able to disable accounts if a session already existed. > > On Fri, 23 Oct 2009 20:54:19 +0200, 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 -~----------~----~----~----~------~----~------~--~---
