Persistent errors experienced by just one user

[406man]

One user on a gallery that I run had a strange persistent fault. This note explains the circumstances, error messages, the debugging steps that I took and how the problem was eventually fixed. It was caused by AVG software. To be clear, there was no fault in the Coppermine software and I'm not asking for any support. Other Gallery Administrators could easily have individual users who experience this problem which is why I'm describing it here.

I'll call the user John – not his real name. At first the gallery was running 1.5.20 and John got an error message when uploading:

"ERROR  A valid form token could not be found"

The message only came when uploading. He had previously been uploading without difficulty and this problem started one day without any obvious changes having happened. Clearing cookies, temporary files and the Sessions table in the database made no difference. John was the only user affected. If I logged in using his credentials on a browser on my PC the error wasn't present. John was using Firefox but got the same error message when uploading using Chrome. I tried logging various parameters to the log file but the investigation only got more awkward as I had limited access to the hosting environment. Because this was an obsolete version of CPG I upgraded to 1.6.26. My gallery is not bridged so all authentication is in the CPG database.

With 1.6.26 John still had a problem with uploading but the error message was now:

"You don't have permission to perform this operation".

Clearing cookies, temporary files etc didn't help. I loaded a copy of the gallery into my development environment and was able to add some deeper diagnostics and use Xdebug but in the live environment I still had to resort to sending debug messages to the log file as I couldn't reproduce the error.

What I did was to compare the messages generated in the live system by a successful upload with my login against a failed upload with John's login. By digging deeper and deeper into the code and adding more debug messages I was able to pinpoint the exact difference that was causing the failure. I'll describe this now but must apologise in advance as it gets very technical. A Gallery admin would never normally need to get down to this level of detail.

When a user does an upload they are authenticated. CPG does more checks than are needed (in my opinion) but that's an aside. As part of the authentication process the code checks for an existing session using a session id. The session id is created from the combination of a cookie value and the encrypted combination of the HTTP_USER_AGENT string returned by the web browser plus the site URL.

The problem arose because the value of the HTTP_USER_AGENT string returned by the web browser was different in the upload compared to every other operation so the calculated value of session_id was different. This meant that when the code checked for an existing session it couldn't be found because there was no session with that session id.

A useragent string returned by my web browser looks like this:
'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0'
The useragent string returned from John's browser looked like:
'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Unique/97.7.6998.67'
In itself there's nothing wrong with John's useragent string although the "Unique/97.7.6998.67" on the end is strange and not part of the Firefox standard. The problem was that when John did an upload the useragent string was as below and you can see that the strange Unique bit at the end is missing:
'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36'
The missing part of the string caused the session_id generated to be different to what was expected so an existing session could not be found and the authentication failed. Hence the error message and failed upload.

A Google search lead me to this fantastic post on a Mozilla forum:
https://discourse.mozilla.org/t/extraneous-product-version-combinations-in-user-agent-ex-herring-94-1-8750-51-openwave-96-4-6033-34/107587/3

The circumstances match what I was seeing from John's machine. A reply to the above post said that the modified HTTP_USER_AGENT string was caused by anti-tracking software and was unconnected to the browser. 

I had a Zoom call with John where he shared his screen with me so I could see what was on his machine. In among the software was a program called AVG Anti Track. This is separate from the main AVG anti-virus software. There is a feature in the user configuration screen which allows you to specify sites where the anti-tracking is not enabled. He added the URL for our site and this fixed the problem. I now know that he recently upgraded his AVG software recently which must have started the problem. The root cause of John's problem was not the use of anti-tracking software but the fact that the anti-tracking software behaved inconsistently in the way that it modified the HTTP_USER_AGENT string, leading to the failed authentication.

In summary, if you're a Gallery Administrator and have a user experiencing a similar problem what should you do ?

1) in the browser, delete cookies for your site and delete temporary files. If the problem persists, go to step 2
2)Try a different web browser. If the problem persists, go to step 3.
3) Change the user's password and log in as them on a known good machine+browser. If the problem goes away when you do this, it's very likely that they have the tracking fault that I described.

For the more technically-minded I've written a plugin called showuseragent. When installed this will write the HTTP useragent string, plus user id and name of the calling function into the global log file for every CPG transaction. Below is an example of what's written to the log file:

Nov 02, 2024 at 04:52 PM - Showuseragent plugin. Called from: pluginmgr.php; USER_ID is 1; HTTP Useragent string = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"

The plugin is available in the plugin section of this forum.