Your session timed out while posting. Please go back and try again USING CHROME

Started by chelseaphil, January 21, 2019, 05:28:52 AM

Previous topic - Next topic

chelseaphil

I know there are huge numbers of posts on this topic. But I cannot find one that is the same as my issue. I do not use Simpleportal or any portal. I use the Curve Multi Color theme. It has the suggested added code to the /form.

This ONLY happens in CHROME every other browser I try is fine.  It could be why since going onto 2.0.15 why my users have dropped. It was brought to my attention by a new member that could join the forum but then not access it when logging in. It happens using both types of login available.

site https://arboleas.co.uk/forum

Thanks in advance

Sir Osis of Liver

Session timeout while posting is not a login error.  Can you post the actual error from your log?
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Illori

Quote from: Sir Osis of Liver on January 21, 2019, 08:14:56 PM
Session timeout while posting is not a login error. 

actually it is, i have seen users report this error when they are lacking the login fix.

Sir Osis of Liver

If the session check is missing, no one should be able to login with any browser.  Don't remember if Curve MC requires the fix, believe it does.

I'm able to login with IE11, checking error log.

Getting a lot of these -



https://arboleas.co.uk/forum/index.php?PHPSESSID=u4lfvtvtf3i1qdrgnh1phv98m3&action=login2
Unable to verify referring url. Please go back and try again.



repair_settings doesn't see any bad paths.

Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

chelseaphil

Just tried to login using Chrome and nothing shows up in the error log referring to it.

This is what appears after the login attempt is made
An Error Has Occurred!
Your session timed out while posting. Please go back and try again.

The Sessions code IS in the index.template file. Like I say it works fine in all browsers except Chrome.

As Sir Osis of Liver says, there are however lots of errors when members use https://www.arboleas.co.uk/forum/index.php?action=login2

This does show up in the error log:

Apply Filter: Only show the error messages of this IP address 178.156.111.145 
     Reverse chronological order of list Today at 09:40:42
Apply Filter: Only show the error messages of this session cc5c2aad7d45e57db24c4e6c30b50e3b
Apply Filter: Only show the errors of this type Type of error: User
Apply Filter: Only show the error messages of this URL
https://arboleas.co.uk/forum/index.php?action=login2
Apply Filter: Only show the errors with the same message
Unable to verify referring url. Please go back and try again

Should I have a redirect on the server if someone uses https://www.arboleas.co.uk/forum they are redirected to arboleas.co.uk/forum

Would that overcome the URL issue?


chelseaphil

I have this in my htaccess file. Does not look right to me. But I am not a coder.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteOptions inherit

Sir Osis of Liver


#Force www:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301,NC]

#Force non-www:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

chelseaphil

That code stopped the site from loading altogether. I changed example to:

#Force www:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^arboleas.co.uk [NC]
RewriteRule ^(.*)$ https://www.arboleas.co.uk/$1 [L,R=301,NC]

#Force non-www:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.arboleas\.co.uk [NC]
RewriteRule ^(.*)$ https://arboleas.co.uk/$1 [L,R=301]

Kindred

Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Sir Osis of Liver

Posted both so he can pick one.  Don't know if either will solve the problem.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

chelseaphil

Using this made no difference. Like I say, it is ONLY when using Chrome that the issue is there.
#Force www:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^arboleas.co.uk [NC]
RewriteRule ^(.*)$ https://www.arboleas.co.uk/$1 [L,R=301,NC]

Except that it produced the same error message when using Firefox as well.
So removed it and put this one back on.

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteOptions inherit

Sir Osis of Liver

I don't install Google software on my computers, so can't test it in Chrome.  The 'Unable to verify referring url' login errors are probably all bots, nothing to do with member logins.  Thinking it may be a certificate problem, maybe you could ask host support to look into it.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

drewactual

can you go into incognito mode in chrome and report back if it continues?

I played (really hot place) trying to figure this out way back when the 'fix' was just surfacing...

the issue is with Chrome and it's sneaky datafile storage... gotta dig into c:\windows\program files(86)\google\chrome and the folder that looks like an IP to clear it... chrome holds onto what amounts to a cache to 'appear' faster like a chubby kid does his stash of cookies. 

if it does it in 'incognito' mode, then this is NOT the issue. 

you can go in there and clear a lot of the data stored (it will rebuild it you can take to the bank, google loves that- and why use their own cloud when they can use your computer?) and clear the problem for yourself, and you can instruct users how to do this, but...... it's a def turn off for users.

this isn't a SMF issue, by the way.  it was created by an SMF issue, but it's googles fault for holding onto those files much longer than expiry directives in htaccess files. 

so... you gotta bust the cache.

one way to do it i don't think is that difficult, is to make a file duplicate to your login.template and call it something else, and point your forms to it.  I've NOT done this, but it is conceivable it would work?

How i ended up doing it in the end (and it's not over with yet- some members still have issues with this one and a half years later) is by leveraging htttp:2 and 'pushing' (if i'm not mistaken 'preload' would achieve the same result) the file... for good measure i reduced the expiry to minutes atop of that- and left it that way for a month or so... the error's stopped almost instantly.. after that month i stopped pushing it and set the expiry's to a respectable amount of time.... in simplest explanation a http:2 'push' crams the files needed to render a page down the browsers throat instead of waiting for it to parse instructions and requesting it- the concept being it will already be there when the browser realizes it needs it saving a trip through the tunnel.

if the cache couldn't be busted in this manner, the only other option available is to install a "no-cache" and "?xxx" at the end of that file to bust the cache... may work, may not.. will leave that to experts. 

but... if it does not challenge your session in incognito mode, then it's the cache almost with certainty.     

Advertisement: