Hey guys, i’m new here, and i’m trying to redirect a feature in my website. It’s a running web page when the runners share their results with other runners.
The page to share the results is e.g.:
www.diariodecorredor.com.br/[email protected]
It’s redirects to www.diariodecorredor.com.br/[email protected] by .htaccess .
But my server start to block this requisition claiming to be attempted invasion. I can change this for another url, like www.diariodecorredor.com.br/[email protected] or www.diariodecorredor.com.br/[email protected] , but the first is better to share.
So i’m trying to redirect this in Cloudflare without results. I try:
(No need to specify https, but need to create two capture groups, which in Cloudflare are just the * character, that would then be transported in $1 and $2 respectively.)
However, as @sandro has pointed out, this rule results in an error, as I believe Cloudflare would not accept the special character @.
You could set the rule with the @ encoded as %40, but this would only work if you could control how the URL is input, which is not the case.
If everything worked fine, you then would face the issue of a loop, as the expression
I believe you’d be better off avoiding the CF page rule redirect altogether, and just create the redirect at the server level using a regular expression that can stop the redirect when it finds “filter.php”.
From what I understood, it is not so much the at symbol but the resulting redirection loop which is the issue. This could be prevented with aforementioned second page rule but the check does not take other page rules into account.
I tested this rule on my testing website with Chrome and Firefox and it did work as far as redirecting goes. Of course @andersonbravo would have to test it in his environment, and also take steps to make sure other issues won’t make this a bad experience for the user. I’m thinking browsers that send the already encoded URL request, which could result in a 404.
Also: if the website generates other, unrelated URLs that happen to contain an email address, they will be wrongly redirected to /[email protected], so definitely this need to be done carefully.
And credit where credit is due, @cbrandt made a very point about the URL encoded character, otherwise we’d be still fighthing the rule parser and its conviction of a redirect (which is actually not wrong, if it werent for the first rule).
