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.:
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:
That might be WAF. Do you have that enabled? If so, try disabling it
As for your page rule, it probably does not work as the pattern also matches the redirection URL and so probably goes in circles.
I presume you get the following error
The details would be
Forwarding URL matches the target and would cause a redirect loop
in this case.
I believe the rule you meant to ask would be:
(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
/[email protected] would also match your rule.
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.
Oh, I see… Then it’s possible to create the following rule:
…and have the filter.php handle the decoding of the URL!
Maybe :), would need to test it before I make wild promises
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.
@cbrandt, you might be onto something.
Aforementioned approach with the initial stopping page rule coupled with the URL encoded at symbol (to trick Cloudflare’s parser) should actually work
And in my posts, /filter.php should be /perfil.php
Not sure what you meant with your last response.
It’s work, but staying in looping when i click in a link in the page =/
Hey man, it works !! =] very thanks
Can you post a screenshot of your rules? The way I posted it should work.
Thank you guys. it’s work!
All right, excellent!
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).