[Grok-dev] how to determine who is logged in?

Sebastian Ware sebastian at urbantalk.se
Thu Oct 11 03:08:39 EDT 2007


I'm no expert, but I use...

   self.request.principal

...to get the current user. And...

   principal.id

...if I need to logg stuff for that principal. I also create a  
separate user object with any fancy stuff I need. I learned this from  
the Kirbi application.

I pass the principal as an argument when calling methods outside the  
View class.

Mvh Sebastian

11 okt 2007 kl. 06.16 skrev Brandon Craig Rhodes:

> My weeks of staring at Grok and Zope 3 are finally resulting in a
> small web app, but I was stopped this afternoon by the question: how
> should my controller layer determine who is performing each action?
> My app is structured like this (following recommendations both in
> Design Patterns and in the PvW book):
>
>   Content layer: some simple content components.
>
>   Behavior layer: Adapters that offer methods for performing
>      business-level operations on the content objects ("add one of
>      these", "give this to that person", "remove one of those"), which
>      often involve operating on several pieces of Content at once in a
>      way that keeps them consistent with each other.
>
>   View layer: my grok.Views, whose contexts are typically from the
>      "Content" layer, but which, when a user hits a buttons or submits
>      a form, adapt their context using a "Behavior" adapter so that
>      they can perform actions upon it.
>
> And so I am finding that, in the middle of Behavior code, I need to do
> things like:
>
>     def increase_quota(account, amount):
>         fs = account.filesystem
>         account.add_quota(amount)
>         History.add('Admin %s has increased the %s quota by %f MB' %
>                     (?admin?, account.username, amount)
>
> You can see my problem!  I am not sure what to put for "?admin?"; I
> don't know how, inside of application code, I'm supposed to determine
> who is performing an action so that it can be properly logged.
>
> How it this normally done?  Should the Controller "know" that it's
> part of a Zope app and ask for zope.security to provide the current
> interaction?  Or should Controllers be dumb and just trust the View to
> pass in the admin, since the View has access to the request object?
>
> My first instinct was to have the Controller know that it was inside
> of Zope, and have it call a function like:
>
>     from zope.security.management import getInteraction
>
>     def get_current_admin():
>         interaction = getInteraction()
>         ids = [ p.principal.id for p in interaction.participations ]
>         ...
>
> But here we run into a second problem: needing CAS authentication, but
> not seeing a Zope 3 module that can do so, I created a simple adapter
> of my own that provides IAuthentication() as a local utility inside of
> my grok.Application.  I had hoped that the presence of this utility
> would make users appear in the current interaction fetched with
> getInteraction() but, alas, no such magic occurs.  Even if I've done a
> CAS login so that a principal is now available by calling up the
> IAuthentication local utility and handing it the current request, the
> list of principals returned by "interaction.participations" still
> includes only users picked up at the top level of the ZODB (thus, only
> admin users), not the users I'm CAS authenticating inside of my
> grok.Application.
>
> Thanks for any help!  Once I figure out this (and also how to use
> skins and make my site pretty), I'll be ready to claim to my superiors
> that they should let me start writing all sorts of things using Grok
> and that it vastly increases my productivity.  (Right now, it just
> results in my reading *lots* of Zope code, and the PvW book, and then
> still not managing to get things exactly right.) ;-)
>
> -- 
> Brandon Craig Rhodes   brandon at rhodesmill.org   http:// 
> rhodesmill.org/brandon
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev



More information about the Grok-dev mailing list