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:
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking âAccept allâ, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.