Login link in mail has to many parameters does not work with 7G firewall

Hi Jan (@agenciesfirst)

Thank you for pointing this out. I’ve run into the same issue before and adjusted the 7G firewall rules to address it, specifically for cases involving “magic login” links with tokens and redirects, to avoid unintended blockages.

eg:

# magic login links with token and redirection can cause blocking
if ($request_uri ~ "magic-login"){
    set $gfwreason "allow";
}

(It was the rule for runcloud; you might need to modify it like this)

if ($request_uri ~ "magic-login"){
    set $7g_drop_bad_request 0;
}

> But it could also be that the attached parameters are simply too long.

When I checked the firewall logs, the block matched with rule 16, likely due to the &redirect_to=https:// part. Encoding redirection URLs could be a better solution.

I’ve started working on a fix for this, which you can follow here: https://github.com/HandyPlugins/magic-login/issues/25

In the meantime, could you test the URL without the redirect_to parameter?

Cheers,

Hi @agenciesfirst,

I’m glad to hear that the snippet did the trick.

> Only token with “&magic-login=1” and that works, but is not needed.

I’ve added a custom magic-login parameter to enhance third-party support. It’s unnecessary if your login URL is wp-login.php (the default login URL), but it becomes somewhat problematic when users begin using plugins that rewrite or alter the default behavior of wp-login.php. This is because the URL structure changes, for example, to https://example.com/login/?token=login-token-here. (https://github.com/HandyPlugins/magic-login/blob/2.0.1/includes/login.php#L278-L285)

> Token only is enough, so when I cut out everything to token, it works.

Did you remove user_id too?

> Why you need the real https url handing over? Maybe it’s necessary for some setups or best practice coding rules I don’t know.

It’s designed for flexibility. Essentially, it enables the addition of redirection if wp_safe_redirect is capable of handling it. For example, you might have courses accessible at example.org, but you use example.com as your landing page. Once people log in to your “members only” area, you might still want to redirect them to the landing page (I’m not sure why there’s a need for this kind of redirection, but it is what it is). So, it provides more flexibility in this way.

Of course, the target URL would be better in an encoded format; I will fix that in the next version. Based on my tests, if you send redirect_to in the encoded format, it doesn’t get blocked 7G firewall. (roughly tested)

I hope this helps.

Cheers,