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
-~----------~----~----~----~------~----~------~--~---
