Non-paid member accounts locking after 1 day

[JohnBob]

I seem to have a problem where members can't log in the day after they've created a free account. Paid accounts seem to be okay. It also seems to affect Editors, but not Administrators.

This is a new installation of s2Member (free). The dev site seemed to be fine, so I'm wondering if the host server set up could be causing this, or is there just a setting somewhere that I've missed??

Any help would be great. Urgent.

Cheers
John

[Cristián Lávaque]

That is odd. You probably did have a setting different in the second blog, then.

Is the free member in your users list? Did you check his profile to see if everything was in order? Did he get the WordPress email with the account details after creating it?

[JohnBob]

I had some issues originally with registration emails not being sent, but changing to SMTP seemed to solve that.

The users are appearing fine the User list (and are listed as the correct user level).
They can login fine day 1, but when they come back the next day it isn't letting them log in.
It doesn't seem to affect paid subscribers, only free (level0) ones, and an Editor (but if I change their password in the admin area they can access again).

The only setting that I think if different is that I have EOT turned on for the live site, but I can't see why this would block a free user at all? My understanding is that free (level0) users don't expire in anyway.

It seems to me that the passwords are just not being accepted on day 2.

Weird and very inconvenient, so any suggestions much appreciated. Thanks.

[JohnBob]

Out of interest is there a setting that would make free subscribers expire after 1 day? (I couldn't find one).

[Cristián Lávaque]

OK...

Well, using s2Member Pro's Free Registration Pro-Form, you can set an EOT and if you set your auto-EOT behavior to delete the account, then you could make the account be removed after 1 day. If the auto-EOT is set to demote, though, the account would be demoted to Level 0, so this shouldn't be a problem.

No setting I know would change the person's password. Maybe you're using another plugin that could be causing this behavior?

[JohnBob]

It's set to demote, so that shouldn't be a problem.

It all worked fine on the dev server with the same set of plug-ins so I can't see what can be causing this. I have to assume it's a s2member issue in some way, as no other plugin can be affecting users in any way that I can see.

Open to all suggestions please!!

[Jason Caldwell]

Thanks for reporting this important issue.
~ and thanks for the heads up Cristián.

What is the exact error message that a Free Subscriber receives on the second day?
When this happens, does the account still exist, or is the password just different?
Can we see a list of the other plugins that you're running in concert with s2Member please?

Just to note. s2Member has no setting that automates password changes. I have to assume ( if it's s2Member causing this ), that it's the Automatic EOT System. But you're correct, this should not deny them access, it would only demote them; that's the default behavior anyway.

Are you running s2Member Pro? If so, are you doing any imports that may affect existing Passwords?

Also, how are your Free Subscribers gaining access initially? Is it through the Standard Login/Registration Form at /wp-login.php?action=register, or through an s2Member Pro Form? If it's through an s2Member Pro Form, can you please post a copy of the Shortcode that you're using?

[JohnBob]

Hi Jason,

The error is:

ERROR: The password you entered for the username xxx is incorrect. Lost your password?

The password is 100% definitely correct in terms of the letters and numbers entered (not sure if anything could be corrupting that at any point?).

Problem account/s still exist in the Users list.

The fact that an Editor is also having a problem is weird (this is how we first became aware of the problem).

I'm using WordPress 3.1.3.

List of plugins:
AddToAny: Share/Bookmark/Email Buttons Version .9.9.8.2 - DEACTIVATED
AdRotate Version 3.5.1
Akismet Version 2.5.3 - DEACTIVATED
Contact Form 7 Version 2.4.5
Custom Post Type U Version 0.7
Frontpage-Slideshow Version 0.9.9.3.4
Google Analyticator Version 6.1.3
Google XML Sitemaps Version 3.2.4
Hello Dolly Version 1.6 - DEACTIVATED
HITS- IE6 PNGFix Version 3.4
No 404 Errors Version 0.1.1
Really Simple CAPTCHA Version 1.2 (only used on Contact 7 forms)
Regenerate Thumbnails Version 2.2.0
s2Member Version 3.5.8
SexyBookmarks (by Shareaholic) Version 4.0.1
SI CAPTCHA Anti-Spam Version 2.7.1 (not used on the login form - and I've tried deactivating this)
Smart 404 Version 0.5 - DEACTIVATED
Smooth Slider Version 2.3.4.1 - DEACTIVATED
Verve Meta Boxes Version 1.2.6
WordPress Database Backup Version 2.2.3
WP-Cufón Version 1.6.8
WP-Mail-SMTP Version 0.9.0
WP-Paginate Version 1.2.3
WP Widget Cache Version 0.25.4 - DEACTIVATED

I'm currently running the free version of s2Member.

Free subscribers sign up via /wp-login.php?action=register.

Any suggestions/help you can give would be great. Thanks.

[Jason Caldwell]

Thanks for the follow-up.

Nothing jumping right out at me so far. Everything you have looks good, and that list of plugins looks fine too; I don't see anything in that list that would create a conflict. The "Verve Meta Boxes" plugin appears to do some interesting string manipulation, but after a quick review, I don't see anything that ties it to the Login Form.

Can you provide me with a Dashboard login and FTP access? If so, please use this private contact form to submit those details. I'll take a closer look and offer a solution. http://www.s2member.com/contact/

Just a wild guess at this point, but I'd be suspicious that one of your plugins is somehow intercepting $_POST data, as it comes through the Login Form. In other words, one of your plugins might be attempting to sanitize incoming form data and inadvertently removing a special character or something like that.

Another way to test this out, is by using a PHP function to test various Username/Password combinations for yourself. Something like this:

Code: Select all

<?php
if(user_pass_ok("A Good Username", "A Valid Password"))
    echo 'Yep, looks good!';
?>

[JohnBob]

When logging in the user is being recognised okay, as it says invalid user if not.

It definitely seems to be a password issue, and it seems to be a 24 hour thing, not overnight as such.

I tested this as I had a test user in there I set up early PM and that worked fine the next morning, but then was locked out post their original sign-up time.

If (when logged in as Admin) I change a user password then that user (who previously couldn't get in) can then login again.

(I'm not sure if that's true if a user tries to update their own password - I've set up some users to try that with tomorrow).

However, it looks like 24hrs later that password has been affected again.

So I don't think that it can be post data being incepted, but does seem to be something affecting the passwords 24hrs after they are set up.

The only accounts that aren't being affected are the main admin and paid s2member accounts.

Where is the EOT information stored against users? I ask, as I've added an EOT date/time for the Editor who has been affected to see if that makes any difference to their login situation. I thought the EOT data was being pulled from PayPal but as it let me enter something in there, and it's been saved, I'm assuming it must be being saved somewhere locally?

I'm not getting this issue on the dev site, and I've double checked if the settings are the same, and they now seem to be.

It could indeed be a plugin thing (there are a couple of differences), or something to do with the host, or possibly hacking (but I've not read anything about this being an issue, i.e. this type of hack)?

My thought is that the passwords set are being automatically altered after 24hrs, but I can't see what could be doing that as selectively as this (i.e. free members and editors and not paid members or admins).

(I'll need to check with the site owner re: allowing you access directly - as it's their PayPal account etc - Thanks for the offer, and I'll let you know as soon as they make a decision... not always quick!)

I'm tearing my hair out

[Jason Caldwell]

Thanks for the follow-up.
Yea, I'm as confused about this as you are. I'm not aware of anything in WordPress, or in s2Member that would automatically change account passwords. Please let me know if you figure this one out. Thanks!

[JohnBob]

Okay, it's early days (as in it's only been 36 hours so I might be speaking too soon) but I think I might have 'fixed' it, if not totally solved it.

It looks like it was either a s2member clash with the No 404 Errors plug-in, or more likely someone hacking the site via phpMyAdmin (even though this in theory was protected).

I basically disabled that plugin (as I worked out it was the last one I enabled before the issue was discovered), and also thought to delete the phpMyAdmin folder as my gut feeling is that it was/is hacking.

I did this late Saturday evening and I found I could login in to all test accounts okay on Sunday and again this morning (Mon).

I'm going to give it a couple of days and see what happens. Fingers crossed.

It might be worth you checking that plug-in compatibility, but by guess is that it was a PHPMyAdmin hack

Thanks for all your help on this, and sorry to inconvenience you if (/when) it does turn out to be not s2member related (i.e. it just happened to coincide with me adding your plug-in).

[Cristián Lávaque]

Thanks for letting us know, John. I hope you finally solved it and that the problem wasn't because someone had hacked your database.

[Jason Caldwell]

Thanks for reporting back John.
Much appreciated. Please report back again if you can, when/if your theory is proven.