Iām using a production workload of AppService so all issues with regards to sockets and getting stuck on āconnectingā¦ā (described here: https://discuss.streamlit.io/t/azure-appservice-with-authentication-issues) are fine, app loads correctly. Deployment is on a linux docker image hosted on ACR (Azure Container Registry).
However when a file gets uploaded into the st.file_uploader widget, the POST http request returns a 403 Forbidden.
I donāt know anything about Azure AD specifically, but I wonder if itās an issue that using file_uploader sends it through a different port, and the browser isnāt able to sign the requests (since we havenāt incorporated anything like that).
I donāt know, just thinking out loud. But it sounds like thereās a step missing to authenticate with AD Authentication.
I wonder if either of these links are saying what Iām thinking:
When youāre using file_uploader from the browser, I wonder if the issue is that Streamlit doesnāt have the AD token that you need. Similarly, I wonder if it would work with anonymous requests (second link).
Yes that was my suspicion as well, will look into adjusting the service principal, will let you know if it makes a difference. Although if that were the case I would expect all endpoints to be problematic, including healthz and stream; otherwise thereās something special about what upload_file is doing on the backend.
As for anonymous requests, yes it does work as I said in my original thread.
Unfortunately Iām also unfamiliar with AD authentication but one thing the upload_file endpoint does differently is requires a XSRF token. You could try disabling server.enableXsrfProtection to False to see if thatās the issue.
Just to add on regarding this, you can always change your log level config option with logger.level. The available options are error, warning, info, or debug.
I deployed my streamlit app to azure and I am facing similar issue with st.file_uploader(). This is not consistent. Sometimes the file uploads properly and move to next action and most of the time it doesnāt work as expected. Could you be able to figure out the resolution for it.?
Do I need to make any specific configuration on Azure machine? or this is an issue with stremlit?
Unfortunately I havenāt found a resolution to this yet, even the latest file_uploader component suffers from the same problem. There seems to be something specific about how this component works thatās different from the rest of the streamlit because with AD authentication enabled itās the only one causing an issue.
Hi @JoeNSalloum Thanks for the reply. The issue got resolved for me.
Here is the observations on my case:
While testing the application in the local docker container. It all worked fine for me. The reason being in the local it allocates only one pod for running the entire application. All uploads being referenced within the same pod.
Whereas; On Azure machine - Based on my replica setting, it created 4 pods on the server and the load balancer doesnāt properly handle the calls across pods. So I changed the number of replicas to 1 and the issue is no more. It got fixed. I am using almost 10 file_uploader() in the app and all works fine for me.
I am not a devops person but it worked for me with the help of my devops engineer.
Thanks for the info, so it looks like youāre using AKS (Azure Kubernetes Service) as opposed to AppService pulling an image from ACR (Azure Container Registry) and spinning up a single (or multiple - if you scale out) container. In my case I solved the problem of multiple nodes by setting what Azure calls the ARR Affinity cookie; essentially a way to guarantee stateful applications to always hit the same node on the backend in a multi-node setup.
I tried your suggestion and brought down the number of nodes/VMs to 1 - same issue, but I thank you for taking the time to share your experience with everyone else
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.