add get_tornado_instance as an experimental API

[link89]

Checklist

• I have searched the existing issues for similar feature requests.
• I added a descriptive title and summary to this issue.

Summary

As a developer, this API will allow me to access the tornado.Application instance, so that I can use the low level API to implement features that are unsupported by the streamlit for now.

Why?

streamlit has some limitations which make it very hard to implement some common features. for example, to keep user session after refresh web page. Before streamlit has formal support for features like set cookies, to allow developer to access the low level tornado.Application instance would be a practical temporary solutions.

For example, in my case I would like to set a session cookie when a user login my app via OAuth. This could be done by implement a dedicated raw-api/login.html endpoint to return a html page with set cookie headers in it and then redirect to the real target page. It is a common pattern to handle 3rd party login but unfortunately there is no streamlit API to implement it.

If I can access the tornado instance, this can be easily done by add a custom route handle to return a dynamic login.html page with set cookies header in the response. And I believe a lot of similar issue can be solved this way. I don't think it would take too much effort to provide this API.

Reference:

• https://discuss.streamlit.io/t/is-it-possible-to-create-a-raw-html-endpoint-for-setting-session-cookie/69419

How?

By just implement an experimental API named get_tornado_instance should be enough IMO.

Additional Context

No response

[github-actions]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.

[vdonato]

@kajarenc @sfc-gh-jcarroll FYI -- we may want to consider doing something like this (or accepting #8662, potentially making some changes to it to export it from any new namespace we may add) as part of the auth/headers projects.

[sfc-gh-jcarroll]

Thanks @link89

It's unlikely that we'll directly support using the Tornado instance since we've intentionally avoided exposing Tornado internals since early Streamlit. We're also beginning to look at moving Streamlit to an ASGI framework in the not too distant future (you heard it here first! 😉) so that would break any Tornado compatibility.

We're actively working right now on auth use cases similar to the one you described, see #8518

We're also doing some planning and design on custom HTTP endpoints similar to what you described in a more general way, along the lines of what I described here.

In general today, most developers use the undocumented-but-supported headers API for similar use cases. We will likely add a fully-documented-and-supported version of that in the near future.

I'm sure it's not quite the answer you hoped for, but that's the current state and we are definitely putting more energy in this direction than we have historically.

[link89]

@sfc-gh-jcarroll I believe you are working on some awesome solutions to solve those problems eventually , but the problem is when. I don't think I am lucky enough that some 2019 issues will be resolved in the next few weeks.

Thus I guess provide an experimental API as a transitional solution should not be bad. I think it's nothing to worry about the Tornado compatibility issue, once you have custom HTTP endpoint implemented it won't be hard for app developers to migrate to the new one and deprecate the broken feature.

I believe it will be good to provide some low level APIs so that a developer can use them to solve issues when there is no better way to choose. It's all up to you to decide anyway,