no problem anymore, that was a while back. it's been working
correctly for quite some time. if you check the later posts, I did
exactly what you suggest, and use session credentials. it then had an
issue where it assumed that the form always called the fields "login"
and "password" so I overrode that behavior myself. then
AuthenticatedPrincipalFactory doesn't actually adapt a principal back
to the type of principal you originally sent in, but instead sends you
back an IPrincipal, rather than derived version. so I built my own
Authenticated factory as well, to get back a principal with my own,
extra attributes.
as far as the "login/password" fields issue, I'm pretty sure Florian
submitted a fix for that back to svn a while back as well.
Thanks for the answer though!
On 6/1/06, Stephan Richter <[EMAIL PROTECTED]> wrote:
On Wednesday 12 April 2006 12:54, Pete Taylor wrote:
> 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.
Aehm, this is exactly what the SessionCredentials do.
> 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:
>
> @form.action('Login')
> 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:
> self.setCookies()
> #i've both used this and not used this...
> #doesn't seem to affect anything one way or the other
> self.request.setPrincipal(principal)
Why are you doing this by hand? The authentication service should do all of
this for you.
> 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.
All this will work, if you use PAU correctly.
I strongly suggest setting up a simple PAU, all with standard components. It
is really not that hard and work beautifully.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
--
"All guilt is relative, loyalty counts, and never let your conscience
be your guide."
- Lucas Buck, American Gothic
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
