#1
I'm having an issue with the simple members module where I try to login and it simply redirects me back to the login page without any error message. I know the password is correct so not sure what the issue is. Has anybody come across this before and found a solution?
#2
Hi mjim,

Assuming you have installed the updated 'simple members' module that now has sub-modules and you have followed DC's video instructions on the install https://youtu.be/v6Mc3e5SXOM

I would start by looking at the method 'submit_login' in the controller 'Account.php' of sub-module 'account':


I'd check $result == true to ensure the validation is working as expected and not redirecting to the login form. Then I'd insert a
after line 104 to ensure the returned member object is valid. If it isn't, keep following the logic until you find the problem.

Cheers,
Si
#3
Thanks Si

I traced it back to the csrf_block_request method in validation_helpers.php.

It redirects to my home page which redirects back to login.

I can see that $_POST['csrf_token'] is being sent.

So I believe it has something to do with the line 593:
$result = password_verify(session_id(), $_POST['csrf_token']);
#4
I can't replicate your problem, can you please state the version of Trongate you are using? I recall a few versions back, DC introduced a bug with the csrf check but has since fixed it.

When I add an echo on $result I get 1 which is true and never get redirected to BASE_URL


Suggest you try creating a new app with the Desktop app, then install the simple members module. So you have a fresh copy of Trongate and the members module.
#5
Thanks Si

Although I've always had the same issue with Simple Members, this is a new app that I built a week ago with the latest Version: 1.3.3044.

If I reset the password, I can login without any problems.

If I'm logged out due to a session expiring or on a second device, I get the same issue where I can't login without resetting the password. My clients are having the same issue.

I'll keep digging and thank you for your help!
#6
Thanks for sharing more information on what your issues are. However, I still can't replicate your login issue on localhost. I even played about with the cookie and session to shorten the expiry time, so it forced me out but still all worked fine for me once I resubmitted my credentials... no need for password resetting.

Are the login issues you are experiencing for a live site? If so, are you caching? I'm thinking if the csrf token is being cached they won't match and that would definitely send you back to the login form apart from this theory, I'm at a loss as I can't replicate your issue.
#7
I believe it is a caching issue with my production server.

I'll run some tests this week and let you know what I find.

Thank you!
#8
I found it odd that the session_id() was the same on localhost but different on every page load on my production server.

After I ran a few tests it seems it was Varnish that was the cause. I disabled it and my session_id() doesn't change now and I can login without any problems.

It is recommended to keep this running on a live server but I'm not aware of how I can do this and still have my session_id working properly so I have to leave it off.

It is resolved for now so thank you Si for steering me in the right direction.