I’ve never been a fan of the whole authenticated_userid versus unauthenticated_userid. In all of my implementations of an auth policy that use a cookie with a token in it, I have unauthenticated_userid return None.
Even ones where it would be possible to retrieve a principal or userid, I still return None. From a security perspective, unauthenticated_userid might as well be a guest, and I use authenticated_userid as appropriate everywhere else in my code. > On Apr 9, 2015, at 07:49 , Christophe de Vienne <[email protected]> wrote: > > We did not do that for 2 reasons: > > 1) The documentation states "performs the same duty as > authenticated_userid". -> in my understanding, it means a value that is > usable as a principal and is no different from what authenticated_userid > would return, except the userid was not verified > > 2) This particular policy is one among others in our authentication > stack. Having it return something inconsistent with the other policies > feels wrong. It means that calling 'unauthenticated_userid' on the > top-level multiauth policy may return different things depending on the > policy that answered, even if the final userid is the same. > > Am I wrong ? > > Le 09/04/2015 15:29, Michael Merickel a écrit : >> I've never had the assumption that unauthenticated_userid would return >> the same thing as authenticated_userid. In my custom token-based >> policy I simply have the former return the token and the latter checks >> the database and converts it to a real user id. >> >> The definition of a user id in pyramid is completely undefined minus >> being convertible to a string. >> >> On Thu, Apr 9, 2015 at 8:08 AM, Christophe de Vienne >> <[email protected]> wrote: >>> >>> >>> Le 09/04/2015 14:42, Chris McDonough a écrit : >>>> On 04/09/2015 08:33 AM, Christophe de VIENNE wrote: >>>>> Hello Chris, >>>>> >>>>> Le jeudi 9 avril 2015 12:30:34 UTC+2, Chris McDonough a écrit : >>>>> >>>>> On 04/09/2015 04:09 AM, Christophe de Vienne wrote: >>>>>> Hi everyone, >>>>>> >>>>>> We are implementing a IAuthenticationPolicy that requires, to get >>>>> the >>>>>> actual userid, an access to the database [1]. >>>>>> >>>>>> Should unauthenticated_userid always return None to avoid a >>>>> database >>>>>> access, or access the database to always return the same userid >>>>>> authenticated_userid will return? >>>>>> >>>>>> The documentation [2] is unclear about what matters most: >>>>> "performs the >>>>>> same duty as authenticated_userid", or "needn't (and shouldn't) >>>>> check >>>>>> any persistent store". >>>>> >>>>> It should return the userid value sent in the request (usually in a >>>>> cookie) without checking if the userid is valid in any way. >>>>> >>>>> >>>>> I understand that. >>>>> >>>>> However the actual userid is not present in the request. Only a token >>>>> that is associated to a user in the database. >>>>> Which means that getting an actual userid makes a database access >>>>> mandatory. >>>>> >>>>> Hence the question: should unauthenticated_userid returns an actual >>>>> userid no matter what or let the actual job to authenticated_userid by >>>>> returning None? >>>> >>>> Ideally, both methods should return the same kind of thing. If >>>> unauthenticated_userid returns a token, so should authenticated_userid. >>> >>> This token has no meaning outside this particular policy, and this >>> policy is inserted in a pyramid_multiauth stack. >>> >>> So we must return the actual userid, and since both functions should >>> return the same thing, I feel we have to access the db in >>> unauthenticated_userid, although it is not meant to. >>> >>> Unless of course if we consider that returning None in >>> unauthenticated_userid and an actual userid in authenticated_userid is >>> an acceptable behavior. >>> >>> To summarize, the question is, which of these behavior is the least >>> acceptable? >>> >>> - unauthenticated_userid returns None while authenticated_userid returns >>> something >>> - unauthenticated_userid access the database >>> >>> My feeling is that accessing database is the lesser of two evil, but I >>> would like some confirmation. >>> >>> >>> Christophe >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "pylons-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/pylons-discuss. >>> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME cryptographic signature
