Another login issue

[Jeff B]

I've witnessed this myself, as well as many members.  When logging in, they are transported to a webaddress that is missing one letter than ours.  As an example, if our address was mywebsite.com,  on login they are transported to ywebsite.com  If they use the back button they come back to the login page showing they are not logged in, but if they hit the home button, they actually are. It only seems to happen for established members.  I've tried to recreate the problem and actually did using edge this morning.  It seems to be related to using pre-propagated from fields. If I clear the fields, and type the username and password in, you login as normal. Once you have done that, it seems like the problem goes away.

People are freaking out when they are transported to a different website that actually exists that shouldn't. This seems to be a bit nefarious but I am hoping it is not. The problem began when we moved to a new server and went from 2.0.13 up to 1.0.15  and yes. I have applied the login patch.

[-Rock Lee-]

Maybe it's a problem of routes when you migrate to used repair_settings.php?.


Regards!

[Aleksi "Lex" Kilpinen]

I've never seen that happen - don't use edge either though. But, could you give a link to your website?
I guess you have already made sure all your paths and urls, themes included, are correct and it's nothing like that causing this?

[Jeff B]

forestryforum.com    It happened with firefox as well as safari too.  Not browser specific.   I enabled the repair settings and have been over and over them.   try going to orestryforum.com  it exists. It shouldnt.

[Jeff B]

Aleksi, let me know if you need a test admin login.

[Aleksi "Lex" Kilpinen]

You're using a portal, EzPortal I guess? Does it have it's own setting for where to take users when they login?

Aleksi, let me know if you need a test admin login.

If you want, I can take a look.

[Jeff B]

PM sent.

We were having all kinds of trouble with session errors and such. I went away from using the www and changed everything I could find anywhere to reflect no www.   Our mrmbers problems have mostly cleared up by deleting all cache cookies and bookmarks, but this issue keeps cropping up,

[Aleksi "Lex" Kilpinen]

OK - I tested with the account you sent me. IE11, FF56 and Chrome 64 - none of them did what you described.
Also all your theme settings seem to be OK, so that wasn't it.

BUT - there is something wrong clearly, your EzPortal is missing language strings for example, and your error logs seems to have more than a few errors related to mods. Nothing too serious though - everything seems to be working.

[Jeff B]

Yes, I've not been able to clear those all up.  Especially the personal message mod installed a long time ago. Scared to try and uninstall it due to all the errors it shows trying to uninstall.  Odd about the ezportal as that was a fresh install after upgrading everything.

Like I said, the only way I can get that login error to occur, is if you are using a machine that was used to login before the upgrades and if you let the login fields propagate themselves. Say I type in a B, and it offers Bozo, and I take that, then the password field propagates from a save login. That's when it happens.  Once you remove the existing info from the fields by actually typing the info in, it works as expected and the problem is gone.   I had kind of wrote it off until I got notice of it happening again to two older members. So, I tried Edge, which is what they use. I don't.  I had logged in with edge at one time, so my login info self propagated in the fields. Off I was wisked to orestryforum.com   I came back and typed my info in in place of the self propagated info, and I logged in as expected and now can not recreate it in edge again.

Is there any way in the world that old saved login info gets screwed up somehow with the new way the new secured login works?

[Aleksi "Lex" Kilpinen]

Is there any way in the world that old saved login info gets screwed up somehow with the new way the new secured login works?

Quite honestly, at this point I have no idea what might cause it do that, when it works normally otherwise.
Your source code looks clean, no obvious boogiemen there, the login / out functionality seems to be working fine...

[drewactual]

can we get a look at your php(info)? 

if using files as the sessions handler, it may be time to clean the directory storing them up.  also, if using files as a handler, it's a good practice to have them clear(invalidate them) every 4300 seconds as a maximum.  1440 i think is the default- but some server managers (if using shared server) try to cut back on server load by increasing them. 86400 is about as long as is good practice to use- which is a day (i think that's 86400, something close to it anyway)... some folks use 24 minutes (1440 and the php default i think, and others twice that... those sessions are good for that period of time, so active users checking in within the time of the session's life are going to pick up where they left off...

another way out, though i don't rec it as it can cause other issues, is to change the cookie name which invalidates ALL the current cookies and forces users to log in again collecting the new cookie- presumably those would be 'fresh' with little interlacing with 'old' information.

also, if using OPCache, you're gonna need to invalidate the files to see the changes. (but i don't think this could be what you're seeing)

[Jeff B]

One of the things that I did early on after the changes and ensuing problems for people logging in was to rename the cookie.  It didn't have any effect on the session issues and such. I did have mixed cases of www and non www and standardized that. What is the best way to give you a look at php(info)  copy and paste?  Actually I think the default on this new server (debian) is that it is disabled. I'll have to see where to enable it in the php.ini file.

[Aleksi "Lex" Kilpinen]

Take a look at this, and try What is a phpinfo() file?

[Jeff B]

I enabled it and copied it to a .rtf file. Let me know the most appropriate place and person to give it to.

[Jeff B]

I don't know if it is relative at all, but the old server had memcache installed.  I've not installed any cacheing program on this server as it is always screaming fast. I've not even configured sphinx search on this new server. (although I would if I knew how)

[Aleksi "Lex" Kilpinen]

can we get a look at your php(info)? 

Seems to be
session.cache_expire   180
session.gc_divisor   1000
session.gc_maxlifetime   1440
session.gc_probability   1
So this shouldn't be a problem.

One of the things that I did early on after the changes and ensuing problems for people logging in was to rename the cookie.

Also, if cookies or sessions were in play - I'd think this would have nixed these problems.

[Jeff B]

What do the sessions in the sessions table do?  All that was moved to the new server. Is it related?

[drewactual]

Yeah, if he already changed cookie names,... What you said.

And the phpinfo looks good.

Gotta be a proxy cache on some in between server.

Add to htaccess code to stop cache by setting time to zero.  Clear smf file cache. Clear any sessions.  Wait a few days, and then set it back the way it was.

[Jeff B]

I got to thinking, I have a laptop here that I have not used since the changes were made. I suspect it will do what my other machines have done.  Any suggestions on capturing what is going on, in case it actually happens?

[Aleksi "Lex" Kilpinen]

You could perhaps use Firefox to try and see what is happening.

- Open DevTools (F12)
- Go into Toolbox options
- Enable persistent logs, in Common preferences
- See network requests and responses under the Network tab