Is there a new approach oder workaround available with st v1.0?. It seems still to host only unsecured http sessions.
I am sure you are aware of this, but for anyone who works with data or use cases that are at all sensitive, this is, or at least should be, a crucial requirement, both because it is common sense and good practice, and because there is a large and vociferous privacy community that is just waiting to jump on companies that ignore privacy protection. One of the first things I did at my last PM job was to move us to https.
Streamlit as a Python library intentionally stops before https, not because we can’t do it, but rather so that we focus on providing the best data app experience for users.
So there are definitely ways to run your Streamlit apps securely, irrespective of the version of Streamlit you are using.
The following is meant as friendly offer of a complementary perspective, not trying to bust your chops, or to argue with the near-term focus on providing best data app experience, and I totally commend Streamlit for providing good pointers to community documentation about how to deploy SSL.
I’m guessing that as Streamlit scales, the “soft” issues around data will become more important, and so will the outside-the-library deployment issues. So my $0.02 is “put it on the roadmap!”
Disagree. There are many more requirements, as you suggest, than just using https. There are data access, personnel, data sharing, auditing… the list is endless. HTTPS is only a single aspect of this, and may be more or less important depending on use case.
And all of these components of good data governance are difficult to do well, especially in a generic sense, without the context of the actual project.
There are many solutions to good HTTPS access, and signposting these and providing good integration is vital, but do not try to reinvent the wheel on this. A bad security implementation is a massive security risk. Focus on what you uniquely do well - streamlit explicitly NOT providing Https is much more preferable than an outdated or incomplete implementation.
Hosting on streamlit or behind a reverse proxy is trivial and allow separation of security from business logic.
My $0.02 - do NOT put it on the road map!
It’s quite easy to run it on HTTPS with reverse proxy as madflier suggests. I have done that by configuring apache server. When the request comes to the IP, apache will receive it and forward it to the appropriate port in which streamlit is running. I then used certbot to issue the certificate and also reroute all the traffic to https. Finally, you adjust the config in streamlit to point to the correct ip address / domain name in which you are serving the app.
Since Streamlit uses Tornado you can just edit the Package to make it use HTTPS instead of HTTP by adding the following “ssl_options” in file “server.py” in path “C:\Python310\Lib\site-packages\streamlit\server”. And everything works fine. HTTPS gets used instead of HTTP and WebSocketSecure (WSS) gets used instead of WebSocket (WS).