404 when trying to edit or remove path containing a slash

[squareclouds]

hi everyone,

i just realized that when i have a path with a slash, lets say

blog-referenzen/(:all)

or

de/uebermich

that i am redirecting, it works fine, but when i try to either remove or edit them in the panel the popup/modal does not open and i get redirected to 404, so i have to delete them by hand in the yaml

--

Steps to reproduce

1. setup a path with a slash to be redirected somewhere
2. after saving it, try to edit it

Expected behavior

modal opens up and you can edit (or delete) the entry

Additional context

Context

• Browser: latest FF and Chrome
• Kirby version: 3.6.2
• Retour version: 4.0.0

[medienbaecker]

This also happens when you try to resolve or delete entries in the "failures" tab.

[createdbyarc]

Hi also experiencing something similar - unfortunately I need to redirect a lot of urls with forward slashes - thanks in advance.

[bogdancondorachi]

Hi also experiencing something similar - unfortunately I need to redirect a lot of urls with forward slashes - thanks in advance.

Happens to me as well when trying to edit or delete a redirect

[distantnative]

I am sorry that this hasn't been fixed. I keep trying to reproduce the bug on my side from your screencasts etc but no luck, always works fine for me.

Can you all share the following details:

• what's the path of that entry
• what's the redirect to of that entry
• where does the Panel take you when you try to edit (which URL)

Thanks a lot!

[bogdancondorachi]

Hi @distantnative, thanks for getting back. I know you are busy on Kirby right now. Here's my details on the bug

IMPORTANT: this error seems to appear only on entries that contain an /

These are my entries

and if I try to edit them or delete them, I get a 404 the url seems looks like this "https://hasty.ai/panel/dialogs/retour/redirects/content-hub%2Fsoftware-engineer/edit" "https://hasty.ai/panel/dialogs/retour/redirects/content-hub%2Fsoftware-engineer/delete"

Also, I get the same 404 on any failures entry with an / when I try to 'add as redirect' or 'remove' an entry (clear log works fun) https://hasty.ai/panel/dialogs/retour/failures/.aws%2Fcredentials/delete

My kirby runs on 3.6.6 on php 8.0.20 and apache

[code-blep]

I have also encountered this issue on a clients website. This issue is easily replicated by installing the demo version of Kirby. If the URL (after the TLD stuff) has a slash in it, it breaks. Hate to say it but this makes this plugin pretty much unusable.

After various tests, I suspect that the issue is in the index.js file, but because it has been minified, it is not practical to work on.

[FynnZW]

Having the same issue. Any slash breaks opening the edit modal. The url is https://www.mydomain.com/panel/dialogs/retour/redirects/projekte%2Ftest/edit

It is working correctly on my local valet / nginx server. But failing on the production apache, with this configuration:

1. htaccess is forcing SSL and www
2. config.php has url - option set with full domain name ('url' => 'https://www.mydomain.com')

It is this setup: https://forum.getkirby.com/t/how-to-force-www-and-not-break-the-panel/13718

[tobimori]

Might this be an Apache issue? For me it runs fine on the PHP dev server, and my nginx instances, but not on production Apache.

Edit: It seems like an issue with Apache, see https://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes - this is the case if you get a 404 error from Plesk/Apache/cPanel/etc. It might also happen when you use Apache behind a nginx Reverse Proxy, then there's probably a setting there to fix that - this seems to be the case if you get a 500 response from Kirby that the view couldn't be found.

Edit 2: In order to fix this issue, no matter the servers' settings, it would be beneficial to switch to another way of encoding the path, e.g. browser-safe base64 without slashes, see https://www.php.net/manual/en/function.base64-encode.php#103849.

[ieteo]

1. Adding AllowEncodedSlashes NoDecode fixed the issue on Apache instances. Thanks!

2. In order to fix this issue, no matter the servers' settings, it would be beneficial to switch to another way of encoding the path

Sharing the same thought +1

[distantnative]

@ieteo thanks for the setup fix for everyone and also thanks for figuring out why - I was really clueless since it worked in all my setups. I will have a look how we could encode the path differently.

[ieteo]

@distantnative the credit goes to @tobimori. He is the one who figured it out and proposed possible fix in code regardless of the web server used.

His idea to base64 encode the path is quite interesting. I have just tested the encoding between JavaScript (FF and Edge) and PHP8 and it works like charm.

JS btoa("/path/subpath/etc/document?param1=foo&param3=bar") outputs: L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy"

PHP \base64_decode('L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy') outputs: /path/subpath/etc/document?param1=foo&param3=bar

and it can also be done the other way around

PHP \base64_encode('/path/subpath/etc/document?param1=foo&param3=bar') outputs: L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy

JS atob("L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy") outputs: /path/subpath/etc/document?param1=foo&param3=bar

To summarize

PHP base64_encode() is equivalent to JS btoa() PHP base64_decode() is equivalent to JS atob()

[tobimori]

@distantnative the credit goes to @tobimori. He is the one who figured it out and proposed possible fix in code regardless of the web server used.

His idea to base64 encode the path is quite interesting. I have just tested the encoding between JavaScript (FF and Edge) and PHP8 and it works like charm.

JS btoa("/path/subpath/etc/document?param1=foo&param3=bar") outputs: L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy"

PHP \base64_decode('L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy') outputs: /path/subpath/etc/document?param1=foo&param3=bar

and it can also be done the other way around

PHP \base64_encode('/path/subpath/etc/document?param1=foo&param3=bar') outputs: L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy

JS atob("L3BhdGgvc3VicGF0aC9ldGMvZG9jdW1lbnQ/cGFyYW0xPWZvbyZwYXJhbTM9YmFy") outputs: /path/subpath/etc/document?param1=foo&param3=bar

To summarize

PHP base64_encode() is equivalent to JS btoa() PHP base64_decode() is equivalent to JS atob()

Just a hint: Base64 contains slashes by itself, so we would need to replace them after encoding/before encoding manually to make it "URL-safe".