search

neos / redirecthandler

The Neos.RedirectHandler package for Flow
MIT License
4 stars 15 forks source link

Escaping of brackets "(" and ")" in redirect for assets #55

Closed GuangHa closed 2 years ago

GuangHa commented 3 years ago

Description

Replacing assets in Backend of files with brackets in the filename doesn't do the redirect correctly. I think the problem lies either in the encoding of the sourcepath for inserting into the database table or in the decoding of the redirect. This is an example on how it is stored in the database: _Resources/Persistent/9/0/f/f/90ffd2359008d82298821d16b21778c5c39aec36/Table%20rates%20%28Status%20as%20of%2030%20September%202021%29.pdf

This is how it tries to find the entry in the database (I think it uses the function getOneBySourceUriPathAndHost from redirectStorage): /_Resources/Persistent/9/0/f/f/90ffd2359008d82298821d16b21778c5c39aec36/Table%20rates%20(Status%20as%20of%2030%20September%202021).pdf

As you can see the Brackets () are either not correctly saved in the database or it is not decoding correctly in the redirect.

Steps to Reproduce

  1. Upload Asset with a filename that contains brackets and open it in a browser (in my case I used a pdf)
  2. Use the replace asset function, check both checkboxes (keep filename and do the redirect of the old url)
  3. reload the asset in browser (the link to the resource)
  4. It loads a 404 site instead of redirecting to the new resource

Expected behavior

Loading old resource url should redirect me to the new resource

Actual behavior

It leads to a 404

Affected Versions

Neos: 5.3 Flow: 6.3

kdambekalns commented 3 years ago

I tried this with:

Following your setps leads to this in the database:

The encoded variant is used for both source and target, that is correct.

image

Reloading the URL of the asset shows the new asset after a redirect, that is correct. Link-Redirect-Trace

Typing in literal ( and ) in the URL leads to a 404, but that is to be expected.

Whyt exact versions of the redirecthandler packages are you using?

kdambekalns commented 3 years ago

Might have been solved by https://github.com/neos/redirecthandler/commit/7940cd399461c29d72e12b985791e5d5df86a83b (is in since 5.0.0, 4.0.4)

kdambekalns commented 3 years ago

Could it be you run into the "default rewrite rules" trap? See first thing in the Configuration section:

Note: When using this to handle redirects for persistent resources, you must adjust the default rewrite rules! By default, any miss for _Resources/… stops the request and returns a 404 from the webserver directly: […] For the redirect handler to even see the request, this has to be removed. Usually the performance impact can be neglected, since Flow is only hit for resources that once existed and to which someone still holds a link.

GuangHa commented 3 years ago

Could it be a problem in Firefox with the encoding?

This is before i replaced the file (with keeping the name as is): grafik

After replacing and calling the same url I get a 404-error. If I copy the same url and open it in Chrome the redirect works.

Firefox-Version: 94.0 These are the version of the redirecthandler-packages: grafik

kdambekalns commented 3 years ago

How do get that URL? And what is actually sent by Firefox (see Network tab in the developer tools) when you open that URL?

I did some more tests, using an image with parentheses in the filename as well as a PDF document linked in the content. This is the source code:

image image

In Both cases the source code has the correctly encoded parentheses. The same is shown in the web developer tools DOM inspector.

Using "copy (image) link" in Firefox gives me:

Now I replaced both fles with something else, creating a redirect and keeping the name.

I cannot reproduce this, and would still assume the redirect handler is not even invoked, because Apache stops handing the request due to the standard rewrite rules being used. The fact this works in Chrome speaks against this. So I tried to manually enter http://neosdev.localbeach.net/_Resources/Persistent/d/7/5/e/d75ea21c3e85e5d2b828cb5f50e9bf518aa103bc/content-5%20(copy).gif in Firefox and Chrome. Both resulted in a 404 for me.

GuangHa commented 3 years ago

It might be a problem with copying the link. Weirdly when i copied to a new tab in Firefox it uses ...sample (test).pdf and when i copy it to a chrome tab it uses ...sample%20%28test%29.pdf. I will check again with our client about this problem and will report back here...if there is no problem anymore I will close this.

GuangHa commented 2 years ago

Seems to be solved, I also cannot reproduce it anymore, I will close this issue.