I’ve deployed the streamlit sample to an Azure AppService as a container. If I leave it unsecured, it works fine. If I turn on Authentication where it will redirect unauthenticated requests to Azure AD Login, it hangs at CONNECTING with the Please Wait… box up. If I look in the logs, healthz is returning ok, but the wss stream connection is getting closed right away.
In the App Service configuration, I have “Web sockets” set to On and “Always On” set to On.
Any ideas for what I might be able to look at to figure out why the authentication is failing on the web socket call?
Obviously the sample doesn’t need to be secured, but if our data science team uses this for quick visualizations for models and services they develop, we’d prefer not to have those UIs publicly accessible.
Hi,
I’m having the same issue.
If I just remove the Azure AD login, the app works as expected (all the rest remaining unchanged).
I also noticed that the healthz and stream requests seem to be piling up, might be linked to the refresh frequency being half the timeout.
I’m a DS trying to deploy a prototype app to my end users, so I really need it to be secured behind the authentication.
I am seeing the exact same behavior. I believe its an issue with App Service Auth. The authentication logic happens in App Service before handing the http request to Streamlit. I suspect that the web socket connection is being rejected by App Service since this request will not send the auth cookie.
Web sockets and authentication can be quite tricky. Web sockets do not support headers so normally the authentication is passed as an access token in the request as part of the querystring. Since Azure App Service Auth and Streamlit do not have options to configure how to authenticate web socket connections I believe we are out of luck as it stands now.
Im investigating other options like fronting streamlit with a reverse proxy like NGINX, but will require more custom code and container deployment.
I contacted Azure support, seems indeed to be linked to the way WebSockets are handled for Linux containers on Azure
From the link mentioned to the issue raised on streamlit I understand that it is using WebSockets to connect.
Unfortunately on Linux WebSocket are not able to run when Authentication is enabled. This is because the authentication is handled by a separate container that does not support WebSockets at the moment.
While some additional support for WebSockets on Linux is planned for the next Platform upgrade scheduled for next month I am unable to provide you with a timeframe of when WebSockets would work with Authentication.
Until then the solution would be to either not configure the authentication from the portal or manually implement authentication in your application.
AAD Auth can be achieved by using windows containers in App Services (currently in preview). Configuring a new windows container required the following changes:
App Service:
Enable Web Sockets
Configure AAD Auth
Dockerfile
FROM python:3.7-windowsservercore-1809
(remember to change Docker Desktop to use windows containers in order to build and test)
Streamlit
add .streamlit/config.toml file with
[server]
headless = true
since only linux hosts are considered headless, and if not then the container exits by trying to open a browser.
Trying this now, but my Docker-fu isn’t very strong. When I swap in the FROM python:3.7-windowsservercore-1809, my container build errors with a no matching manifest for linux/amd64 in the manifest list entries.
I’d agree with you if you think that it’s very weird that Azure makes it extremely easy to add Azure AD authentication, extremely easy to add WebSockets forwarding, but almost impossible to check both checkboxes at once, without ever notifying the user that what they’re doing might not work. You get the feeling that they’ve just checked the items off a feature checklist, then never bothered to deal with the common use case of combining them.
Anyway, I’m not sure it’s fair to say that its unconfigurable altogether though; after all, it’s all just OAuth 2.0 with Microsoft as an identity provider under the hood, so you could always just wire the auth yourself; Microsoft’s adal package does make it relatively straightforward to factor away the Microsoft-specific parts of the implementation (cf. e.g. this Hello World example).
Of course, the moment you’re writing your own middleware to handle the auth, no matter how light-weight it might be, you’re kind of straying away from the “create something simple fast” mentality that makes streamlit.
After being stuck on this for the past 3 months, I finally found an solution: pay more…
According to a similar thread on AAD + Web Sockets + Linux container, you only need to choose a production instance
It’s not documented anywhere, and the Azure support I reached to back in Feb didn’t even suggest it.
It didn’t work on the my original B3, but it works seamlessly on a P1V2.
I’ll reach out to my company’s Azure rep to clarify what justify this paywall (and at least to document it).
I can confirm that if on a production workload in AppService, streamlit app will load, but uploading files using st.file_uploader returns a 403 Forbidden error when authentication is on. Error goes away when auth is off. Anyone here experienced that?
I’m also struggling with the file_uploader issue when authentication is on. I noticed that the _xsrf cookie, which is required by file_uploader if enableXsrfProtection = true, is not present when authentication is on and therefore the xsrf token is not passed in the header when uploading the file. When I disable authentication, it shows up and everything works:
