Authorization issue when downloading a resource

Support
1

Hello,

I have a folder that I have set to be private. When I try to download an item in this directory in the UI, I get the following message:

{ "message": "Read access denied for folder 5b6af63271d638e57307eb89 (user None).", "type": "access" }

However, if I use the girder-cli there is no issue and I can download the file.

Here are a few details about my configuration that may help figuring out what is up:

  • This instance of Girder was built from Git version 7c5cd54. API version 2.4.0.
  • For Routing I have core_girder set to /girder/, core_static_root set to /girder/static/ and api_route set to /girder/api/v1 in my girder config.
  • Girder is running behind an apache reverse proxy

Any thoughts on why Girder doesn’t recognize that I am logged when I try to download something in the UI?

Thanks!

2

any thoughts on this?

3

Revisiting this, it looks like when I login I get a 401 when girder try to setup a connection over the notification stream:

girder/api/v1/notification/stream?:1 Failed to load resource: the server responded with a status of 401 (Unauthorized)

The notification stream is enabled under the advanced settings, but the stream is still getting blocked and not sure why it is throwing a 401, which is not a code documented in the rest api.

4

Hello,

This could be a result of using scoped tokens created from an API key in the swagger page. If you did this, it would have overwritten your normal login token.

We fixed this issue on the server, but it was very recent, so your instance might not have the fix. As a solution, you can clear your cookies for the Girder server’s domain and log in again through the web client, and that should clear it up.

5

Hi Zach,

Thanks for the suggestion! I had already tried clearing cookies and was still seeing the 401 error and cookies were not being set.

On a hunch, I switched from running in production mode to running in development mode and for whatever reason cookies started being set again, even after switching back to production and clearing cookies. Not sure what that triggered, but its working!

Was this issue fixed on the master branch or on a branch that is consistent with the 2.5.0 documentation? If the latter, can you point me to it?