Weird Login status inconsistency, temporarily solved by clearing the site cache - My Forums

Weird Login status inconsistency, temporarily solved by clearing the site cache

davidsmith — Jul 21, 2015, 06:19 AM

Hello everybody

I've built myself a very simple site, and I'm using Login to provide frontend access to password protected pages. One shared account for everyone. The form has the username hardcoded so they only need a password. So far so good.

I've made a resource group, a user account, put the pages in the group, assigned the user to the group. Tested, working.

Then, some time later (<24 hours it seems) it falls apart and logging in doesn't really quite work. Moving from page to page seems to change the users status, flipping back and forth as if something is being cached. The system denies access to the protected pages even immediately after a successful login, but then shows "Login" rather than "Logout" if the page changes again, as if the login didn't really work.

I imagine the solution is simple, I just don't understand the requirements. I want to use caching where possible, so everything is totally default so far, except the snippet call is uncached, of course.

My initial build had...

[[!Login? &loginTpl=`loginTpl` &logoutTpl=`lgnLogoutTpl` &errTpl=`lgnErrTpl` &redirectToPrior=`1` &logoutResourceId=`1`]]

...in a footer chunk on every page, facilitated as a popup so you could log in on any page. The login button just reveals the popup. But after running into issues getting it to return the user to the same page on which they logged in I decided to simplify and have the login button send them to a special login page.

I haven't yet removed the [[!Login]] call from the footer of all the other pages yet, which could be part of the problem. While waiting for help I think I'll make the whole Login snippet call conditional so it only runs the snippet on the dedicated login page. But eventually I'll want to fix this issue and get back to having a popup login form on all pages.

I also have a "Login/Register" / "Logout" chunk in the top right corner of the page. Rather than a second call to Login (would that actually work? I haven't read documentation about calling the snippet twice with different template chunks) I've been using...

[[!+modx.user.id:is=`0`:then=`...[show login links]...`:else=`...[show logout link]...`]]

...taken from an existing forum thread, and which shouldn't interfere with anything. Worst case I imagine, given the fact that the "logged in" test is happening above the call to the snippet, is that the user wouldn't be shown as logged in till the next page refresh. But that's not happening. Everything works just perfectly for a good while, until it doesn't anymore.

I've tested in multiple browsers, logging in and out and the same, and different times. I've tested it on Skype while someone else logs in too. All good.

Eventually it breaks down and I have to log into the manager to clear the site cache in order to get it all working again. it has the capacity to work, but something is eventually being cached and it gets confused, even though all my tags are called uncached.

As this has been working while I'm testing with a remote friend, for several login/logout revolutions, I really can't understand why, and at what point the cache starts getting in the way. I hope this issue is familiar to someone with more experience, and I look forward to any help I can get!

Re: Weird Login status inconsistency, temporarily solved by clearing the site cache

davidsmith — Aug 27, 2015, 07:18 AM

Ah, I suppose if one person logs in using www and another tries non-www, that could cause the same confusion you mentioned, Bob. Perhaps that's what you had in mind when you said it initially. I'll get that sorted asap in any case.

Re: Weird Login status inconsistency, temporarily solved by clearing the site cache

davidsmith — Aug 27, 2015, 07:14 AM

Unfortunately, after quite some time, the issue has recurred. Clearing the cache sorted it out (not even flushing permissions or logging out all users).

My client suggested that as he observed it fall apart when several people were sat around a table trying to use it, it could be something related to many people essentially logging into the same account. This seems the most likely to me, actually, in spite of the advice I've read on various sites, including this forum, suggesting that it's quite alright to create a single user account in order to facilitate the sharing of a password.

I've just realised I still hadn't tweaked htaccess to force www/non-www (need the client to choose) so I'll be sorting that issue out finally too.

In the meantime I'd appreciate any further advice anyone has, as to what else might cause the sessions (?) to get confused, either over time or when several people are sharing the same account. Perhaps in the case of the latter I need to do something else to avoid session confusion. To date I've never witnessed the manager actually listing a user's recent activity on the dashboard.

Re: Weird Login status inconsistency, temporarily solved by clearing the site cache

davidsmith — Jul 23, 2015, 06:52 PM

I'm fairly sure my testing has been on a consistent domain. Worth a proper look I suppose, but the problem seems to have sorted itself out now, and all I've done is change the server time zone. I can't imagine quite why that should make any difference.

But as it happens I have forgotten to configure the rewrite rule in .htaccess so I'll be sure to do that in any case.

Thanks for the help Bob.

Re: Weird Login status inconsistency, temporarily solved by clearing the site cache

BobRay — Jul 23, 2015, 06:30 PM

One possible cause is the user moving from a www. page to a non-www. page or vice versa. This loses the session and the user becomes not logged in until they move back to the domain they came in on.

Be sure to uncomment one (but not both) of the sections in .htaccess that forces either www. or non-www. URLs.

Re: Weird Login status inconsistency, temporarily solved by clearing the site cache

davidsmith — Jul 21, 2015, 10:16 AM

If I continue clearing the cache, all seems well. Obviously I don't want to have to do that, especially for what must be close to the simplest Login implementation, so I've been looking into possible issues.

I noticed that the manager was reporting the server time incorrectly, so I've updated the system region setting to "Europe/London" which has corrected the time in the manager. Is it possible a time inconsistency could be responsible for confusion with user sessions, or something like that?