I Get Logged Out When I Edit a Page

[CaelanStewart]

Hi,

I'm having an issue when trying to edit a page through the ProcessWire CMS. When I click on the Edit button, the page loads fine. But, if I then navigate to another page (say, the modules tab) I am logged out. This only happens on a few pages, such as /stories/ and its children. Every other page on the site is absolutely fine and I can edit without being logged out. The weirder thing is when I view this page on the front-end, I am also logged out.

It just seems that the simple act of getting a page from the DB causes me to log out, and I can't see the connection.

This is causing us some problems since this website is for Hilton, and with 88 people currently registered on the site (and many more to come), we're getting a lot of phone calls. I'm not sure how this can be anything we have done, since we have not modified the Admin Panel or the Core code whatsoever, and that simply going to edit one of the affected pages in the admin panel logs us out. And I repeat, every other page is fine.

The website is here:

https://extraordinaryfb.com/

Unfortunately, it's a private site, and requires registration with a Hilton associated email address, so I am not a liberty to create an account for somebody to view the site themselves.

If anybody can tell us what might be happening, that'd be great. Many thanks in advance.

And on a side note, I could not register with my normal company email address since your forum tells me it's an invalid email address. It's a @progress.digital email address, and it is perfectly valid. Only allowing .com/.co.uk and other common TLDs does not conform with email standards.

Though I must say, your ProcessWire system is very impressive and we have found it great to work with. Extremely extendable.

[Nico Knoll]

Could you take a look in your /site/assets/logs/errors.txt and post it here?

What fields are you using "stories" site? Is it a special template or the same as every other page? Have you tried delete the /stories/ site and recreate it? Or delete the template and recreate it?

Which additional modules are you using (especially: do you use any third party fieldtypes?)

[CaelanStewart]

Hi,

Thanks for your reply.

There is nothing in the errors.txt file from today apart from a login throttle error, because one of my colleagues had forgotten the password to his account and tried too many times.

There are no special fields, just title (text), CKEditor and Image upload fields.

There are no third party field types on the affected page. And this problem is only affecting some users. A colleagues account has the same permissions, in the same order, and the same email extension as me and he can view the page fine. I created another account, different from the one that created the page, and it still logs the user out.

[ryan]

I think this forum software may have been made before the newer longer email addresses, but I'm sure they'll account for that in a future update. A lot of email address validators currently validate the last portion as being between 2 and 4 characters, and I'm guessing that's the case with IP.Board. That reminds me, I need to go double check that PW's $sanitizer->email() isn't one of them.  

The first thing I'd suggest doing is enabling debug mode by editing /site/config.php and setting the $config->debug=true; That should enable any obvious errors to appear on the screen. Getting logged out from a particular page suggests that some kind of output is occurring before the http headers, causing the session cookies to be lost. Remember to turn debug mode back off once you've tested things out to see if there are any errors being suppressed. 

Your admin theme appears to be heavily modified (found the admin login page), so that's one thing to look at. Restore the non-modified admin theme, by replacing the /wire/modules/AdminTheme/AdminThemeDefault/ with the original. Move your modified version to /site/modules/AdminThemeCaelan/ (or something like that) so that you can install core upgrades without losing your modified admin theme. The same goes for any core module–if you need to modify it, copy it to /site/modules/ModuleName/ and work with that instead. Otherwise you'll lose all your changes every time you upgrade PW. 

Speaking of upgrades, you might also want to upgrade to the latest PW dev version 2.5.20, as it contains a lot of fixes and enhancements that your site may benefit from. Though the issue you mention with logouts is not one I've heard of before. But it's worth a try. 

If none of this helps feel free to PM me a login so that I can take a look at the page in question and I can examine the http headers to see what is causing the session to break. 

[ryan]

Just reading your additional responses. Interesting that it doesn't affect all users. Try setting $config->sessionFingerprint to false, as perhaps the logout is the result of a dynamic IP address change or something in the user agent string changing. Though if the logout only occurs on one page, that still points to something up with that particular page. I'm actually wondering about something on the server outside of PW, like mod_security or similar messing with the session due to a combination of factors present on that page. 

[CaelanStewart]

I think this forum software may have been made before the newer longer email addresses, but I'm sure they'll account for that in a future update. A lot of email address validators currently validate the last portion as being between 2 and 4 characters, and I'm guessing that's the case with IP.Board. That reminds me, I need to go double check that PW's $sanitizer->email() isn't one of them.

The first thing I'd suggest doing is enabling debug mode by editing /site/config.php and setting the $config->debug=true; That should enable any obvious errors to appear on the screen. Getting logged out from a particular page suggests that some kind of output is occurring before the http headers, causing the session cookies to be lost. Remember to turn debug mode back off once you've tested things out to see if there are any errors being suppressed. 

Your admin theme appears to be heavily modified (found the admin login page), so that's one thing to look at. Restore the non-modified admin theme, by replacing the /wire/modules/AdminTheme/AdminThemeDefault/ with the original. Move your modified version to /site/modules/AdminThemeCaelan/ (or something like that) so that you can install core upgrades without losing your modified admin theme. The same goes for any core module–if you need to modify it, copy it to /site/modules/ModuleName/ and work with that instead. Otherwise you'll lose all your changes every time you upgrade PW. 

Speaking of upgrades, you might also want to upgrade to the latest PW dev version 2.5.20, as it contains a lot of fixes and enhancements that your site may benefit from. Though the issue you mention with logouts is not one I've heard of before. But it's worth a try. 

If none of this helps feel free to PM me a login so that I can take a look at the page in question and I can examine the http headers to see what is causing the session to break. 

Hmm, I will give those a try.

The admin theme isn't really modified, it's just an extra CSS file that overrides the colours on the default theme. We were in a rush to get it out at that point, however.

Just reading your additional responses. Interesting that it doesn't affect all users. Try setting $config->sessionFingerprint to false, as perhaps the logout is the result of a dynamic IP address change or something in the user agent string changing. Though if the logout only occurs on one page, that still points to something up with that particular page. I'm actually wondering about something on the server outside of PW, like mod_security or similar messing with the session due to a combination of factors present on that page. 

It doesn't affect all users, no. Only some, but the ones affected have been tested on the computer, same network and same browser (tried in Chrome, FF and Safari), and they continue to be affected. But with a non-affected account, on the same machine, there's no problem. The affected and non-affects users have the same uaergroups, in the same order, same email extensions.

Weird.

[CaelanStewart]

Hi,

I just tested it in debug mode, no difference.

Another weird thing I just noticed is when I open up the accordion for /stories/ to reveal child pages (but staying on the same page, the page tree) and then reloading the page, I find I'm logged out. But if I don't open up the /stories/ accordion, and reload, I'm not logged out.

[Nico Knoll]

Could you try to duplicate (there is a core module called "ProcessPageClone" or something similar so it's just one click) the /stories/ page and see if the duplicated version shows the same behaviour? 

[ryan]

If I view the source, your admin theme has all the following (at least on the login page) that isn't present in PW's admin theme. There may be more but this is just what I observed on a brief glance: 

<link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png"><link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png">
<link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
<link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192">
<link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
<link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
<link rel="manifest" href="/manifest.json">
<meta name="msapplication-TileColor" content="#ffffff">
<meta name="msapplication-TileImage" content="/mstile-144x144.png">
<meta name="theme-color" content="#ffffff">
<link rel="stylesheet" href="/wire/modules/AdminTheme/AdminThemeDefault/styles/override.css"/>

While none of these are likely to be the source of the problem, it does indicate that core files have been changed. So in debugging this, the first thing you should do is restore the core to a fresh version with no modifications (you can always go back). If you need to present a custom admin theme to the client, put it back in after the problem is resolved, and put it in /site/modules/ so that you aren't delivering something to the client that can never be upgraded. Even something as simple as changing the character set on a core file could cause problems. The issue you are seeing most likely is something interfering with the http headers, which could be as simple as a core file that changed character sets and now has some invisible character preceding an opening PHP tag at the top of a file. That may not be it either, but since you are seeing an issue here that has not turned up in PW before, definitely get a fresh copy of the core before debugging further. 

[CaelanStewart]

Hi All, this problem appears to have resolved itself. I'm still not entirely sure what was happening, but whatever it was, it's now functioning as normal.