API design for tornado guard

[joegasewicz]

The below issues will give some context on why tornado doesn't have a middleware or extension plugin api:

• tornado extensions tornadoweb/tornado#2849
• Middleware for tornado? tornadoweb/tornado#49
• Tornado Middleware tornadoweb/tornado#679

This is a quote from one of the main maintainers of tornado (@ploxiln):

Tornado tends more towards a parts-you-can-use structure. You can make (and distribute) custom Router class, custom RequestHandler subclass, custom httpserver class, custom httpclient class, or a library that's convenient to use with an existing tornado usage pattern. Examples:

https://github.com/bdarnell/tornado_http2
https://www.tornadoweb.org/en/stable/routing.html
https://github.com/siddhantgoel/streaming-form-data/blob/master/examples/tornado/stream_request_body.py

You can also use the mixin pattern, just pass it any subclasses you are extending e.g

class BaseHandler(
    # Add Request middleware here 
    TornadoAuthSessionMixin,
    tornado.web.RequestHandler,
):
    pass

[rennf93]

Thanks for this Joe!

I checked the issues you shared.

So the mixin pattern is the way to go:

class GuardMixin:
    async def prepare(self):
        # security pipeline runs here
        await super().prepare()

    def on_finish(self):
        # response processing, metrics, logging
        super().on_finish()

Users would then compose it into their handlers:

class MyHandler(GuardMixin, tornado.web.RequestHandler):
    def get(self):
        self.write({"status": "ok"})

This is consistent with how your tornado-auth-sessions mixin works, and with the example user ploxiln gave.

One thing to figure out: how to pass SecurityConfig to the mixin.

Options I see:

1. Via Application.settings — users pass config at app init,
   mixin reads it from self.application.settings["guard"]
2. Via a module-level init function — tornadoapi_guard.init(config)
   stores it globally, mixin reads it
3. Via the mixin constructor — but that conflicts with MRO

Thoughts?

[joegasewicz]

I think 1. approach via the tornado settings is probably the 'tornado way' but if we need to wrap the tornado application object anyway then it might also then make sense to use your init method approach...?

[rennf93]

You're right on that, they're actually the same thing if we do it right.

Then something like:

from tornadoapi_guard import GuardMixin, init_guard

app = tornado.web.Application([...])
init_guard(app, config=SecurityConfig(...))

Where init_guard just stores the config (and initializes handlers) on app.settings["guard"], and the mixin reads from self.application.settings["guard"] in prepare(). That way it's one init call at app level, no global state, and the mixin stays clean.

Want to take a first pass at the mixin? The adapters.py spec has the interface contract, and you can reference fastapi-guard's middleware.py for how the security pipeline gets wired up. Tornado and FastAPI both use the async guard-core.

[joegasewicz]

That looks great. I'll make a PR tomorrow for this to get the ball rolling 🙂

[rennf93]

Sounds like a plan. Tyvm Joe!