Captcha problem (confirmation code never match) Captcha problem (confirmation code never match)
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

Captcha problem (confirmation code never match)

Started by Tempestdrg, June 08, 2010, 03:09:01 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Tempestdrg

Hello,

I recently upgraded to cpg v1.5.4 and began to modify the default captcha in order to filter out spambots. I increased the number of letters a user need to enter for registering/posting comments as a guest and changed the color but my modified captcha didn't work so, I removed everything except the configuration file and the albums folder and upgraded from v1.5.4 to v1.5.6.

Even with this version, completely unmodified, the captcha does not work, it always says "The confirmation code didn't match". The users of my gallery report the same problem. I know phpBB has some sort of "purge cache" function that need to be activated for updates to works, is this the same with coppermine? If not, does anyone have an idea on how I can solve this problem.

Also as a note: editing the number of captcha characters in "captcha.inc.php" and "captcha.php", will create problems since there are at least 3 files (register.php, contact.php, and another one I haven't found yet) that are coded to allow only 5.

My gallery:
http://www.dragnix.net/Artistic_Section/Drawings/
Version: 1.5.6

Thanks for any help you can provide.

Joe Carver

You have rendered the "Powered by Coppermine" tag invisible. No one will want to reply because of that modification.

Tempestdrg

When I changed the color of the light grey background for the description/comments to the original (darker) grey of the old v1.4.x igame, I inadvertently changed the "Powered by Coppermine" text to a color that was near invisible.

Sorry about that. It was just an honest mistake here and the tag should now be visible.

Joachim Müller

When reporting issues with captcha it might help to post a non-admin test user account to give supporter a mechanism to actually perform tests.

Joe Carver

Quote from: Joachim Müller on June 09, 2010, 08:05:48 AM
When reporting issues with captcha it might help to post a non-admin test user account to give supporter a mechanism to actually perform tests.

Agreed......

@ Tempestdrg - have you tried using the Captcha on the Contact form? I would also suggest re-uploading a completely fresh clean copy of cpg 1.5.6 in case you missed a file or did not undo all of your mods. Use a good ftp app (Filezilla) and make certain that the older files are indeed being replaced.

Tempestdrg

The confirmation code doesn't match for the contact and the registration form as well as for posting comments. Since I don't want to block new users from registering, the registration process is not using any captcha at this moment.

Also, I have created a test account (username:test, password:test) on my gallery and I have re-uploaded a newly downloaded copy of cpg156 over it but it didn't solve the problem.

To have a better idea of the nature of the problem, I have created a new gallery (a test user is availale there too; user: test, password: test) using a new database and fresh copy of coppermine ( http://www.dragnix.net/test/ ) to see if this problem was caused by the upgrade process or if there was issues with my database / modifications with my gallery. But the captcha still gives me the same result. The Test gallery doesn't contain any modification and is set up with the default values (except for the option allowing guests to post comments). The files on both gallery have been uploaded using the latest version of Filezilla, and the versioncheck function doesn't see any problem.

Yesterday, in captcha.inc.php, I changed
$aCharSet = array(), // array of characters to select from - if blank uses upper case A - Z
to
$aCharSet = array('A'), // array of characters to select from - if blank uses upper case A - Z
But the captcha still reports that the confirmation code doesn't match even if the answer is always "AAAAA". This change has been reverted back to normal when I re-uploaded an unmodified version of the file.

I'm not really sure what to do next... My site is hosted by Ipower.

Joe Carver

Good job with setting up a test gallery. That isolates the problem to your server, not the upgrade.

Set  Enable debug mode to "Yes everyone". Set   Display notices    on/checked

Please don't post the debug output and also keep in mind that some of the notices have no impact/meaning to what you are tryiing to fix. I will try to revisit your test gallery later today.

(long shot)
Run phpinfo - does the output show MD5 support? And for someone who might know more than I do - what are your versions of php and MySQL ?

Your problem is unique, if not singular but you are off to a good start fixing it with the test gallery.

Tempestdrg

I have enabled debug mode on both gallery. My host allows me to set the php version (by default) either to v4.4.9 or v5.2.12; it is currently set to php5.

Also, in the phpinfo, MySQL version is 5.0.51a (Client API version) and MD5 is mentioned only in the "Hashing Engines" (hash support enabled).

Joe Carver

It looks like your server is not supporting Session correctly.

Quote/include/functions.inc.php

    * Warning line 3779: session_start() [function.session-start]: open(/var/php_sessions/sess_1d48f4b0e6da5eb4a87f1350fc5c7f49, O_RDWR) failed: No such file or directory (2)[/li][/list]

What does your phpinfo say about Session?


(I might be out of my league trying to help any further with this.)

Tempestdrg

I think it would make sense that Session isn't configured properly because in phpinfo, the session.save_path is "/var/php_sessions". However, there are no such folder on my host, it seems to use "root/phpsessions".


session
Session Support enabled
Registered save handlers files user sqlite
Registered serializer handlers php php_binary wddx

Directive Local Value Master Value
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_httponly Off Off
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 100 100
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
session.hash_bits_per_character 4 4
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /var/php_sessions /var/php_sessions
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 1 1

Joachim Müller

Please contact your webhost then and ask them to look into this. You're welcome to show them a link to this thread.

Tempestdrg

This problem was indeed caused by an incorrect session save path, I have contacted my webhost and they have fixed this issue.
Everything seems to work perfectly now.

Thanks for the help.

phill104

Thanks for returning and resolving your thread ;D
It is a mistake to think you can solve any major problems just with potatoes.

pwa

Quote from: Tempestdrg on June 10, 2010, 07:43:07 PM
This problem was indeed caused by an incorrect session save path, I have contacted my webhost and they have fixed this issue.

I had the same problem (provider home.pl in Poland).

The easiest way is set folder /tmp for session data in main application directory - mayby this can help others...

regards, Pawel

Joachim Müller