Strange bug in st.file_uploader

I upgraded to 1.30.0 from 1.29.0 and am getting this strange Axios error when uploading a local image file. Any idea why this happens? (I downgraded to continue my work.)

I tried starting vscode, through which I’m running Streamlit, as admin but that made no difference.

image

2 Likes

I talked to our dev team, and their suggestion is that it’s probably a CSRF issue, and if that you use a custom deployment (e.g. with a proxy), you need to either:

  1. Disable CSRF protection
  2. Whitelist new _streamlit_xsrf cookie name in your proxy layer

@blackary Hi Zak - I’m running this on localhost on my PC. It’s through the vscode terminal window. I’ll upgrade again and try outside vscode just in case vscode has a built-in proxy that I’m not aware of.

Upgrading to 1.30.0 and running from the command line didn’t work. I don’t know how to whitelist _streamlit_xsrf (in my browser the cookie is _xsrf). I don’t have any proxies running. And I tried in Brave (shields down), chrome and edge.

Hey, @asehmi, thank you for testing!
it’s strange, have you tried deleting cookies and hard-refreshing the Stremalit app?

If that doesn’t help, could we have a short call next week, to try to debug together, if you have free time?

Hi - Yes, I tried incognito and several different browsers. In Brave, I turned off all shields. Eventually, I managed to get this working by setting the global config.toml server setting enableXsrfProtection = false. Not ideal, but had to find a workaround.

Happy to have a call next week.

1 Like

@kajarenc @blackary
Thanks for helping resolve the issue, which was solved by refreshing my tornado package installation. For some reason my version of tornado was pointing to a virtual environment file and probably hasn’t refreshed for years! @kajarenc suggested running pip freeze to check I had at least v6.1 (which I didn’t) and then I ran pip install -U tornado to upgrade to v6.3. After this we cleared the browser cache and hard refreshed my app, and saw the correct _streamlit_xsrf cookie was being saved in the browser cookie jar. This can be confirmed in the response header for the /health network call and the app cookie jar explorer in dev tools.

After this the file_uploader axios 403 error vanished.

P.S. I also set the default enableXsrfProtection back to true!

Thanks again.

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.