> On Jun 20, 2017, at 22:05, Mike Orr <sluggos...@gmail.com> wrote: > > On Tue, Jun 20, 2017 at 11:34 AM, Bert JW Regeer <xiste...@0x58.com> wrote: >> AuthTkt relies on the browsers goodwill, what you are looking for is a way >> for you to expire an authentication session server side: >> >> https://usingnamespace.gitlab.io/pyramid_authsanity/faq.html#why-tickets > > That says that storing the user ID in a cookie is a bad idea, but > isn't that what AuthTktAuthenticationFactory does?
Yes, and my implementation does too. However what is referred to there is when people do: authentication=yourusername or authentication=userid And just add that to a cookie. That is what allows trivial “attacks” whereby an attacker just changes the cookie to say “authentication=adminaccount” and now they have an admin account. AuthTkt goes a step further in that it stores the userid/username and signs it, so it can’t be spoofed, but there is no expiration server side, that is where having a ticket server side comes in. > It says that it's > better to have a server-side list of valid tokens, but does > AuthTktAuthenticationFactory have that and if so where? It does not have this. > If it doesn't, > why is it called a ticket, because it seems to be the non-ticket the > article is disrecommending. Yup. > Whereas if the server did have a list of > valid tickets, then it could just delete the ticket, and then if the > client comes back with a ticket-cookie that should have expired, the > application can tell the browser where to go. Exactly what you want -- It’s overloading the language of what a ticket is. In AuthTkt the “ticket” is the cookie. In my case the tickets are per authentication “tickets” that are compared on the backend to the front-end. I guess I could clear up the language or change it or use something like “token” but that also has a very specific connotation for people. The important thing is that you can invalidate an existing authentication without a client being involved. Bert -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/DC658E78-0B91-446D-B74A-7AEB34E81630%400x58.com. For more options, visit https://groups.google.com/d/optout.
