Does amProtect throw 404 errors on your server?

Recently a small handful of people have emailed me about an issue they were experiencing with amProtect throwing a page not found error also known as a 404 error. It even started happening on my own servers.

This doesn’t happen if you hide your protected posts from people who are not logged in. But it can happen if you don’t.

When you provide teaser content in a protected post using the more tag and someone who is not logged in tries to read that post, amProtect redirects the reader to the aMember login script with a parameter in the query string that tells the login script to redirect them back to the permalink for that post. That method has always worked just fine…up until now.

But suddenly on hosts all over the place, including mine, it did not. So I had to track down why.

I first looked at the amProtect code to see if I changed anything that could cause this behavior. I looked at how I was url encoding the permalink and anything else I could think of. I couldn’t find a single thing wrong.

So the next step was for me to look at the /amember/login.php script and see if something was wrong there. I compared the recent 3.1.9 version to older versions and I couldn’t see anything different. I know there was a security fix for aMember recently so I thought maybe it had something to do with that. But as it turns out, it didn’t.

It wasn’t an aMember or amProtect issue, it was a server issue.

The redirect works like this:

http://kencinnus.com/amember/login.php?amember_redirect_url=http://kencinnus.com/somepage/

Of course the colons and slashes would be url encoded by amProtect but I just wanted to show you what was happening. If you typed that into the browser you would get a 404 error.

But if you typed this into the browser it would work fine:

http://kencinnus.com/amember/login.php?amember_redirect_url=/somepage/

Now logging into WordPress works the same way. Here is the URL for logging into WordPress:

http://kencinnus.com/wp-login.php?redirect_to=http://kencinnus.com/somepage/

I realized that was still working with no errors.

So I sent in a support request to aMember and asked them to help me out with it since I wasn’t getting anywhere. They took a look at it and told me to go ask my hosting company about mod_security and to make sure that AllowOveride All was set in my Apache configuration. They said that putting http:// in the middle of a URL was tripping a mod_security rule.

I have to apologize to Anton at aMember.com because at first I thought he was just not giving me his full attention. I mean…how could it be a server issue if WordPress worked but aMember didn’t? But I begrudgingly went to HostGator, where I host my site, and started a live online chat with a technical support person there named Matthew We.

The first thing I asked was for him to confirm that AllowOverride All

Then I told Matthew what was going on and asked if he knew what could cause it. He did.

Matthew explained that I was hitting a mod_security rule on their server. Sounded familiar.

After he verified that I was the proper owner of this web account it only took him about 5 seconds to whitelist my server for that particular script to work in that particular way in mod_security.

Anton knows his stuff. Sorry for doubting you Anton!

Since this has been happening to a lot of people lately I asked Matthew to tell me how to explain it to my amProtect/aMember customers so if they run into this problem they can get it fixed.

I asked him why it used to work and then stopped working. He said that this rule gets enabled/disabled frequently and that they had indeed changed it. It's a very common rule that prevents a common exploitation of WordPress sites, but the URL format is also used by a number of other scripts in a legitimate way...aMember being one of them of course.

He told me it was not something I could change myself. They had to whitelist it for me.

If your site is hosted on HostGator you can go to the support desk and request that they whitelist mod_security rule 1234234 for your domain.

If you are on a different host then the rule will have a different number but you can describe the situation and they will know what you are talking about.

Matthew says its a very common request that they get all the time and they can fix it fairly quickly after verifying that you are the actual owner of your site.

That's all I know about this.

Hope this helps!

All the best,

-Ken Gary