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.

I just filed issue #77348 and had to go through...
ERROR:

    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.

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.

[1] http://git.php.net/?p=web/bugs.git;a=blob;f=www/report.php;hb=HEAD

I just got the "Please enable cookies so the Captcha system can work" error again filing #77351.

Wow. I'm afraid petk is right. I just triggered this bug multiple times filing https://bugs.php.net/bug.php?id=77352 by reloading https://bugs.php.net/report.php 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.

I just got the cookies bug again filing #77353. I believe bugs.php.net is confused by a session loss.

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.

Thank you petk, but would you mind clarifying to which exact project you refer to?

The bugs.php.net 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.

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).

> 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.

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.

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

I am under the impression that this has been fixed.

No, the issue has not been fixed.  petk's analysis[1] is spot on.

[1] <https://bugs.php.net/bug.php?id=66653#1545852651>

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 
$_SESSION['form'][$formtoken]['captcha']
or
$_SESSION['report'][$formtoken]['captcha']


$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.

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:

/var/lib/php/sessions

Given that bugsnet has been superseded by GH issues, it
sufficiently safe to assume that this issue won't be fixed.