Nope. I wouldn't worry too much. Should be a simple refactor either direction.
On Sun, Jul 19, 2015, 10:22 Iain Duncan <[email protected]> wrote: > Thanks Randall. Have you any thoughts on doing the lookup in a tween vs > wsgi middleware? Will it amount to the same thing? We don't know for > certain that all inner apps will be pyramid apps (it's conceivable there > might be other wsgi deployed things) which is why I was thinking middleware > first. > > iain > > On Sun, Jul 19, 2015 at 10:18 AM, Randall Leeds <[email protected]> > wrote: > >> You're on the right track. >> >> Whether it's the RemoteUserAuthenticationPolicy or some other policy, the >> key thing is just to have your application code not know or care how or why >> there is an authenticated user or how permission was granted in the current >> context. >> >> Lean on `request.authenticated_userid`, `request.effective_principals` >> and `request.has_permission` and let everything else be specified at >> "deployment" by integrating the right policies. >> >> I have exactly a set-up like you describe in one application right now, >> where I have an oauth tween that sets the WSGI env from oauth parameters >> and then RemoteUserAuthenticationPolicy sees that. >> >> On Sun, Jul 19, 2015 at 10:01 AM Iain Duncan <[email protected]> >> wrote: >> >>> Ok, just sharing in the hopes of feedback. My latest thought for shared >>> auth is something like this: >>> >>> SSO Login app >>> - Pyramid app that handles login process, has db for looking up users >>> and groups >>> - after lookup, creates a JWT that stores the user id and list of >>> principles >>> >>> Other Apps >>> - have a middleware layer that decodes the JWT token, checks it, and >>> then puts the user id and the list of principles into the WSGI env, much >>> the way repoze.who does >>> - main app(s) uses a RemoteUserAuth policy, handle ACLs from the info in >>> the WSGI env *only*. >>> >>> I like this right now (in my ignorance, lol) because our main apps can >>> be completely ignorant of where identity comes from and if we change >>> schemes, we only have to swap out middleware. But I'm quite possibly still >>> on Mount Stupid. (http://www.smbc-comics.com/?id=2475) So comments >>> welcome! >>> >>> thanks >>> iain >>> >>> -- >>> 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. >> > > -- > 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.
