Request refused if I don't do anything on the site for too long

[DeCysos]

▶🚶‍Reproduction steps

1. Dashboard -> Settings -> Image Upload --> Upload user interface SET On-page container
2. Go to youre Site (example: https://pfs.red) & Login
3. Upload a Picture
   
   (use this button)
4. stay on the page (keep tab open) for 1 hour (no less) (Do nothing in the time in the TAB)
5. Upload an image again
   (Now try to upload two or more pictures (the error should only come with one picture, but you would theoretically be redirected immediately))
   
6. See the error message

😢Unexpected result


== Request denied

📃Error log message

[Tue Jan 07 11:51:53.403114 2020] [proxy_fcgi:error] [pid 30419] [client 172.68.xxx.xxx42440] AH01071: Got error 'PHP message: Anfrage verweigert'

🤔 What I think

It is a problem with Ajax (Javascript) that it does not recognize the session cookie (session) without the page being reloaded.


For test purposes, I completely removed the Samesite option from me, so all cookies should be set and readable.

 

[DeCysos]

I'm doing another test in Firefox on two different servers.
I will tell you the result soon.

I can not imagine that it is due to the browser setting. Since I didn't close the browser, I just continued to work normally in other tabs.

I wasn't logged out either, it's just that you couldn't upload the picture.

 

[DeCysos]

so in firefox the same problem

Before upload


after the upload attempt


After Reload



Unexpected for me: The SessionID has remained the same. I assumed that it would change.

I have now tested this in Firefox 71
I can not really imagine that it is the browser, if so please tell me exactly it could be.
I do another test on another server with a fresh installation in Firefox.
Maybe it is a server setting after all

 

[Thanos92]

@DeCysos I have the same issue like you! With your new tip working fine, but without this option enable i get the same error every time!

 

[DeCysos]

The same on demo.chevereto.com


(I tried between 01:04 and 01:06)
method:

• started around 00:00 with open demo.chevereto.com (in chrome 79 browser)
  I was already logged in.
• waited at least an hour.
  Leaving the tab open, but still surfing in other tabs.
• After about an hour, let the tab display. (01:04 ?)
  (do not reload the page)
• The upload button (press top right)
• Select a few pictures from the hard drive
• Maybe choose the category.
• press the Upload Button
  process is beginning with upload ....
  When the picture is uploaded, the script starts processing, after this has been done there comes the exclamation mark (error)

So Rodolfo,
it is probably due to the server configuration.
Since this error does not occur on one of my servers.

But I can't say why.

 

[DeCysos]

I have just checked whether any Apache modules are activated on the "beta.pfs.red" (B) server which are not activated on the other server (A).
But that's not the case. On the contrary, a few more modules run on server (A).
The other Apache instructions also do not differ from what Server (B) has.

What could be the cause of this?

 

[Rodolfo]

I've tested on the demo and I get the same outcome.

The response code is 400 (Bad Request), which is thrown because the posted value of auth_token doesn't match the one stored on the server, it changed after the PHPSESSID timeout which is normal.

Session data timeout according to the value of session.gc_maxlifetime which determines how many seconds to remove any old session data. Since you didn't issue any request, the session data was destroyed (but not the session cookie).

The bug is that the software should refresh the auth_token after the timeout, for now I suggest to use /upload route.

 

[DeCysos]

Very nice that you could also confirm that.

Can the problem be corrected by changing the script or is it absolutely necessary to change the server?

Spoiler: Maybe the solution would be as follows:

An Ajax script makes a query every 5 minutes (possibly adjustable in the dashboard or in Settings.php) whether the user is still online. Similar to forums where it is checked whether the user is still online.

 

[DeCysos]

Session data timeout according to the value of session.gc_maxlifetime which determines how many seconds to remove any old session data. Since you didn't issue any request, the session data was destroyed (but not the session cookie).

I checked both servers for session.gc_maxlifetime and found no difference.

Server B - (no error)	Server A - (with error)

Only the session.gc_probability value is different.
Server A: 0
Server B: 1

 

[Rodolfo]

We only need a timeout on the session gc. If the timeout is reached, an alert message should be printed on screen informing this to the user. The user clicks "OK" and the window refreshes, causing the session to refresh and everything will be working again.