I'm sorry I can't help a lot with this issue (it'd be easier if I was experiencing it myself), but if it's believed to be a phpBB (forum software) bug, we use 3.0.10 right now and 3.0.11 is the latest. Here's the changelog:
https://www.phpbb.com/support/documents ... on=3#v3010I did see issues relating to "stuck PMs" fixed in 3.0.11 (some folks here may remember that issue -- unrelated to what we're talking about, but I just happened to notice it while skimming).
3.0.12 is not out yet, but here are the changes proposed so far:
https://www.phpbb.com/support/documents ... on=3#v3011If the issue is believed to be with PHP, the PHP version used is 5.3.15. The latest is 5.5.3, and if there was a place that was most likely responsible for this, it'd be in the sessions module or (remote possibility) the core.
http://www.php.net/ChangeLog-5.phpMy gut feeling is that it's some kind of phpBB "thing", since server-side I don't really see anything that indicates an issue, but it's hard for me to diagnose this (as said, can't really help with that). I did find this:
https://www.phpbb.com/community/docs/FA ... out_issuesWhat's described here is vague/weird -- the settings are actually under the General tab, under Server Configuration / Load Settings. I've attached two screenshots (01.jpg and 02.jpg) showing what we have these set to. I've also included a screenshot of the Cookie Settings section since some of what thefox mentioned above is referenced there.
Keep in mind two things when looking at these screenshots (but please keep reading):
1) The session timeout value shown is just an indicator of how long you can be actively logged in before the board will automatically log you out. If you are a person who leave a tab open at all times here at the forum, then yes, my understanding is that you will be getting logged out after 3600 seconds of not interacting with the site anywhere; this is by design. Increasing this number might sound like a reasonable thing to do, but then again it may not be a wise thing to do. For example if someone is leaving the browser window/tab to the site open for an entire day, then the number would have to be increased to 60*60*24 = 86400 seconds or thereabouts. I would much rather people just close the damn tab/window when they're done. (I actually generally do not have to re-log-in very often on my setup, it's quite rare, but I also do not use tabs and I do not leave browser windows open indefinitely; I always [X] out of things when I'm done)
2) The settings shown there are phpBB-specific and not PHP-specific; PHP has its own types of control over sessions as well (specifically the GC cleaning up old files, etc.). So these two things require a somewhat "balanced" series of settings that match up well and don't conflict with one another.
Anyway, this caused me to find this post:
https://www.phpbb.com/community/viewtopic.php?t=2015965Where someone states up front that the "session IP validator" basically looks at the network block you're part of, and requires a session to be valid only if the client IP connecting is within the same /24 (this would be a security measure). So, if your ISP is doing something like NAT'ing your outbound connections to the forum (usually done at workplaces for lots of reasons, but also for load balancing), and the connecting client IP could therefore flip in real-time from 1.2.3.4 to 1.2.9.16 (for example) then I can see this causing a person who was active on the forum to suddenly log out. Remember, this is not your "workstation IP address", this is actually what gets seen IP-address-wise on the nesdev server.
The settings we use permit the last octet to float/change (i.e. the A.B.C method), as indicated in the 03.jpg screenshot. I am happy to try changing this to something else ("None" possibly), but I would much rather not if the root cause can be determined.
But as you can see, there are other security measures phpBB has in place (and some I have blacked out in the screenshot because we do know spammers/etc. show up here and this is not the Moderators board so these posts/this information is public) to also "verify" that the client connecting is who it says it is -- specifically "validating the browser" (probably comparing User-Agent strings), handling situations where the browser (HTTP client) includes the X-Forwarded-For header (this is often use by caching proxies, so if you're at a workplace that uses an HTTP proxy server then this header might be included and your web browser wouldn't be sending it, the proxy server would -- the only way for us to see this would be to use tcpdump on the server, which I cannot do) and also referer validation.
Basically my point here is that there's lots of "stuff" that could cause this to go awry for someone, and troubleshooting it requires familiarity with all the aforementioned things, plus requires that the troubleshooting be done in real-time. For example I cannot go back and look at site (Apache) access logs to track down thefox -- username/etc. is not stored anywhere in the logs, so all I could go off of is IP address, but as I said above if the IP address is shifting around a lot then my greps/etc. are going to be wrong/incorrect (the site gets hit a *lot*).
The best I can do is try to get
exact timestamps from you (please include timezone, or if you can just give me UTC timestamps that would make my job much much easier (server log timestamps are in UTC)) when you see the issue start, along with the exact time you had to re-log-in, and I try to figure out if it's the session IP validator that's causing it. I've already grepped through logs and there just isn't enough information to key off of there (no way to correlate an access to a username).
Welcome to The Internet(tm) and Web Crap of today, and what we SAs have to deal with all the time.
