Archive download link does not respect S3_ALIAS_HOST setting

[davetroy]

Steps to reproduce the problem

1. Request an archive of your account
2. Click "Download your archive" Link in Email notification
3. User is redirected to link based on S3_ENDPOINT setting, not S3_ALIAS_HOST
4. Manually replace S3_ENDPOINT value in link with S3_ALIAS_HOST; download will work

Expected behaviour

User should have received link based on S3_ALIAS_HOST

Actual behaviour

User received link based on S3_ENDPOINT

Detailed description

Requesting a download of one's account archive produces a user-facing link to S3_ENDPOINT instead of S3_ALIAS_HOST. In our setup, this will not work, because S3_ENDPOINT is a private VLAN-accessible endpoint that we do not want to expose to end users. S3_ALIAS_HOST should be used instead, as it is for the distribution of other user-uploaded files.

Specifications

Mastodon 4.1.1
Ruby 3.0.4p208
PostgreSQL 15.1
Redis 5.0.7

[Dominion0815]

same problem here

[daniel-naegele]

We are experiencing this issue on our instance with version v4.1.2

[davetroy]

I poked around a little bit in the code to see if I could understand what was going on here and it looks like it may be something related to the Paperclip gem and how it's being called or configured. I don't know enough about the particulars of the implementation here to know what the problem is, though. Maybe something different between the web and mailer environments when rendering the link? 🤷‍♂️

[codl]

It doesn't only affect the download link in the email but also the download link in import/export settings.

I managed to work around this with nginx since both links actually point to the mastodon server, which then redirects wrongly. If using the recommended nginx config, replace

mastodon/dist/nginx.conf

Line 144 in f877aa9

proxy_redirect off;

with

proxy_redirect http://192.0.2.69/my-bucket/ https://media.example.net/;

where http://192.0.2.69/my-bucket/ is your internal s3 endpoint and https://media.example.net/ is your public address. Nginx will intercept the redirect to 192.0.2.69 and instead redirect to media.example.net.

[davetroy]

@codl thanks! That solution seems to work. I did need to be sure to use https on the internal endpoint for it to work. (I figured that would be the case.)

Perhaps the best solution for this would be for the maintainers to include this setting in the documentation, if it's not already.

[ClearlyClaire]

This is an underlying issue in Paperclip (thoughtbot/paperclip#2196), but I am not sure how it is supposed to be addressed. I am unfortunately not knowledgeable enough in S3.

[davetroy]

The workaround of adding proxy_redirect seems to work okay. If that's added to the documentation, it should probably be sufficient for now. But perhaps the issue could be addressed at the Paperclip level as well.

[Maffsie]

@davetroy unfortunately doesn't work for me (on queer.party) as i'm not using Nginx as a front-end loadbalancer