nerdynel17

Got it, thanks!

Hi: yes, I have the salt postfix feature enabled. Should I disable it until the fix is released?

Hi:

I’m reopening this topic because I’m having the same issue with cookie-based brute force prevention and 127.0.0.1 again. I can work around it by disabling cookie-based brute force via the constant, clearing my cookies and browsing history, then accessing my admin and reenabling cookie-based brute force. However, I have to do this every few days and for obvious reasons it’s not optimal. (For full disclosure, my host changed servers from Apache to Nginx in October of last year.)

For the record, I currently have the “Ban POST requests that have a blank user-agent and referer” setting disabled.

In one of the other topics, I saw that you’re working on a fix related to cookies and Nginx; would this fix also fix issues with cookie-based brute force prevention?

Yes, I have a caching plugin. I cleared all browsing history and cookies, then cleared my cache via the caching plugin, then disabled and reenabled brute force. This appears to have worked. I’ve regained access to the AIOS dashboard and I’m not locked out of admin (for now), so I’ll mark this resolved. I’ve had occasional issues with 127.0.0.1 redirects in the past, so I’ll continue checking for this issue.

Update: after continuing to troubleshoot, I have finally isolated the source of the issue. It was indeed a plugin conflict. One of the default plugins that came with my WordPress install – one that I hardly used – generated and continually updated the “Attribution” page whenever the site changed in any way. Since I really don’t need that plugin or this “Attribution” page, I deactivated and deleted the plugin, then reran Boost. No more errors – and Site Health now reports no issues!

Hi:

I’ve had a very busy week, but I downloaded the Health Check plugin and began the troubleshooting as recommended. I have not yet nailed down the issue as, even with most* plugins off and the theme switched to default, the same failure regarding the attribution page recurs.

I have not completed the troubleshooting, however, so I will report again if I find the root cause, or if I’m unable to find the root cause.

*Due to my hosting plan, some plugins must remain enabled for the site to work properly, so I left these on during the troubleshooting. If I’m unable to narrow down a plugin conflict, I’ll take this issue up with them to see if anything on the host end might be driving the conflict.

Hi Emily:

Thanks for checking my site’s Jetpack connection.

The Attribution link loads just fine for me; I tried it on both my phone and my computer on different browsers and it worked on all.

Hi:

Unfortunately, deactivating AIOS and then regenerating did not resolve the issue (but curiously, when troubleshooting with my host a few days ago, they didn’t see the issue after deactivating AIOS).

I tried flushing my caches (I have some caching plugins active), but the issue persists.

For now, I have restored AIOS and the firewall.

Sure:

To make things easier, I have uploaded screenshots of Site Health and Jetpack Boost (see links below).

Site Health notification

Jetpack Boost notification

NOTE: The Jetpack Boost notification is incorrect – I have not published any new posts or pages recently. However, this is the message that keeps appearing each time I update Critical CSS.

Of the settings you mentioned, I only had the 6G firewall and related settings enabled. I turned 6G and related settings off, per your suggestion, but I still have the issue.

Hi again:

Your suggestion worked and I have regained access to my dashboard with AIOS activated. As a sanity check, I then set the value to false, toggled the cookie-based prevention option in AIOS off and on, logged out, waited a short period, and then logged back in. I did not get the loopback error. Thanks!

• This reply was modified 1 year, 4 months ago by nerdynel17.

Update: My host was able to fix the issue with the SSL certificate. Thanks for assisting!

Hi:

Yes, I used Let’s Encrypt. I just checked this on my host and I do see the expiration; it normally auto-updates 30 days before expiration…

Hi:

Thanks for the response!

The caching plugin is provided by my hosting, so my options for managing it are limited. Do you know of any potential workarounds?

As for my security plugin, the “cryptic” URL you mentioned might be a result of one of the brute-force attack prevention features; could I send you a quick DM on Mastodon to discuss this further? I could try to tinker with the security plugin settings to see if the issue gets resolved, but I would very much like to keep the security plugin active…

It’s been a few days, and it looks like the custom firewall rules did the trick. Thanks!