Originally I used SessionAuthenticationPolicy because the code was straightforward and what I was doing before. I mentioned the seemingly-duplicate code between '*CookieSessionFactory' and AuthTktAuthenticationPolicy and whether it could be merged, because it was long and complicated (and hard for me to understand, all that cookie signing and setting stuf). Somebody recommended AuthTktSessionFactory anyway saying it's not necessarily a great idea to put your authentication in your session. I'm not sure I fully agree with that, but I switched to AuthTktSessionFactory anyway.
Now I'm wondering, how does AuthTktAuthenticationPolicy enforce logouts? With SessionAuthenticationPolicy it deletes the userid in the server-side session, and if the server wants to reject somebody with prejudice or clear all sessions it can delete the session backend object. But with AuthTktSessionFactory as I understand it, it merely sends a header to the client expiring the cookie. What if the client ignores that directive? Would the person still have authenticated status? Does the server keep a record somewhere of which tokens are still valid? (Akin to storing the ID in the session.) If not, how does it know whether to reject the cookie because it previously invalidated the token? Does this mean SessionAuthenticationFactory is actually more secure than AuthTktAuthenticationFactory? -- Mike Orr <[email protected]> -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3Duqt%3D_i-eus-VHWeSEO%3DNasWkfTiSr0YgvnjWQZv6_quDA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
