Well not infinitely on the second time, the second time around which it was about 20 times of successful attempts that were disallowed and probably an hour between the time where I was stuck infinitely and the time I wasn't (session related?), I should also mention that on the first tap, I wasn't given a captcha nor did it click, it seemed like a misfired event
After analysing, the urls used were always containing www
Lately now the issue is non-existent however I have since been using the desktop version by default by clicking the "Desktop Version" once down bottom, this setting has since stuck.
I would assume the moment I attempt to login from this same device outside of desktop version, the change in headers would cause cookies to be invalidated and require another captcha.
As this issue appears to relate to non-chromium headers triggering this, I can only assume there is some exploit ITW right now that is used by botters to execute these non-standard attacks.
Nevertheless, I highly recommend looking into LetzEncrypt for SSL certification. Whilst Cloudflare does provide us with a free, easy and professional solutions, it comes at a cost of managed ssl certification.
And let's be fair, if the end goal is simply for ddos protection, then wouldn't a decent host with a mitigated ddos attack plan, ip tables, f2b, lets encrypt and a standard Debian system be enough?
Interested to hear your take on this since it seems like you're making a trade off for ease of use (which I completely understand).
Unfortunately, we aren't able to reproduce this issue (even with active adblocks), we eased some settings on cloudflare, but that is all we can do for now. The captcha is to combat ddos attacks. On a ongoing attack, the settings are set more strict, we don't show captchas annoy you, it's to keep the site online.