Hi all...  here goes "yet another PAU email", after a fashion.  it's
really more a question of design, and "am i thinking about this
correctly" than anything else.  what follows is wordy and potentially
too specific to my own implementation to be reasonably
troubleshootable, so feel free to ignore...  there's just really only
one place to go for these kind of answers ;)

i have built a credentials plugin and an authenticator plugin, and set
them up in my PAU.  i built the credentials plugin such that if no
credentials a recieved in the request, it checks the cookies for the
expected credentials, and if they're there, builds the necessary
credentials dict out of that instead, and returns that back for the
authenticator plugin to use.

the login logic then, assuming a principal is infact returned from
pau.authenticate(self.request) (either because the cookies have the
credentials or the request did), returns back
self.request.setPrincipal(principal) and sets the cookies for the next
use (in the case that the credentials were found in the request, but
hadn't been set yet).

my login form's action looks like this:

    def handle_login_action(self, action, data):
        lsm = component.getSiteManager(context=self.context)
        pau = component.getUtility(IAuthentication, context=lsm)
        principal = pau.authenticate(self.request)
        if principal is not None:
            #i've both used this and not used this...
            #doesn't seem to affect anything one way or the other

and, usually thereafter, my principal is available in
request.principal.  but not always.  certain submission update/render
make request.principal unavailable.  and in my logs, when i get an
unauthorized error, the user shows up as "unauthorized, myUserId", as
opposed to "login, id" etc.

since http is fundamentally stateless, my thought here is that i need
to add "Session Credentials" to my PAU as well, and put my principal
in the session, so that it's always available to me somewhere.  but is
this correct?  mexiKON in IRC the other day mentioned that the pau
itself should handle making the authenticated principal "resident",
but I think I may have misunderstood "how", or misinterpreted the
context to which he referred.  or he may have meant that the pau
handles it *if* you add session credentials to your credentials
plugins.  but i'm confused/worried because my logs show my user as
"unauthenticated" anyway, so I'm wondering if I haven't actually
successfully authenticated, but am rather re-authenticating on each
request with the cookies...  which may be what is supposed to happen?

the userDetails div does show me logged in as the expected user, and
the user has the role "site member" granted.

as a bit of extra background, i have a viewlet that needs to be aware
of request.principal.  in tales, i did a bit of tracking of "where and
when" the current self.request was aware of request.principal.  the
primary page view found request/principal/id every time.  the viewlet
could find request/principal/id in tales, but not in the viewlet class
(a form.Form), even though self.request is super'd up through.  i
attempted, in the viewlet, to look at
"self.__parent__.request.principal" since i set __parent__ to the view
that comes in on __init__, and i know that view can see
request.principal, since it shows up in tales every time.

still no luck, it always throws AttributeError on request.principal.

so i'm confused as to whether or not i've failed to properly
authenticate, or if there's something i misunderstand about the
render/update pattern for form.Form that doesn't include the
request.principal in the post.

that's all i've got for now.  again, if my questions are likely
answerable only with the context of my own implementation, that's
ok...  i'll be fighting with it more anyway.  but if something sticks
out as misunderstood or misconceived on my part, please, let me know!

Thanks in advance for any help...

"All guilt is relative, loyalty counts, and never let your conscience
be your guide."
  - Lucas Buck, American Gothic
Zope3-users mailing list

Reply via email to