On Fri, Aug 28, 2020 at 7:27 PM p...@thirdfloor.com.au <p...@thirdfloor.com.au> wrote: > > Hi. > > We have a non-trivial Flask app that I'm in the process of moving chunks of > to Pyramid and would like to get some input on options for how we run two > systems until the whole lots is migrated. > > The data layer is agnostic with regards web framework (using ZODB) so that > there are no problems having two systems concurrently access it. However I'm > struggling with the best way to go with auth across both. Conceptually the > simplest would be to have a auth cookie that is valid in both, it could be > set to only be created in one and honoured in the other. A call back from one > system to the other to verify a cookie is another way but that just increases > moving parts.
I had a pair of Pyramid applications that shared a session cookie. One was at e.g., 'foo.example.com' and the other at 'm.foo.example.com'. I set the cookie domain attribute to span both. (I don't have the code at hand but maybe '*.foo.example.com'.) Both applications had the same codebase, just different configuration options to dispay a desktop or mobile layout. They both shared the same Redis session backend. I wasn't doing authentication, just saved search criteria. I had to change the configuration a bit for the staging servers because I couldn't replicate the subdomain relationship; the domains were like 'foo.staging.example.com' and 'm-foo.staging.example.com'. I didn't want to wildcard at the 'staging' level because that would bring in lots of enterprise sites I didn't know what they are. But I couldn't find a configuration that would span just 'foo' and 'm-foo'. So instead I put them on different ports in the same domain, 'staging.foo.example.com:444' and 'staging.foo.example.com:7446'. The default cookie configuration successfully spanned between the ports. Another application has OAuth2 authentication. It doesn't have a companion but its structure may be useful. I may have used 'pyramid_oauthlib'. When a successful login comes back from the auth server it returns a dict of claims (email, name, server groups, etc). I parse the claims into principles and store that in the session along with some metadata. Subsequent requests use the session data for authorization/metadata, so it's the same pattern as the one above and could share the cookie with a companion application if I had one. A disadvantage of this approach is that after login, the "logged-in" state in the application is independent of the logged-in state in the auth server so they will expire at different times, and if the account is modified you won't see the changes until they log in again. If this is unacceptable you can save the server's auth token and revalidate it on every request. Then both applications would have to do this. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3Duo5tWA%2BZRLtK5mtkNh6KS4ae-_q939C_H_Lsk7vTKpZ8Q%40mail.gmail.com.
