> On Jun 20, 2017, at 21:58, Mike Orr <[email protected]> wrote: > > On Tue, Jun 20, 2017 at 11:34 AM, Bert JW Regeer <[email protected]> wrote: >> I don’t agree with storing authentication session information in the session >> because they have two very different concerns/lifetimes. Sessions should >> store temporary data that may be useful across a user switching from one >> page to another, but should not store long-term information. Whereas >> authentication is usually longer lived, and has different concerns regarding >> the ability to expire/verify it is still valid. > > I guess my use cases are different. My organization wants idle logins > to time out in a shortish period of time so people don't leave the > site logged in and then somebody else comes to the computer and starts > using their privileges. So the time limit for an idle login and an > idle session is about the same (e.g., 15 minutes, 1 hour, 4 hours, 8 > hours depending on how strict and inconveniencing we want to be.) and > I don't see why they can't be the same. And if the session gets lost > for some other reason along the way, well, that's one of the basic > weaknesses of the web. > >> AuthTkt can’t be merged with the CookieSessionFactory stuff because AuthTkt >> as a policy is meant to work together with Apache’s AuthTkt module or any >> other code using AuthTkt. It is a lot like using JWT. It allows a single >> server (the authentication server) to sign and provide the user with a >> “token” they can use to authenticate against a different server/endpoint >> with that “token” and that other server doesn’t have to do any checking >> other than verifying the signature that yes the user is authenticated. > > I don't know how to set up multi-platform auth tokens, if ti goes > beyond just sharing the cookie. Athough our organization wants to move > to an OAuth server (which they don't have yet although they have a > limited one) so that will be kind of like a ticket. Another group has > a Django app that has OAuth, so I figure when they get it set up with > the central server they can show me how. > > How do you tell AuthTktAuthenticationFactory which foreign tokens to > honor, if Apache or a central server sets one?
It’s based upon the secret (i.e. the signing key) > >> However this has the flaw, as you saw that you can’t expire the >> authentication server side, you have to trust that the client listened when >> you asked them to remove the “token” and no longer use it to connect to a >> server. >> >> Besides JWT being an incredibly complex standard that every so often you >> read about yet another library that implemented it poorly (and thus leading >> to security issues) it has the same flaws as AuthTkt. >> >> pyramid_authsanity is my auth policy that tries to fix some of these issues. >> It can use the existing session, or another cookie, or even authorization >> header, and does server side checking that the ticket in the token has not >> expired or been removed. This allows for example a single user logged in >> from 3 different locations to easily de-authenticate the two other locations >> by clicking a button to remove some entries from the database. >> >> Using SessionAuthenticationFactory with a server side session implementation >> is slightly more secure, however the default session implementation which >> stores sessions in cookies (and thus has no server side state at all) has >> the same issues as AuthTkt in that expiration of the cookie is something the >> client has to abide by. > > I'm using 'pyramid_redis_sessions'. I can't guarantee that session > values will fit within cookie limits, because one application stores > all the search result IDs to page through them and there could be five > thousand. Although that application is still in Pylons. Still, I think > the cookie-value limit is too low for many session use cases. I think > I'll go back to SessionAuthenticationFactory. > > -- > 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%3DuodeBZ9X%2BqMCcS%3DcxRKNmfgJpUD5tXYbuEJ4qb%2BOBufiw%40mail.gmail.com. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/D1D244B7-A86D-48A3-A32C-4C7AE03E9B7F%400x58.com. For more options, visit https://groups.google.com/d/optout.
