|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66653 "Incorrect CAPTCHA" trying to file or comment a bug report
Submitted: 2014-02-06 03:57 UTC Modified: 2022-01-20 16:30 UTC
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: chealer at gmail dot com Assigned: peehaa (profile)
Status: Wont fix Package: Website problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2014-02-06 03:57 UTC] chealer at gmail dot com
As reported in bug #33449, bug #53255 and bug #66393, CAPTCHAs on have been broken for as long as I can recall.

danielc fixed this in January, as can be seen in bug #66393. According to danielc's latest comment there a few hours ago, the fixes had been deployed. However, I experienced the same issue when reporting bug #66652.

The submission form I'm filling is "48 + 26 = ?" as challenge. My answer is 74, and I am about to click "Send bug report".


I got an error. After clicking, the ITS said "Incorrect Captcha". It now says:

Solve this new problem:
24 - 3 = ?

I entered 21 as answer, and I am about to click "Send bug report" again.


I got a warning:


Are you sure that you searched before you submitted your bug report? We found the following bugs that seem to be similar to yours; please check them before submitting the report as they might contain the solution you are looking for.

If you're sure that your report is a genuine bug that has not been reported before, you can scroll down and click the "Send Bug Report" button again to really enter the details into our database. 

Since I am sure, I am about to do that.


I got another error:
Incorrect Captcha

The form now contains:

Solve the problem:
23 - 19 = ?

I entered 4 as answer and am about to click "Send bug report" once again.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-02-06 04:01 UTC] chealer at gmail dot com
The experience I had when filing this report is similar to the one I had when filing bug #66652. I also got several errors when filing #66652. 3 or 4, if I remember correctly. It could be that I entered one incorrect answer once.
 [2018-12-26 18:50 UTC] chealer at gmail dot com
I just filed issue #77348 and had to go through...

    Please enable cookies so the Captcha system can work

...first, before seeing this bug a few times too. No idea if these bugs are technically related.

I just tried posting this very comment, and went through the bug twice already.
 [2018-12-26 19:30 UTC]
Hello, thanks for reporting these. The Captcha system here relies on the session_start() in the code[1] and on having enabled cookies in the browser.

I think I've just found how this issue happens, so stay tuned for a fix in the following days... It happens due to a too simplistic captcha generation. Once the report page is opened one captcha question and answer is generated (for that browser tab). If user opens a new bug page (or report page) in a new browser tab a new answer and question get generated and previous ones are wrong and this strange error pops up. If you possibly spot any more on this issue sooner than me, let me know please.

 [2018-12-26 20:00 UTC]
-Assigned To: +Assigned To: petk
 [2018-12-26 22:50 UTC] chealer at gmail dot com
-Summary: "Incorrect CAPTCHA" trying to file a bug report +Summary: "Incorrect CAPTCHA" trying to file or comment a bug report
 [2018-12-26 22:50 UTC] chealer at gmail dot com
I just got the "Please enable cookies so the Captcha system can work" error again filing #77351.
 [2018-12-26 23:18 UTC] chealer at gmail dot com
Wow. I'm afraid petk is right. I just triggered this bug multiple times filing by reloading in a different tab after each CAPTCHA I was given. I stopped when it became obvious that I could have reproduced this as many times as I wanted.
 [2018-12-27 02:05 UTC] chealer at gmail dot com
I just got the cookies bug again filing #77353. I believe is confused by a session loss.
 [2019-05-23 13:33 UTC]
-Assigned To: petk +Assigned To:
 [2019-05-23 13:33 UTC]
I'm unassigning myself from this issue. According to my evaluations and calculations this project is too messed up to move further. Apologies for trying to slightly improve it. Developer experience here is so low that it is not possible to fix it actually.
 [2019-05-28 02:53 UTC] chealer at gmail dot com
Thank you petk, but would you mind clarifying to which exact project you refer to?
 [2019-05-28 12:07 UTC]
The in particular since this is related to it. Otherwise, I'm referring here to all web/* projects (bugs, main website, pecl site, docs editor app etc.) with this.
 [2019-05-29 02:43 UTC] chealer at gmail dot com
Thank you petk
There is no need justify unassigning a ticket, but if you do, I would appreciate a deeper explanation (perhaps with a link).
 [2019-05-31 14:42 UTC]
> There is no need justify unassigning a ticket, but if you do, I would appreciate a deeper explanation (perhaps with a link).

Hello, there isn't any particular link to the exact problem here actually or steps to reproduce this. This is a thing that happens over several periods of time and loads of discussions so one can make an impression of how things are being done here, what kind of practices are used to fix and maintain (or not maintain) certain parts of the websites, and mostly the too expensive burden being present to fix some existing issue. You can trust me, that I've invested a lot, and tried many things to get things moving forward here. 

Mostly it's the problem of what kind of practices and requirements run these projects and if these can't be changed neither moved forward into different and better ways then from my point of view this app can't be moved forward. This app is not a tutorial how to do things in web. We just need a fully working environment to report and have an overview of the bugs of PHP software...

Now, if we need to discuss if even using Composer is a good thing or not, or if some weird mixed, customized unsynced coding style is used in multiple different files and syncing that into a common coding style for particular project is a problem of a level that causes arguments and issues, or that some dependency is a problem then even if there would be a discussion happening we can already see that it's happening way to slow to something to be done. I've opened several topics that would be good to discuss but no responses. I couldn't move forward since my changes started causing all kinds of conflicts etc etc and here we are now.

I'm really not into some "fun" challenges that are mostly brain damage so I simply move on to something else instead where things can go forward more smoothly.

I'm not saying that someone else couldn't fix this. Maybe they will see a way with this messy coding way to improve this app and they can do it... But not me, sorry :) I have no time for this anymore. Way too much quality things have been already proposed and not welcomed so, let's just move on and we're good to go to the next things on our todo lists. Cheers.
 [2019-06-01 17:53 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: peehaa
 [2019-06-01 17:57 UTC]
I will have a look in the (relatively) short term to see if I can repro it too and can implement a quick fix for it where I find the problem.
 [2019-06-01 23:54 UTC] chealer at gmail dot com
Thank you petk. Your description brings me as many questions as it answers though. I suggest you explain your decision on your blog, or post an explanation to a PHP mailing list.

Thank you peehaa
 [2021-07-11 14:13 UTC] chealer at gmail dot com
I am under the impression that this has been fixed.
 [2021-07-11 14:51 UTC]
No, the issue has not been fixed.  petk's analysis[1] is spot on.

[1] <>
 [2021-09-18 22:10 UTC] ddpm at liscovius dot de
There are 2 potential reasons: 

1. Session is timed out server side before user submits the form. Either by normal PHP session cleanup logic or server based cron job cleaner (Debian's sessionclean you naughty boy!, see /etc/cron.d/php ) This is a thing the maintainer of the web server has to take care.

2. The $_SESSION must be able to handle multiple browser tabs:

Instead $_SESSION['answer'] use 

$formtoken can either be random generated for each form loaded (session file storage grows with each page load)
or be reused until the captcha was solved for the $formtoken. (

The forms could contain the formtoken as 

<input type="hidden" name="formtoken" value="<?= $formtoken ?>"/>

Or the captcha only needs to be solved once for a user session and all following form submits do not need solve annoying captchas.
 [2021-09-18 22:16 UTC] ddpm at liscovius dot de
You can also watch the entries of the currently existing user sessions server side when stored in file system: On Debian 10 the default location seems to be:

 [2022-01-20 16:30 UTC]
-Status: Assigned +Status: Wont fix
 [2022-01-20 16:30 UTC]
Given that bugsnet has been superseded by GH issues, it
sufficiently safe to assume that this issue won't be fixed.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 21 01:01:28 2024 UTC