"sudden death"

[MarionRaven]

I'm sporadically facing the login dialog when working in PW. (So I'm surely already logged in.)

If I log in a second time I can go on until I want to save. PW guesses to be cheated.

Loosing all the work done so far is really not amusing at all.

I suspect this happens (Firefox 14.0.1) if I copy and paste between tabs (and domains).

I have not investigated this issue a lot. I don't expect anybody else to do this for me. I'm just wondering, whether someone has the same experience and then maybe can give me a clue.

[DaveP]

This sounds to me like a cookie conflict. Are you logged in to two sites at once, in the same browser? Do you have another browser to open one of the domains in?

[ryan]

I agree with DaveP that it does sound like there is some sort of cookie conflict in your domain. I don't think copying and pasting between tabs should be a problem at all.

Are you working with two different copies of ProcessWire on the same domain? If so you'll want to change your sessionName in /site/config.php for one of them.

Does your IP address change during the session? If so, you want to disable sessionFingerprint in your /site/config.php

[SiNNuT]

I suspect you are running into the build-in CSRF protection, do you get this exception?:

/**
 * Throws an exception if the token is invalid
 *
 */
public function validate() {
 if(!$this->config->protectCSRF) return true;
 if($this->hasValidToken()) return true;
 $this->resetToken();
 throw new WireException($this->_('This request was aborted because it appears to be forged.'));
}

[ryan]

I'm guessing it's not the CSRF protection, but that's a good thing to mention too. If that CSRF error was the one that you are getting, you can disable CSRF protection by adding this line to your /site/config.php:

$config->protectCSRF = false; 

However, I would check the sessionName and sessionFingerprint considerations first, as a CSRF error may be a side effect of a cookie conflict too.

[MarionRaven]

Overwhelmed!

@DaveP not every time it happens.

@SiNNuT yes, i get 'This request was aborted because it appears to be forged.'. But that is the the second (and last) failure after I seem to have successfully logged in again.

@ryan I will try »$config->protectCSRF = false;« since the superfluous login only is not a big deal.

BTW: There is the possibility that I use "secondlevel.com" and "www.secondlevel.com". => 2 Domains => failure. I'll pay attention.

I noticed that Firefox stops (or at least slows down) JS in a tab which has no focus. Is there any watch dog with Ajax involved regarding logins?

[WillyC]

[quotamos]BTW: There is the possibility that I use "secondlevel.com" and "www.secondlevel.com". => 2 Domains => failure. I'll pay attention.[\quotamos]

donut do that. stay at.same host. fix yer htaccess so u donut forgot

[Pete]

Mmmmm... donuts.

[MarionRaven]

I'm now able to reproduce my "automatic" sign out. Maybe others are affected by the same problem.

I'm using firebug and firephp once in a while.

Without firebug my firefox transmits the user agent string : ... Firefox/16.0

With activated firebug the uas is: ... Firefox/16.0 FirePHP/0.71

This change in uas kicks me out of my processwire backend session.

[ryan]

Session fingerprint also keeps track of useragent. So if your useragent or IP is changing, then the session is considered no longer valid. This can help to prevent session hijacking. But it can be a nuisance if your IP and/or useragent are changing for a valid reason. In that case, you should disable session fingerprint from your /site/config.php file. Locate this line and changed it to 'false' as shown below:

/**
* sessionFingerprint: should login sessions be tied to IP and user agent? 
*
* More secure, but will conflict with dynamic IPs. 
*
*/
$config->sessionFingerprint = false;

[woop]

I've always had major issues with keeping my session logged in ever since I started using Processwire. Both on mobile with my phone and on wifi with the laptop. Setting sessionFingerprint to false fixed all issues. Maybe the fingerprinting is a bit too harsh?

[JeffS]

Not if your coming from fixed address environments. I like it this way.

When you are on mobile or a ISP that dynamically assigns and reassigns IP addresses this setting is what you need. 

[woop]

Not if your coming from fixed address environments. I like it this way.

When you are on mobile or a ISP that dynamically assigns and reassigns IP addresses this setting is what you need. 

Sure - but for these users it would be nice to still be able to use some kind of fingerprinting. Eg. solely relying on User Agent or in a combination with some other value. Would be better than nothing?

[alan]

On 10/19/2012 at 3:17 PM, ryan said:

Session fingerprint also keeps track of useragent. So if your useragent or IP is changing, then the session is considered no longer valid. This can help to prevent session hijacking. But it can be a nuisance if your IP and/or useragent are changing for a valid reason. In that case, you should disable session fingerprint...

I have a site where Chrome on Android, with all history removed, on a re-booted phone, will not login and I am seeing

User 'admin' - Error: Session fingerprint changed (IP address or useragent) (IP: xxx)

in the session log. If I open an incognito window it will login. If I login to Android as a new user (and so virgin chrome) it will login.

(the delete all history not fixing it surprised me)

I was able to fix this with:

$config->sessionFingerprint = 0;

in /site/config.php

Is it 'safe' to leave this set this way? There's no danger of two users logged in getting their sessions 'mixed up' with this set to 0 is there (i.e this isn't the only thing that keeps the identity of a client to their session 'understood' by PHP/PW is it)?

Thanks for pointers and sorry if I missed answers to these points from other threads. Cheers, -Alan

[horst]

Alan, it will not mix up sessions, but it is less secure in regard of session steeling possibilities.

If this is a special device with a known Useragent, I would suggest dynamicly disable sessionFingerprint only for that UA.

something like that in the site/config.php:

if(isset($_SERVER['HTTP_USER_AGENT']) && 'StringOfTheProblematicUserAgentHere' == $_SERVER['HTTP_USER_AGENT']) {
	$config->sessionFingerprint = 0;
}

 

[alan]

Thanks Horst.

I know it's happening for one iOS device and as noted on one Android.

If I test and all can login AOK with sessionFingerprint=2 or 4 or 8 then presumably that is better (than 0) since at least some extra security is added, do you think?

PS: Wow, never realized config.php could have dynamic statements, I suppose it's .PHP so why not; tks for the tip!

[deltavik]

By any chance, did you add cloudflare or something like that?

I ran into this issue recently.  The session logs said  "Error: Session fingerprint changed (IP address or useragent) (IP: 108.162.219.219)." That IP address is Cloudflare IP. 

Then, after searching on this forum, I added sessionFingerPrint = false in config.php. The problem then went away. Good. 

However, the next day I removed that line to test the login/logout issue. Interestingly, I didn't notice any issue.

So -- I don't really understand why the problem didn't reappear after I removed that sessionFingerPrint line. 

 

[alan]

I didn't @deltavik but I too am puzzled why the problem came up. My hosting is a fixed IP, so am I.

I wonder if there is somewhere a way to 'clear' existing fingerprint 'expectations' so I would then be able to return the setting to default and all would work. It seemed really odd that my Android would:

# fail to login
# fail even though I cleared all history (etc, all items all time)
# quit, Chrome, rebooted phone
# BUT would work if I used the same device, same app (Chrome) in incognito mode

Clearly my device in non-incognito mode is fingerprinted on my PW install and when it's seen won't work - I wonder how I clear that..?

[horst]

If you have a static IP, you may log UAs for this IP a short time. I assume, you then will find what causes the issue:

<?php
// somewhere in site/ready.php, for example
$myPrivateSaticIP = '123.123.123.123';
if(!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $ipAddress = $_SERVER['HTTP_X_FORWARDED_FOR'];
} else {
    $ipAddress = $_SERVER['REMOTE_ADDR'];
}
if($ipAddress == $myPrivateSaticIP) {
    // log infos of IPs,  user agent and more, ...
    $items = array();
    $items[] = 'REMOTE_ADDR: ' . (isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : 'N/A');
    $items[] = 'HTTP_X_FORWARDED_FOR: ' . (isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : 'N/A');
    $items[] = 'HTTP_USER_AGENT: ' . (isset($_SERVER['HTTP_USER_AGENT']) ? $_SERVER['HTTP_USER_AGENT'] : 'N/A');
    // add more if needed ...
    $log->save('my_ip_useragents', implode(' || ', $items));
}

https://processwire.com/api/ref/log/save/

[deltavik]

50 minutes ago, alan said:

I didn't @deltavik but I too am puzzled why the problem came up. My hosting is a fixed IP, so am I.

I wonder if there is somewhere a way to 'clear' existing fingerprint 'expectations' so I would then be able to return the setting to default and all would work. It seemed really odd that my Android would:

# fail to login
# fail even though I cleared all history (etc, all items all time)
# quit, Chrome, rebooted phone
# BUT would work if I used the same device, same app (Chrome) in incognito mode

Clearly my device in non-incognito mode is fingerprinted on my PW install and when it's seen won't work - I wonder how I clear that..?

 

since you are this far in troubleshooting, I assume you had also cleared the site/assets/sessions folder?

[alan]

Thanks @horst and @deltavik for your help and suggestions. I will check both routes (I'd not cleared sessions folder as I use the db to store sessions and I'd assumed there would be none, but will check). Cheers!

[lenno]

On 8/26/2016 at 10:44 PM, deltavik said:

By any chance, did you add cloudflare or something like that?

I ran into this issue recently.  The session logs said  "Error: Session fingerprint changed (IP address or useragent) (IP: 108.162.219.219)." That IP address is Cloudflare IP. 

Then, after searching on this forum, I added sessionFingerPrint = false in config.php. The problem then went away. Good. 

However, the next day I removed that line to test the login/logout issue. Interestingly, I didn't notice any issue.

So -- I don't really understand why the problem didn't reappear after I removed that sessionFingerPrint line. 

 

Hi,

I just wanted to point out that we recently ran into the same issue when using Cloudflare's CDN. Weird is the fact that we were able to reproduce the logout issue with a specific user when editing a specific page. Every time the user clicked "Save" for this specific page, she was kicked out. I assume that at this point the IP address changed - from Cloudflare to the actual user's IP address or the other way around. The error is the same as in the quoted post above:

User 'somebody' - Error: Session fingerprint changed (IP address or useragent) (IP: 162.158.XX.XX)

The IP address is - just as above - in the Cloudflare range: https://www.cloudflare.com/ips/

We are currently working around this issue by using a different Domain name to access the ProcessWire backend. This domain is not routed through Cloudflare and the approach works fine for us so far.

I can provide further information if required.

[formulate]

Ah ha! That makes sense from my end. At the time I was having problems, it was on a server that was using Cloudflare. I had disabled Cloudflare for other reasons (namely their CSS caching drives me bonkers) and that resolved my issues, but I had never made the connection between the two. Thanks for coming back and chiming in with your findings.

[gmclelland]

If you are using cloudflare.com you might also want to create a page rule like:

*mydomain.com/processwire/*

• Security Level = High
• Cache Level = Bypass
• Disable Apps
• Disable Performance

This should prevent any of the Processwire admin from being proxied by cloudflare.

[BenSlayers]

On 3/14/2017 at 3:10 PM, gmclelland said:

If you are using cloudflare.com you might also want to create a page rule like:

*mydomain.com/processwire/*

• Security Level = High
• Cache Level = Bypass
• Disable Apps
• Disable Performance

This should prevent any of the Processwire admin from being proxied by cloudflare.

1

Thanks for that! I have been stuck on this all morning. It never even occurred to me that it could be CloudFlare causing the issue...ugh. You, sir, are a scholar and a gentleman.