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.
signature.asc
Description: OpenPGP digital signature
