- 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
#21
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
#22
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
#23
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.
#24
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
#25
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.
#26
cpg1.6 install / Re: cpg 1.6 and smf 2.1.4 ques...
Last post by Dark_Angel - October 21, 2024, 07:01:04 PMOK, I can try that, should I first add the cpg "now" gallery tables to the forum's DB? They are not on the same database. I have no idea what the bridges user pass is either it has been so long.
#27
cpg1.6 install / Re: cpg 1.6 and smf 2.1.4 ques...
Last post by phill104 - October 20, 2024, 03:36:06 PMBridging does not need database manipulation. What it does is just points to the members and permissions details of the bridged application instead of using the coppermine version. So no need to import or fiddle with any of the databases.
I would suggest you start by upgrading to CPG version 1.6.26 using the installer stub to upgrade - https://github.com/coppermine-gallery/cpg1.6.x/releases
I would suggest you start by upgrading to CPG version 1.6.26 using the installer stub to upgrade - https://github.com/coppermine-gallery/cpg1.6.x/releases
#28
cpg1.6 install / cpg 1.6 and smf 2.1.4 question
Last post by Dark_Angel - October 20, 2024, 05:24:14 AM/asking questions before I do it. I am forced to do this upgrade due to PHP going to 8.3
Iam using right now smf 2.0.19 but am having to upgrade to 2.1+ I do have Coppermine Photo Gallery 1.6.09 (stable) and it gave us the dickens to install it due to many errors. It was supposed to be bridged but it would not behave. So although it appears to be bridged, the darn thing is not associated with the member list of the forum.
My question is I am most likely to have to upgrade the forum, use my forums current database but do I then just add the database from the existing gallery to the forum database or install the gallery fresh into the DB then import the existing db into it?
After 17 years of not needing to do anything but minor updates I feel like a total newbie, sorry.
Iam using right now smf 2.0.19 but am having to upgrade to 2.1+ I do have Coppermine Photo Gallery 1.6.09 (stable) and it gave us the dickens to install it due to many errors. It was supposed to be bridged but it would not behave. So although it appears to be bridged, the darn thing is not associated with the member list of the forum.
My question is I am most likely to have to upgrade the forum, use my forums current database but do I then just add the database from the existing gallery to the forum database or install the gallery fresh into the DB then import the existing db into it?
After 17 years of not needing to do anything but minor updates I feel like a total newbie, sorry.
#29
cpg1.4 upgrading / Re: How to export database
Last post by AnnieHoney - October 13, 2024, 03:38:56 AMthank you! i'll try that
#30
cpg1.6 plugin contributions / Re: HTML5 Slideshow plugin
Last post by Chuckster - October 13, 2024, 12:11:18 AMI was just going through my Coppermine Gallery after upgrading to PHP v8.3 and encounter the following error with ANY PHP v8.x version:
It seems to be working fine on PHP v8.x, but with this error, and without knowing 100%, would you mind looking in to this?
Code Select
Deprecated: Optional parameter $albname declared before required parameter $uio is implicitly treated as a required parameter in /plugins/html5slideshow/config.php on line 102It seems to be working fine on PHP v8.x, but with this error, and without knowing 100%, would you mind looking in to this?