Are you trying to host the apps in the same process? Where do you want certain shared parts to live as you migrate? In Pyramid code? In Flask code? Agnostic?
Option 1: If you want Pyramid to be able to use any Flask code then you'll have to likely setup Flask's threadlocal variables / request object inside the Pyramid request so that you can invoke Flask APIs. Option 2: If you want Flask to be able to use Pyramid code as you move it into Pyramid then you'll have to setup Pyramid's threadlocal variables / request object so that you can invoke Pyramid APIs. Option 3: If you want it agnostic then both Flask and Pyramid code need to pass their relevant data (path, headers, etc) into a function that doesn't care where it came from. You can do any of the things I mentioned above - I'm not sure what's the best for your situation. If you move your auth into Pyramid then you're basically talking about giving Flask a way to invoke `pyramid_request.has_permission(...)` which falls into Option 2 and would likely be best going forward if you're trying to move code into Pyramid. If you just want the cookie to be parseable in both frameworks, and write most of the security code separately in each, that should be quite doable as well because in Pyramid you can just define your own AuthenticationPolicy which could probably reuse a lot of code to parse/validate the cookie. Worst case scenario you can always write an AuthenticationPolicy that just hits a trusted REST API or something in the Flask code to parse/validate it, and then you just have Flask do the work there. If you're running the apps in the same process then they can potentially call each other pretty easily. For example with WebOb it has `request.get_response(app)` in which you construct a WebOb request object, and it can talk directly to another WSGI app (Flask, etc) and get back a WebOb response. This would automatically handle all the threadlocal stuff I mentioned above at least between Flask/Pyramid - no promises for whatever you're doing with other globals / threadlocals from other frameworks you're using for ZODB etc. Anyway without more details I can only focus on these high level options but I hope it helps. There are certain advantages of them both being Python WSGI apps in that you can actually run them together in the same process, and invoke code from each other without hitting a network. You can setup something like rutter (path-based dispatch between multiple WSGI apps) or pyramid.wsgi.wsgiapp2 (Pyramid can wrap other WSGI apps) to handle what you want in Pyramid and dispatch the rest to Flask. - Michael > On Aug 28, 2020, at 21:12, 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. > > Has anyone done this before or have any other ideas? > > Thanks for any input. > > Peter W. > > -- > 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 > <mailto:pylons-discuss+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/124cda96-4016-4049-b591-bb1fa25da663n%40googlegroups.com > > <https://groups.google.com/d/msgid/pylons-discuss/124cda96-4016-4049-b591-bb1fa25da663n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/2A72C370-0A31-4086-B70D-A36441D83E4F%40gmail.com.
