Redirection using a Regex expression that matches a role or login status redirects to the "unmatched" URL

[sforeman]

To help track problems please follow this template. If you can provide screenshots then that will help.

Summary

I am trying to redirect from a URL pattern to an image file, but the image is only to be served if the viewer is logged in with the correct role.

Actual Behavior

I am trying to take URLs of the form {mysite}/id/yyyy.zzzz.ext onto the destination {mysite}/target/yyyy/yyyy.xxx.zzzz.ext

using the regex $/id/(.{4})(.*)$ with target {mysite}/target/$1/$1$2

This works as expected if only the URL is processed. However, I also want to match the role of the person who is logged in. When this extra condition is added, the redirection always goes to the "unmatched" URL.

Steps to reproduce

Create a redirection using a regular expression. Set the requirement for the role (or login status) to be matched. Specify a target URL for matches, and one for unmatched.

Environment

This applies to Edge (Version 114.0.1823.58), Chrome (Version 114.0.5735.199) and Opera (Version:99.0.4788.88) browsers. Wordpress (6.2.2) Redirection (5.3.10)

[johngodley]

This shouldn't make any difference. Check that your expression is actually matching the URLs, and also you are not running into any of the problems listed here:

https://redirection.me/support/problems/url-not-redirecting/

Failing that it is likely to be a caching issue.

[sforeman]

Hi John,

that's what I thought and tried clearing caches on the server and browser.

Today I have done a series of tests where I used a different input URL for each request. I have "masked" the output folders by changing the top levels of the output paths.

The input Regex was: ^/ttt/(.{4})(.*)$

And the matched destination was: /FOLDER/$1/$1$2 The unmatched destination was: /not-allowed/

This should have eliminated cacheing as the input URLs were different for each call, and the logged in and logged out tests were performed on different browsers (Opera for logged out, Chrome for logged in).

The results are below.

Input Match type Output destination ===== ========== ================== /ttt/1991.001.0026.jpg URL only (Logged out) /FOLDER/1991/1991.001.0026.jpg /ttt/1991.001.0027.jpg URL only (Logged in) /FOLDER/1991/1991.001.0027.jpg /ttt/1991.001.0031.jpg URL+Role (logged out) /not-allowed/ /ttt/1991.001.0032.jpg URL+Role (logged in) /not-allowed/ /ttt/1991.001.0033.jpg URL + login status (logged out) /not-allowed/ /ttt/1991.001.0035.jpg URL + login status (logged in) /not-allowed/

[johngodley]

Did you look at the things listed on https://redirection.me/support/problems/url-not-redirecting/? Specifically the ones regarding redirecting images.

This problem is almost certainly something specific to your setup.

[sforeman]

Thanks John.

Yes, I had looked at the issue about redirecting images and other common file types, but as the regex redirection worked without adding the additional test against status I hadn't realised that the system could intervene after Redirection had started processing the URL.

I have now changed the input URLs so that they do not appear to be known file types (-jpg etc instead of .jpg) and I am using the regex to reconstruct the original file name. This works, so I have a way forward.

However, that still leaves me puzzled because just using the regex to create the new URL for redirection works. The problem only arises when the additional constraint of checking against login status or role is added.

The whole process works as I would expect f I use a random sequence of letters without a file extension - logged out I get the /not-allowed/ page, and logged in I get a 404 (because the file doesn't exist, nor does the equivalent page).