st.file_uploader with Azure Active Directory - error 403 [August 2023]

Good morning!

I noticed recently (August?) that I am not able anymore to upload files on my Web App.

It is deployed on Microsoft Azure and it ensures that only people from my organisation have access to it via Azure Active Directory.
Until August 2023, I was using the workaround: enableXsrfProtection = false (which was fine for the uploading).

Since August, this is no longer working.

Any idea how to proceed? Thank you very much!

1 Like

Hi, I am encountering the same issue as well. Uploading works as long as authentication via Azure Active Directory is turned off. Once it is enabled, I can no longer upload files on my app. The workaround doesn’t work with me either. Thanks for bringing the issue to light!

Hi @aelbadry , @Adlef ,

Can you try using Streamlit v1.26.0? Several bug fixes related to the st.file_uploader were merged recently, so maybe using this latest Streamlit version helps. Let me know!

Hi @marduk,

I tried with the new version of streamlit 1.26.0 but unfortunately it didn’t change anything :frowning:, even with the workaround implemented.

Hi @marduk,

The issue is still persisting with the updated version.

Thank you both for checking! Just had a better look and this issue is frequently discussed on the forum. (My guess is that an HTTP request is triggered when a user attempts to upload a file, and that request isn’t picking up on the Azure Active Directory authorization headers.)

Not sure if this works, but a user in one thread recommends the following configuration in the .streamlit/config.toml file:

[server]
enableXsrfProtection = false
enableCORS = false

This was also done. The application stops running and gets a reset when the option enableXsrfProtection=false.

I even checked the log of my webapp on Azure:
“container X for Y site is unhealthy, stopping site.”

Then, the WebApp is again pulling the image and restarts the whole thing.

Just want to add that this worked for me on a slightly different problem. I was getting an error when uploading a file on a streamlit embeded with IFRAME and it was all on the local network.

1 Like

We were facing the same issue today, also on Azure, with Azure AD Authentication enabled.

We’ve upgraded to streamlit 1.26.0 in our requirements.txt.
We’ve disabled XsrfProtection and CORS in our config.toml, which now reads like this (in case the other options are also interesting to anyone?)

[server]
runOnSave = true
enableStaticServing = true
enableXsrfProtection = false
enableCORS = false

After those two changes, it is working, no more error 403 upon uploading the files.

Hope that helps!

Also, I’ve noticed that in the Azure webapp settings there a section about CORS. Ours looks like this:

2 Likes

Unfortunately, I followed the same without success:

[server]
runOnSave = true
enableStaticServing = true
enableXsrfProtection = false
enableCORS = false

CORS disabled as in your screenshot in Azure.

When I try to upload a file, the app stops and starts again from beginning :frowning:

Thanks anyway for the help!

Unfortunately, after all recommendations here I am not able to solve the issue :frowning: .

Anyone has a clue about the different settings to do on Azure side?

Thank you!

I am still having the issue as well and none of the recommendations worked either.

Bump, same issue here as well. Followed the creation and two lines to the config.toml, published to Azure Web app, ensured the CORs setting was the same and still having the same problem.

+1

Also experiencing the same issue. Tried the steps above with no luck.

Anyone found any resolution to this?

Thanks

I can’t explain how and why but by performing an update of all my python packages involved in my appplication I am now able to process any document on Azure cloud.

Additionally here are my settings (in config.toml):

[server]
enableXsrfProtection = false
enableCORS = false
[browser]
gatherUsageStats = false

Thanks for sharing.
How did you upgrade your packages? I do it cia CI/CD and it is
My understanding all gets reinstated from scratch in every deployment. Unfortunately last time I tried these settings it still didn’t work.

Update: Just did another update with your settings and it then worked, woohoo!

1 Like

hey did you solve the issue?

Yes, it has been solved. :slight_smile: