- Welcome to coppermine-gallery.com/forum.
News:
cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]
Recent posts
#61
cpg1.6 miscellaneous / Re: Coppermine Thumbnails & Wo...
Last post by nowordneeded - November 24, 2024, 10:34:16 AMHi Phil:
I'm sorry for being so obtuse. What I meant is that I have the same theme on all the sites I linked. The problem I'm having is the links I have in the posts of Bella and Pedro. the photos aren't showing up as they used to. Unlike Temuera where the links in post show up to the gallery. I'll attach screenshots.
Once again, this is when I try to display the thumbnails from the galleries in the Wordpress main site. They used to work on Pedro and Bella and I'm not sure what's happened. I haven't done anything to the sites. Nothing in coding. Just suddenly the images from the Coppermine galleries aren't showing.
I hope that was clear. If not please let me know.
NWN
I'm sorry for being so obtuse. What I meant is that I have the same theme on all the sites I linked. The problem I'm having is the links I have in the posts of Bella and Pedro. the photos aren't showing up as they used to. Unlike Temuera where the links in post show up to the gallery. I'll attach screenshots.
Once again, this is when I try to display the thumbnails from the galleries in the Wordpress main site. They used to work on Pedro and Bella and I'm not sure what's happened. I haven't done anything to the sites. Nothing in coding. Just suddenly the images from the Coppermine galleries aren't showing.
I hope that was clear. If not please let me know.
NWN
#62
cpg1.6 miscellaneous / Re: Coppermine Thumbnails & Wo...
Last post by phill104 - November 23, 2024, 06:38:30 PMCan you give some more info? I cannot tell what links you mean, where exactly they are not working or what update you did that caused the issue?
#63
cpg1.6 miscellaneous / Coppermine Thumbnails & Wordpr...
Last post by nowordneeded - November 23, 2024, 03:51:39 AMHello:
I've just started getting this issue with two of my sites. I'll give both here because the issue is happening on both. They are:
https://bellaramsey.org/gallery
https://pedropascal.org/gallery
Both are running the latest 1.6.26 (stable) version.
What the issue is I made an update to Bella and found that the links to the updated album thumbnails in the posts are not showing up. They were before and now they're not. I would think it was the theme I'm using, but I have another site here: https://temueramorrison.org/gallery where I'm running the same 1.6.26 (stable) version and yet, the thumbs are showing up in the posts on the main site.
What could be going on that this is just happening on Bella and Pedro?
Thanking you in advance for your reply.
NWN
I've just started getting this issue with two of my sites. I'll give both here because the issue is happening on both. They are:
https://bellaramsey.org/gallery
https://pedropascal.org/gallery
Both are running the latest 1.6.26 (stable) version.
What the issue is I made an update to Bella and found that the links to the updated album thumbnails in the posts are not showing up. They were before and now they're not. I would think it was the theme I'm using, but I have another site here: https://temueramorrison.org/gallery where I'm running the same 1.6.26 (stable) version and yet, the thumbs are showing up in the posts on the main site.
What could be going on that this is just happening on Bella and Pedro?
Thanking you in advance for your reply.
NWN
#64
cpg1.6 upgrading / Re: Unable to connect to datab...
Last post by phill104 - November 15, 2024, 08:51:51 PMWell done. This sometimes happens when hosts upgrade but the upgrade is not fully complete until the customer does a reboot. This if often done to protect the customer, so they can reboot at a time suitable for them.
Glad your issue is resolved.
Glad your issue is resolved.
#65
cpg1.6 upgrading / Re: Unable to connect to datab...
Last post by pegweb - November 15, 2024, 08:44:01 PMIn a move of desperation, I did a graceful reboot of the entire server and the page started to load again. I was able to perform the update. Weird.
#66
cpg1.6 upgrading / Unable to connect to database ...
Last post by pegweb - November 15, 2024, 08:28:39 PMOur web host updated to MySQL 8.x and since then our Coppermine gallery has been broken. We downloaded the latest 1.6.x version and attempt to run the update.php but we get the following. Need help.
Coppermine critical error:
Unable to connect to database !
MySQLi said: 2054 : Server sent charset unknown to the client. Please, report to the developers
Coppermine critical error:
Unable to connect to database !
MySQLi said: 2054 : Server sent charset unknown to the client. Please, report to the developers
#67
General discussion (no support!) / Re: Coppermine Plugin for Word...
Last post by 406man - November 03, 2024, 09:55:25 AMQuote from: Stella on September 03, 2019, 06:16:18 PMI'm most interested in a Wordpress Coppermine plugin that would automatically display on the homepage latest additions and link back to them in my Gallery --6, 9, or 12 images at a time.I've re-read this old thread and think it's worth bringing it up to date. It's possible to do exactly what's requested above using the cpmfetch add-on for Coppermine. Although not a plugin for Wordpress in the usual sense, the implementation uses the Wordpress wpcode plugin to implement PHP code snippets that run cpmfetch
The latest version of cpmfetch is described here and is available for download:
https://coppermine-gallery.com/forum/index.php/topic,80810.msg390631/topicseen.html#msg390631
This article describes how to link a gallery into a Wordpress site:
https://coppermine-gallery.com/forum/index.php/topic,80812.msg390633.html#msg390633
#68
cpg1.6 plugin contributions / Re: showuseragent plugin
Last post by phill104 - November 02, 2024, 07:11:36 PMWell done. Looks quite useful but probably only notes to be turned on during testing/diagnosis.
#69
cpg1.6 plugin contributions / showuseragent plugin
Last post by 406man - November 02, 2024, 06:02:19 PMAs described in the General Discussion section of this forum, one of my gallery users experienced a strange fault. He was the only user with the fault and it was very difficult to track down as I was unable to reproduce it in my test gallery. I had to modify the source code to dump out various variables to a log file in the live system. Eventually, when I'd narrowed down the area where the fault was generated I was able to write a plugin to dump out the relevant information. The fault involved the useragent string sent by the web browser to the server. There was no problem with the Coppermine software as the problem lay in the AVG software that he was using.
When installed this plugin 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"
Having a plugin makes it much easier to generate the diagnostic information in a live environment than changing the gallery source code.
I fully accept that this plugin will be of minimal interest to most CPG Administrators but there might be circumstances in which the information it provides will be useful
When installed this plugin 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"
Having a plugin makes it much easier to generate the diagnostic information in a live environment than changing the gallery source code.
I fully accept that this plugin will be of minimal interest to most CPG Administrators but there might be circumstances in which the information it provides will be useful
#70
General discussion (no support!) / Persistent errors experienced ...
Last post by 406man - November 02, 2024, 05:51:40 PMOne 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.
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.