[Zope-CMF] Forcing skins by role
Tres Seaver
tseaver@zope.com
24 Aug 2002 10:34:50 -0400
On Fri, 2002-08-23 at 19:35, Paul Winkler wrote:
> On Fri, Aug 23, 2002 at 04:11:53PM -0700, Paul Winkler wrote:
> > > Ugh. Let me see if I can make it work
> > > based on the AUTHENTICATED_USER value
> > > in the REQUEST.
> >
> > ... and the answer is: not any way that I can think of. :(
> > I can look up the user's name in acl_users ( and hope it's
> > the right one), but I get back a plain vanilla User object,
> > not AuthenticatedUser, so I don't get a useful has_roles
> > method.
>
> Just to elaborate: a bit more investigation proves the
> above reasoning is false.
> REQUEST.get('AUTHENTICATED_USER') returns an actual
> user object complete with has_roles(). But
> even so, calling it in an access rule seems to always give
> 'Anonymous User' as fas as I can tell.
>
> So apparently, this REQUEST variable is actually inserted
> in teh REQUEST sometime after access rule is called.
The access rule is invoked during URL traversal, which is indeed earlier
in the request processing than the machinery which kicks off
authentication. The reason for this is that Zope2's security mechanism
is "bottom up" (it starts from the final traversal target).
> Looks like I'm going to need to go in a different direction.
> Maybe I can have a method that sets the skin and is always
> called by my main_template of every skin.
That is the earliest opportunity you have, actually, since
authentication is done by the publisher at the point where it has a
callable (the method or object being published) but just before calling
it.
Another alternative would be to create a custom security policy (derived
from AccessControl.ZopeSecurityPolicy) and arrange to do the skin
setting from within its 'validate' method. You would then modify your
startup code (e.g. z2.py) to install your own, custom policy.
Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com