WYSIWYG Image Access_Token

[ccu-jesseg]

I'm trying to add public files such as images to a collection using the WYSIWYG and Directus adds an access_token parameter to the image reference URL behind the scenes. I assume this is the access token of the currently logged in user. Since launching a feature on one of our sites that leverages the WYSIWYG, our images fail to load randomly. I'm wondering if the access_token is expiring.

Is there a way to disable the access_token from being appended to file links or another way to solve this problem? Our public role is set to have read access to files so the access_token should not be necessary for access to the files outside of the admin site.

Thanks for any insight!

[lambdajack]

Hi, I am also having this issue.

I agree that the access_token appears to be expiring based on the api message received back.

THINGS I'VE TRIED:

1. Setting a static access_token to the images loaded into the WYSIWYG (whilst this appears to be set in the api dashboard, the request on the client still contains a completely different and automatically generated token).
2. Making all requests as admin using the Authorization header - even this does not override the expired access_token as the requests still fail as unauthorised. All other admin endpoints work fine with this method.. just the WYSIWYG images that fail.
3. Setting the entire api (including the hidden Directus system collections) as publicly CRUD accessible. (even if this worked it would not be a viable solution, but it seams the api respects the access_token above all else).

This is a significant problem as the src of the img's is seemingly generated by the WYSIWYG itself and there is no way to strip the url of the access_token ahead of time as the client loads the html dynamically. Not to mention that would be difficult/unreliable to parse at scale with large amounts of data.

Any help on this front is greatly appreciated. Thanks!

[lambdajack]

On further digging, it seems that the 'static access token' which you can provide to the wysiwyg interface panel does not actually save the token to the database, rather to the ui only.

Once the token is set, it correctly appears in the box:

	<div class="field half">
	        <div class="type-label">{{ t('image_url') }}</div>
	        <v-input v-model="imageSelection.imageUrl" />
        </div>

however as soon as the image is saved, the image which is served becomes the users long automatically generated access token again.

STEPS TO RECREATE:

1. Create a wysiwyg field and set the 'Image Token' in the interface panel to any string you like.
2. Go to the collection and add an image to the wysiwyg field. You should see that your Image Token appears in the Image Url field.
3. Save the image with your custom Image Token.
4. Save / publish the collection etc.
5. Request the collection - notice that the access token is an automatic generated string.
6. Go back to the wysiwyg field and 'edit' the image - notice that the Image Url does indeed show an automatically generated string and not the Image Token you set in the interface.

QUESTION:

Are these Image Tokens that we set in the interface suppose to have an infinite TTL which would remove the problem raised above? If so, is there a way to set the permissions or does it only allow access to the specific asset it is attached to?

[rijkvanzanten]

Are these Image Tokens that we set in the interface suppose to have an infinite TTL which would remove the problem raised above? If so, is there a way to set the permissions or does it only allow access to the specific asset it is attached to?

The static access token is just a way for the admin to inject an access token of their choosing. We built it with the static tokens in mind, as those have an infinite TTL. This token can be associated to a user/role with only read access to directus_files, with a specific filter to only allow for the chosen files.

The way I tend to use it is by creating 'public' folder in file library, configuring the wysiwyg to use that for files, and then add a static token that only has read permissions to files where folder = public folder. That allows you to keep everything private (including files), and only share the bare minimum with the outside world through the wysiwyg