Received attachments (mostly images) are not working

[PepeGonzalesNFC]

PHP version: 8.2.10
FreeScout version: 1.8.100

For some reason, we are getting an Access Denied message for all attachments that we receive via email. It is very strange.

Here is a URL that gives access denied: https://support.domain.org/storage/attachment/4/9/1/image.png?id=&token=

Here is a URL that works (just change the image.png file extension to any extension that does not exist): https://support.domain.org/storage/attachment/4/9/1/image.pnga?id=&token=

I am unsure if this is a bug from the system itself or a module.

[freescout-helpdesk]

1. Check if the attachment file exists in /storage/app/attachment/4/9/1/image.png

2. If attachment exists here is the place to debug: https://github.com/freescout-helpdesk/freescout/blob/dist/app/Http/Controllers/OpenController.php#L154

[HumaneWolf]

Following up on behalf of @PepeGonzalesNFC.

1. The attachment file exists.

2. The id and token is passed along in the url provided by your system, so the linked line is probably not the culprit. The other likely culprit in that file is line 170, as that actually compares values. However, I will stress that the exact link generated by the system does not work, but if we change the file name in the link it does. No other changes. Please have a look.

Our environment is based on the helm chart linked on your installation page, with a couple of tweaks to enable the container's Postgresql support. Freescout is behind a simple nginx ingress controller.

[freescout-helpdesk]

So now you need to figure out why token parameter in the attachment URL is not equal to $attachment->getToken() for your attachments.

if ($token != $attachment->getToken() && (bool)$attachment->public !== true) {
    return \Helper::denyAccess();
}

[HumaneWolf]

Alright, with some investigation we have found a solution.

Our initial suspicion was that it could be something in freescout, as the rest of our infrastructure is rather simple. We don't do anything special.

The issue turned out to be a combination of our Cloudflare CDN cache and the default caching rules sent by the docker container nginx config. This caused a few issues with how Freescout saw the incoming asset request.

We disabled the CDN cache for the support desk, which resolved the issue. From our perspective the issue can be closed then.