Unable to Load Images in Portal Due to 403 Error Despite Administrator Access

[Abdallah-Awwad]

I've noticed that when I log into the portal (even as an administrator) and try to view any organization's folder, I can see the available cards for existing images, but they never load.

When I checked the network tab for the images, the response is 403. However, when I try to access the image with Postman, for instance, and attach the token, it can be viewed normally.

To reproduce :

1. Make a fresh copy.
2. Add any image to the Directus folder, for example.
3. Attempt to view it in the portal (files tab).

[ComfortablyCoding]

Thanks for the report! Is this using the latest agency-os version?

P.S. Looking into this it seems no auth/cookie is being set on asset requests making it a public request

[Abdallah-Awwad]

Thank you for considering! Yes, I'm using the latest version.

P.S. Looking into this it seems no auth/cookie is being set on asset requests making it a public request

Do we have a function in nuxt/directus SDK that allows us to attach authentication to asset requests?

[ComfortablyCoding]

Do we have a function in nuxt/directus SDK that allows us to attach authentication to asset requests?

We have a way to do so via cookies, which will auto attach to all requests including asset ones.

A temporary solution utilizing cookies with the current codebase is to add this code snippet

useCookie('directus_session_token').value = value.access_token

after this line https://github.com/directus-labs/agency-os/blob/019fd3c7e0aa227c13df9ac5f46f4d734cc52e6b/modules/directus/runtime/plugins/directus.ts#L30

In doing so we ensure all requests now have the correct cookie header and therefore proper access permissions.

[Abdallah-Awwad]

Hey @ComfortablyCoding, thanks for the info and sorry for the late reply.

I did try your suggestion, and I can confirm that a cookie named directus_session_token does exist on the client-side. However, the issue with the missing cookie in the request header persists.

I'm ready to dig deeper into this. Got any ideas on what to check next? I have more time to dedicate to troubleshooting now.

[ComfortablyCoding]

Hey @ComfortablyCoding, thanks for the info and sorry for the late reply.

I did try your suggestion, and I can confirm that a cookie named directus_session_token does exist on the client-side. However, the issue with the missing cookie in the request header persists.

Strange, from my testing adding that cookie should be all that is needed. It works fine for me once the above code is added at the location mentioned.

I'm ready to dig deeper into this. Got any ideas on what to check next? I have more time to dedicate to troubleshooting now.

Appreciate the offer but I would hold off for now. Once #100 is merged I plan to update the directus client to start using session mode which should resolve this issue.

[ComfortablyCoding]

I have opened #103 as the potential fix for this, please let me know if this resolves the issue for you. You might need to update some of the cookie rules for it to work.

[Abdallah-Awwad]

Thank you! I will try it as soon as I can

You might need to update some of the cookie rules for it to work.

Sorry, but what do you mean?

[ComfortablyCoding]

You might need to update some of the cookie rules for it to work.

Sorry, but what do you mean?

This should only apply to cross site setups (frontend and backend on different domains). For those setups the cookie settings/restrictions will need to be changed to SameSite=None and Secure=true on the backend for it to work.

[Abdallah-Awwad]

After reproducing the issue, I encountered CORS problems when I'm trying to log in (both locally and on HTTPS). Once I adjusted CORS_ORIGIN: 'true', it worked like a charm! 🔥

I think we need to update the docker-compose.yaml accordingly if that's the case.

[ComfortablyCoding]

Glad to hear!

In terms of changing the docker-compose file as that seems to be a setup specific setting I will leave it as is for now. If enough reports come in of the issue we can re-visit it.