s3 custom_url makes signature verification fail

[benaryorg]

Describe the bug
When I upload a file to S3 and I have custom_domain set, I get an error.
I do not get the error with the custom_domain setting removed, even retroactively for existing files.

To Reproduce
Steps to reproduce the behavior:

1. use s3 backend with custom_url
2. upload flow background image
3. open flow
4. background image not loaded

Expected behavior
URL both with and without custom_url works.

Screenshots
not applicable

Logs
not applicable (signature calculates properly, it's just somehow wrong)

Version and Deployment (please complete the following information):

• authentik version: 2024.12.1 (the code around the signature doesn't seem like it has changed recently, and I don't have a good way to quickly upgrade for testing)
• Deployment: manual (issue is not deployment-related)

Additional context

This occurs with a radosgw running with Ceph squid (v19.2.0).

When the custom_url setting is off I get this URL:

https://s3.ovh.xn--idk5byd.net/benaryorg-authentik/media/public/application-icons/Grafana_logo.svg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ISXPUYU60051HVZ8LXX0%2F20250314%2Fdefault%2Fs3%2Faws4_request&X-Amz-Date=20250314T181538Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=253b6e3e445dff3b553b228a01f5ed685d30f5f6d6ef93db3c350c813e53c531

When it is on I get this one:

https://benaryorg-authentik.s3.ovh.ニャー.net/media/public/application-icons/Grafana_logo.svg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ISXPUYU60051HVZ8LXX0%2F20250314%2Fdefault%2Fs3%2Faws4_request&X-Amz-Date=20250314T181657Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=56a737db3aa170b5909fec7a6639cb9b96ccd48513db8666d30d56203001c5e1

Since it works with one but not the other (and the signature differs) we can probably assume that the following line is okay and works, despite the punycode domain:

authentik/authentik/root/storages.py

Line 109 in e87a17f

url = url.replace(root_url, custom_url)

The error I get is this:

<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><Message></Message><RequestId>tx00000d09c7361dc47e6cc-0067d0711a-2194166-default</RequestId><HostId>2194166-default-default</HostId></Error>

As to everything else, I wouldn't know to be honest.
If you need any further information (or a test bucket) I'm happy to help.

[rissson]

I wonder if this is specifically a punycode issue since it works with one URL and not the other. cc-ing @dominic-r since they looked into this part of the code recently.

[dominic-r]

I'll take note of this issue and release a fix with my upcoming PR. Thank you for reporting this. It seems to be indeed related to punycode...

[benaryorg]

I've edited the issue to put some new links in there which won't go away (the Grafana logo will live in Authentik forever, the flow background not so much).

I noticed that, yes, when I right-click "copy image link" and paste it here, only the latter URL actually gets turned into Unicode characters, so it may indeed be punycode.
Since I can't Ctrl+U in the dynamic JS environment to see the source, I would've had to check the network responses since I don't trust the inspector to not already run some processing on the strings anyway.

The config however clearly uses "xn--idk5byd.net" in both cases, it's literally the "custom_url" boolean that's on or off, same config otherwise.

[RemiKalbe]

I actually have the same issue without any punycode. If I use the aws cli to sign it manually there is no issue, for some reason Authentik is not generating the url correctly.

[benaryorg]

I can confirm that d1e1502 from #13406 works when rebased onto 2024.12.1.
I now have custom_url set and get links with correct signatures pointing to the given URl.

rebase process

git fetch origin pull/13406/head
git checkout --detach FETCH_HEAD
git rebase --onto tags/version/2024.12.1 HEAD~3 HEAD
# resolve merge conflict
git checkout @^ -- poetry.lock
git -c core.editor=true rebase --continue

At this point in time I cannot test with newer versions though.

[dominic-r]

Great! That's good, thanks for checking.

[authentik-automation]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[benaryorg]

not stale

As an aside, it's a terrible idea to configure auto-close for a stale bot.
Marking issues as stale via tags or something is fine, but closing them is just annoying for everyone involved and doesn't actually solve any issues.
Stale bots are just what people use when they can't afford to do proper triage, and since this issue has been properly triaged, the bot is evidently counter-productive.
To be fair, this issue notably lacks appropriate tagging for that purpose, something like "confirmed", and potentially a tag with affected authentik versions would be required to review whether an issue might still be relevant; i.e. the thing that stale bots are used for despite being utterly unable to solve that domain.

TL;DR: please stop using a shitty stale bot as an excuse to not do proper triage, it's just annoying for everyone.

[dominic-r]

p.s. I'll open a PR to fix this issue specifically as a large PR englobing a bunch of changes doesn't seem realistic time-wise for me at this time. Srry about the delay till resolution

[dominic-r]

Hey there @benaryorg I opened a PR ^^ which should resolve this issue. If you can, would it be possible to try it out in your environment to ensure everything works as expected. I don't have a punycode domain to try this on, so I'm relying on tests