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 Mustafa,
great to hear and thanks for your quick response.

Your first snippet works also for me, the second one not.

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

Worked.

The token Link has now no redirect_to param.

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

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

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.

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,

Hello @agenciesfirst,

I’m excited to announce the release of Magic Login v2.1! This latest update enhances security by encoding the target URL, effectively addressing the issues encountered with nG firewall in our testing environment.

To support this improvement, I’ve also published comprehensive documentation specifically for configuring nG firewall with Magic Login, which you can access here: https://handyplugins.co/magic-login-pro/docs/ng-firewall/

Given that the previous solution has successfully resolved your concern, I’ll be marking this thread as resolved. If you have any further questions or need additional assistance, please don’t hesitate to reach out.

Regards,