thread... ;)
How do you represent an identity? Do you have access to a user's login
credentials? Maybe a user name would suffice - for example, in your
ACL plugin (which might query the ACL preDispatch), you might:
if($acl->isAllowed(role, resource, etc) && !isBanned($identity-
>userName))
if you define isBanned() to check some table or list of banned users,
the list could be updated dynamically and be checked against during
each run through preDispatch. Similarly you could extend the ACL and
define isAllowed() in such a way that it will not only query the ACL's
role/resource/privilege but also check if the user is banned? Then if
the user is banned, you can clear their identity from storage and take
measures to ensure that they will not be able to log in again until
the ban is lifted.
The authentication versus authorization point made by Keith is valid -
in fact, banning someone via the ACL, thereby "de-authorizing" someone
is entirely dependent on them being who they claim to be (in other
words, authentication). The authentication isn't what you need to
change, because you aren't changing "who the person is" , you're
changing "what they are allowed to do." Of course you will want to
prevent successful logins from a banned user who is not already logged
in, but that's a different matter.
--Mike H
On Feb 26, 2009, at 9:27 AM, bennyg wrote:
>
> i'm can see what you mean about using Zend_ACL but this still
> wouldn't solve
> my problem as if I gave a user a role of banned then their old role
> would
> still be persisted in the session until the next time they
> authenticate.
>
> I could create a front controller plugin to reauthorise a user on
> each page
> load but it seems far more logical to keep all the authentication in
> the
> same place.
>
> It would be interesting to know how other have handled this and what
> would
> be considered best practice.
>
>
> keith Pope-4 wrote:
>>
>> I think you are getting confused with authentication and
>> authorization. Authentication is making sure someone who they say
>> they
>> are. Authorization is making sure that person can access a resource.
>>
>> So you have Zend_Auth and Zend_Acl (Authentication & Authorization)
>>
>> You can do a check per request using an ACL assertion, ala a Front
>> Controller Plugin
>>
>> 2009/2/26 bennyg <ben@magiconlinesolutions.co.uk>:
>>>
>>> I've implemented Zend_Auth on a new project that I'm working but
>>> would
>>> like
>>> to make a few changes to how it works.
>>>
>>> The main change I would like to make would be to reauthenticate a
>>> user on
>>> each page load so if I choose to ban them they get logged out
>>> instantly.
>>>
>>> To me it makes sence to implement this functionality within
>>> Zend_Auth by
>>> extending the class.
>>>
>>> I can only find one example of someone extending Zend_Auth so
>>> would like
>>> to
>>> check if this is the best method to solve my problem.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Extending-Zend_Auth-tp22223840p22223840.html
>>> Sent from the Zend Auth mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> ----------------------------------------------------------------------
>> [MuTe]
>> ----------------------------------------------------------------------
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Extending-Zend_Auth-tp22223840p22225223.html
> Sent from the Zend Auth mailing list archive at Nabble.com.
>
没有评论:
发表评论