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.

[dominic-r]

Rebased to 2025.2.2