Can't log out, 403 forbidden

Actually I believe this is what worked.

Then I saved it and changed permissions to 404 to keep it that way.

The broken cPanel HotLink Protection Tool problem surfaces over and over on each BPS version release. The broken cPanel HotLink Protection tool problem also breaks WordPress in general. This problem has been going on for well over 10 years now. ??

To prevent this problem from occurring over and over we created this additional option – Turn AutoLock On.

Same issue as all the others (403) will try the AutoLock On. Seems like the upgrade should be more seamless than this, but such a great plugin I can’t complain (too much ;).

Yeah, we tried to figure out a way to hook into cPanel, but it is outside the capabilities of client to server interaction/relationship. Basically any check from a client site happens to late to prevent a server-side condition/tool/etc. ??

I tried the autolock – nothing. I deleted the plugin and now I get a 404 error when trying to load /wp-admin/ in Firefox or Safari. In Chrome, where I still had the admin open I reinstalled WordPress. I still have the 404 error. What happened exactly?

Am I going to be able to use this plugin anymore? It seems I can’t use AutoLock On and I need to keep plugin updates going (including BPS).

Please advise

Delete your root .htaccess file and wp-admin .htaccess file. Go to WordPress Settings >>> Permalinks and resave your permalinks. There is another issue that appears to be occuring on Host’s with mod_security installed – the new Brute Force Login protection code could be the cause of your particular site’s issue/problem.

https://www.ads-software.com/support/topic/wp-is-dead-after-upgrade-bps-to-493?replies=8

got it – working again. thanks. will there be an easier (more foolproof… me being the fool) way to update this plugin so I can use it again? I liked it, but this is a difficult thing to manage in terms of updating and there might even be a restriction on my host which prevents me from using it seamlessly.

Yep, we have designed BPS to work on the 1,000’s of Hosts worldwide, but there are at least 3 known Hosts worldwide where BPS just will not work. I imagine there must be at least a few more. ?? .htaccess files are distributed configuration files (basically Server config files that have less juice/limited juice) and yes there will always be other factors in any environment to take into consideration. We have done our best to make BPS compatible right out of the box, but would never kid ourselves into believing we could make BPS work perfectly in every possible scenario right out of the box. Most folks just have to click and shoot and others are not so lucky. ??

If BPS does not work right of the box for you then you can either bail or mess around with BPS. Up to you of course. ??

I would have normally been more specific as to what code I deleted, but because it is working and locked, I don’t want to go in there again and do it. ?? I guess I will though, you’ve been much help. I’ll do it tonight.

The autolock has always been on because after it creates the files and i enbale them, the permissions are automatically set to 404, which I often have to change because I often have to go in there and change some things and then i relock it manually through ftp permissions.

Regarding the rewrite base:

Okay, that makes sense.

My website structure is:

example.com/exampleblog

and example.com/exampleforum

within example.com i have an htaccess at the moment that has rewrite base:

/exampleblog

and in exampleblog htaccess folder i currently have:

/exampleblog

(which you correctly said that BPS does for you.

Based on what you said, my htaccess in my example.com root should be

/

I will change it. My question is, then why does it still work with my current configuration?

Also, when I update permalinks in my wordpress install (which is in /exampleblog) what htaccess does it modify? the one in example.com/exampleblog or in example.com/?

This will clear a lot for me…

Thank you
Jose

WordPress does internal rewriting for permalinks and also creates an .htaccess file to create the correct “base” for the site and creates some basic/standard mod_rewrite code/rules to ensure that everything works correctly. So to answer your question about permalinks specifically what happens when you save your custom permalinks is these are DB options that are stored in your database and WordPress uses these DB options to rewrite your URL’s based on the custom permalink options/tags that you have saved. Nothing changes regarding the .htaccess code when you change your custom permalinks – this rewriting is done internally by WordPress using PHP code.

Not really sure about your first question so I’m going to go with – “if it ain’t broken then don’t fix it” ha ha ha. ??

And just to put you at ease – as long as you click the BPS AutoMagic buttons before activating BulletProof Modes you are guaranteed to have the correct .htaccess code created for each of your websites.

Thanks for some extra info regarding the process.

I take it back, it appears you were right. My root .htaccess has a rewrite base of:

/

and my WP install subfolder has a rewrite base of:

/exampleblog

It is good to know that BPS will use the right rewrite base.

Also, everything is currently working with an edited .htaccess. I will enter the code I deleted next as I promised.

Okay, so even though things were working just fine, I went ahead and FTP’ed in there and downloaded the edited htaccess I had, which was working, and went to WP and did the automagic buttons again for secure htaccess file. Then I activated both /exampleblog root folder and wp-admin folder.

As expected, upon logging out I got the 403 error.

Then I removed:

# BRUTE FORCE LOGIN PAGE PROTECTION
# Protects the Login page from SpamBots & Proxies
# that use Server Protocol HTTP/1.0 or a blank User Agent
RewriteCond %{REQUEST_URI} ^(/wp-login\.php|.*wp-login\.php.*)$
RewriteCond %{HTTP_USER_AGENT} ^(|-?)$ [NC,OR]
RewriteCond %{THE_REQUEST} HTTP/1\.0$ [OR]
RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
RewriteRule ^(.*)$ - [F,L]

and “Head” from:

RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]

And removed this:

# BuddyPress Logout Redirect
RewriteCond %{QUERY_STRING} action=logout&redirect_to=http%3A%2F%2F(.*) [NC]
RewriteRule . - [S=6]

Once I removed those items again, I changed permissions back to writeable in FTP, uploaded the edited htaccess again, refreshed WP and logged out–no problem.

I don’t think “Head” has anything to do with it.

It is one of the other two things, and I don’t think it is conflict with other plugins because this was working well with other plugins before the update.

And since this began to happen, I went into BPS>login security>Turn off/on>turn off login security (which I thought would remove that login related code that gets generated in the htaccess, but it didn’t).

Which is why I went in there and took that code off manually and that’s how I got the logout to function again.

PS–after you analyze the information I’ve provided, can you also let me know if my site is safe in spite of the code I’ve removed?

Thank you,
Jose

The BuddyPress Logout Redirect code is very old code so we will take a look and see if it needs to be removed. Our BuddyPress Forum is not affected in an adverse way by that code, but your environment/setup might be a bit different. Most likely the cause of the problem is the new Brute Force protection code. We will be releasing a new BPS version as soon as we can. Thanks.