New site install, Admin keeps refreshing

[Jay D]

Hi all, 

I am bringing up a new PW project, this is a fresh install, as well as on a new virtual machine. I was able to get all checkmarks when stepping through install process. But when logging into the admin page, it keeps refreshing and adds the following query string to the admin url: `?r=1684082315`. 

Any ideas on what is causing this?

Debian box, Php 7.4, mod_rewrite enabled. HTTPS is not enforced. 

[Jay D]

Looks like there is Login JS that is causing the issue here: 

/wire/modules/Process/ProcessLogin/ProcessLogin.js?v=109-1673029732

And this is the code firing the redirect:

	var startTime = parseInt($('#login_start').val()); // GMT/UTC
	var maxSeconds = 300; // max age for login form before refreshing it (300=5min)
	
	// force refresh of login form if 5 minutes go by without activity
	var watchTime = function() {
		var ts = Math.floor(new Date().getTime() / 1000);
		var elapsedSeconds = ts - startTime;
		if(elapsedSeconds > maxSeconds) {
			window.location.href = './?r=' + ts;
		}
	};
	
	// reload immediately if we received browser cached login form watchTime(); 
	watchTime();

In comparing the timestamps, the one coming from #login_start is short. Adding the "*1000" to this line fixed the redirect:

var startTime = parseInt($('#login_start').val())*1000; // GMT/UTC

 

[wbmnfktr]

6 hours ago, Jay D said:

Debian box, Php 7.4, mod_rewrite enabled. HTTPS is not enforced. 

Do you have more details on that setup?
I have an old machine running that kind of dev setup but never noticed that issue at all.

Which ProcessWire version are you running?

[netcarver]

Quick thought - could you check your server has a time sync service enabled (ntpd, chronyd or systemd) and that the time is accurate on the server. Perhaps you could update the ProcessLogin.js code to console.log(startTime) as well, and post the results here? Maybe compare it with console.log(new Date().getTime()) from your browser console. Then we can get a feel for how far out of step the server and browser times might be?

[gebeer]

Have you been able to solve this?

I had the very same issue some time ago. In my case it was related to the machine I was working on. It only happened on my notebook. On the desktop everything was fine. I never went to investigate this deeper because at that time I happened to do an OS reinstall (Linux) on my notebook. I suspect though that it might had something to do with the local time on my notebook OS not being correct or something along those lines.

What I used as a temp workaround is to force login with my superuser account in _main.php or home.php (can't remember exactly) so I was able to work on the site locally.

$session->forceLogin('superusername');

 

[Jay D]

@gebeer Yes, I was able to fix it by adding the *1000 to this line:

var startTime = parseInt($('#login_start').val())*1000; // GMT/UTC

I need to make a pull request with this code, and see if they accept it.  

[Jay D]

On 5/14/2023 at 5:44 PM, wbmnfktr said:

Do you have more details on that setup?
I have an old machine running that kind of dev setup but never noticed that issue at all.

Which ProcessWire version are you running?

3.x, downloaded on May 14th. 

[PhilR]

Also getting this issue when updating ProcessWire master version to 3.0.210. We tried the above with no luck so going to rule out issue with WAF in front of the site causing the issue 

[Jo J]

I also experienced this issue. Following on netcarver's advice above, it turns out that my device clock is ahead by over 5 minutes. I adjusted my device time & it worked but thought a broader solution might be better.

This fixed my issue.

var startTime = parseInt($('#login_start').val()); // GMT/UTC
// var maxSeconds = 300; // max age for login form before refreshing it (300=5min)
var clientStartTime = Math.floor(new Date().getTime() / 1000);
var clockDifference = clientStartTime - startTime;
var maxSeconds = 300 + clockDifference; 

But I prefer it be done in the core, so I opened an issue in github. 

[Jo J]

JSYK, this issue has been fixed by Ryan. His preferred fix also addresses when the #login_start gets stale via cache which is important.

Issue #1839 corrects ProcessLogin refresh issue when client and server have different times for UTC/GMT.

The fix has been pushed to the current dev branch as of today for continued testing.