Thanks everyone for the answers. For now we decided that unauthenticated_userid would return None.
Christophe Le lundi 13 avril 2015 15:20:52 UTC+2, Bert JW Regeer a écrit : > > 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 <cdev...@gmail.com > <javascript:>> 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 > >> <cdev...@gmail.com <javascript:>> 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 pylons-discus...@googlegroups.com <javascript:>. > >>> To post to this group, send email to pylons-...@googlegroups.com > <javascript:>. > >>> 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 pylons-discus...@googlegroups.com <javascript:>. > > To post to this group, send email to pylons-...@googlegroups.com > <javascript:>. > > 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 pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
