503: Service Temporarily Unavailable

[drbyte]

Hi Jason,

Suddenly some of our members are getting the error above "Too many IP addresses accessing one secure area"

I looked over the forum and it seems some are still facing the same issue.

Not sure if it's related to the cron job as somebody mentioned above or simply related to another plug in that might be causing it.

It seems that the error started when All in One SEO Plugin & WP Super Cache were recently issued a new updates.

I also ran the Cron job manually to make sure by typing http://www.sitename.com/wp-cron.php

Now, something really interesting i read while browsing the support documents at my host company.
"PLEASE NOTE: You can NOT run any Cron in intervals less than 15minutes on shared or reseller hosting accounts."

Jason: Is there away to disable the IP restriction mode in your plugin?

Please advice

Thank you

Sam

[drbyte]

Updates:

It seems users who sign up between the new release and the one before are the only ones experiencing this issue.

The IP is not the one is restricting accounts, it's the usename. It seems that it got stuck somewhere where it can not be cleared.

I did a small test to one of my members. I tried to log in using her username and password from my location and sure it gave me the 503 error screen. So the IP address was not the issue (That's after clearing/reset the ip restrictions and doing the cron job)

Fix: The only fix I found is to delete the user account an re-create a new one using different username.

So far it's been working fine for lots of members.

Sam

[danisrael]

Jason,

This seems to be occurring around the 30 day mark for us. We've been using it for almost two months. Last time, we used the update to reset the logs. At the same time, I changed the setting to allow 10ips per 30days. However, user are starting to incur incidents of this problem.

Is there a way to troubleshoot this. To see what is taking place and causing the issue. Or to verify that it isn't abuse?

Dan

[danisrael]

One more item here...

Once a user begins to expierence this error, they are never able to log in. However, the preference option is only set to "punish for 15 mintues." Why doesn't this eventually allow them to log back in?

Also, could this very setting be part of the issue when running on Dreamhost? Is this causing the CRON jobs to run inside a restriction as stated above?

[danisrael]

Sam, did you ever find a way to troubleshoot this?

[drbyte]

deleting the member and re-creating the account worked for me

[danisrael]

I was hoping for a way to determine whether this is indeed Link Sharing or legitimate users issues. I can correct with the "reset logs" function added in one of the updates. Just unsure how to track down why it is occurring.

[drbyte]

if it happens to the same user and no body else then it's abuse and you should terminate the membership. Meaning if you have 500 members and only couple is having the issue over and over again, then you got something on them

[markelshark]

I too would like to be able to see the IP addresses the person connected with. I hope the system doesn't just have a counter. It should save the IPs so you can review them.

[eagle4life69]

Jason Answered this.
viewtopic.php?f=4&t=666#p2973

[markelshark]

No, Jason didn't answer the "can we see the IPs of the people getting these error messages?"

[webber]

I found the restricted IP's in Wordpress DB Option's
Do search for " s2m_ipr "
This will pull up ip restrictions fields with the ip addresses.

I also found out that even after resetting in Unique IP Access Restrictions:
Maximum Unique IP Addresses Allowed,
Security Breach Timeout Period,
Reset IP Restrictions Logs

I still had to wait for the previous Security Breach Timeout Period before the user could log in again.

Hope this helps

[markelshark]

That does help but did you figure out a way to associate any of those rows with actual users? I've searched for every string I can find in there and can't link it to anything else in the database.

This "feature" is particularly annoying because I have a lot of international users and many get new IPs each day. I keep resetting the logs but they still don't get access - I'm guessing it has to do with what you said where it has to wait for the timeout period. But some of the timeout periods are way more than the minimum period of 15m that I have set. For example take a look at this row:

"_transient_timeout_s2m_ipr_... 1291617048"

That timestamp corresponds to: Mon, 06 Dec 2010 06:30:48 GMT

December 6th??? I'm guessing this is a bug where it keeps adding to the timeout each time a failed login occurs?

Jason, I know you've been gone recently but I really think this needs your attention to resolve.

[markelshark]

Ok, for anyone who has this same issue here is how I reset the IP restriction for a particular user. Just to recap the problem is that some international users (specifically Germany) can generate a new IP every 24 hours due to some weird ISP stuff that have over there (source: http://de.wikipedia.org/wiki/Zwangstrennung). On top of that there is some bug in S2member where the logs are not getting reset entirely (timeout penalties) and may not be incrementing correctly (I had some penalties dated for December and I've got it set to a 15m penalty).

So in short some users would get locked out with 503 errors and no matter how many times I hit the reset button in S2member those users were not able to gain access unless the signed up for a new account each time.

So... thanks to Webber's sleuthing above here is the resolution:

1) have the user send you there last IP address. In this example we'll pretend the IP address is xx.xxx.xx.xxx.

2) Go into phpMyAdmin and search your wordpress database for that IP address. It should pull up a row in wp_options that contains a column called 'option_name' that look something like this:

a:2:{s:14:"xx.xxx.xx.xxx";i:1284444427;s:13:"xx.xxx.xx.xxx";i:1286561693;}

a:2 - To break this down the "a:2" at the beginning stands for "attempts: 2" showing the # of IP addresses that have attempted access.

s:14 - I don't know what this is

xx.xxx.xx.xxx - this is the IP address recorded in the attemps

1286561693 - this is the UNIX timestamp of the login attempt. You can decode that using http://www.onlineconversion.com/unix_time.htm .

3) To drop this from 1 attempt to 2, for example, simply update the value on this row to be:
a:1:{s:14:"xx.xxx.xx.xxx";i:1284444427;} and S2 will let think the user only has 1 login attempt.

Cheers

Mark

[Dr Dave]

Mark and Webber,
Thanks for rooting this out!
Hopefully Jason will clear it up in upcoming versions.

[ddgdaily]

Ummm.. I'm having this issue too, and am not techie enough to do what Mark suggested (ie I don't want to mess around with the database and my users aren't techie enough to know what their IP address is).

Was there a laymans fix other than deleting and re listing the user (not an option) - I have only been using the plugin since saturday, and it seems the problem has been occuring for existing members since then.