Suggestion for Accesibility Feature

[aepaegayah]

Hello,

I have some blind acquaintances that are having trouble with the login captcha.

Their primary browser is edbrowse [0], and unfortunately, the "Play audio for CAPTCHA" link simply returns a zero-byte response, preventing them from logging in. Edbrowse is a 100% text browser and for obvious reasons it completely ignores the src attribute of image elements.

However, it appears that the sign in page is initializing the session's random number when a request to captcha/show_captcha.php is made. Since edbrowse ignores the image source, this request is never made and the captcha integer is never initialized. Apparently, projecteuler.net/read_captcha.php in this state returns a successful, but empty, 200 response.

Is there any possible way to handle this differently? We are extremely pleased that Project Euler is not using Google reCaptcha and would be thrilled if a good solution to this issue could be found.

Thank you in advance!

[0]:https://edbrowse.org/

[euler]

Hi, aepaegayah. Accessibility matters a great deal to me, so thank you for giving me some insights into the problems some of our visitors may have.

I have made some changes to the way that the CAPTCHA session is generated. If no image is present on the page, and a session has not been generated, clicking the "Play Audio for CAPTCHA" link will initialise a session.

Please let me know if these changes solve the problem.

[aepaegayah]

Hello Euler,

Even at the ripe age of 315, you work fast! Thank you.

I just gave the login page a whirl, and unfortunately I am still seeing a zero-length content in the response. This time however, 500 is getting returned. Perhaps my initial root cause hypothesis was incorrect?

For good measure, I have copied the libcurl logs below. Please let me know how else I might help teasing out the issue. Note, in light of the "Forbidden" error, I have munged "HTTP/2" in the output below:

Code: Select all

curl>
GET /captcha/read_captcha.php?0.42054906036091033 HTTP/<the number 2>
Host: projecteuler.net
user-agent: edbrowse/3.8.5
accept-encoding: deflate, gzip
referer: https://projecteuler.net/sign_in
cookie: PHPSESSID=648669cc6471c5b714455f53b1c92eb9
accept: text/html,application/xhtml+xml,*/*;q=0.8
accept-language: ja-jp

curl<
HTTP/2 500
date: Sat, 01 Oct 2022 01:59:53 GMT
content-type: text/html; charset=UTF-8
content text/html; charset=utf-8
content-length: 0
server: Apache
x-powered-by: PHP/8.1.2
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
no cache
pragma: no-cache
strict-transport-security: max-age=63072000; includeSubDomains
x-static-config: yes
x-guest-hostname: vps-cc63e9
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
referrer-policy: same-origin
content-security-policy: script-src 'self' https://cdn.jsdelivr.net/gh/highlightjs/ https://cdn.jsdelivr.net/npm/mathjax@3/ https://polyfill.io/v3/;style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net/gh/highlightjs/ https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.4/css/all.min.css;
permissions-policy: geolocation=(), microphone=(), camera=()
x-cdn-cache-status: MISS
x-via: NRT1

[euler]

I am still not sure what is happening with you receiving those forbidden errors?!

I think I might have found the problem with my latest changes not working. The JavaScript file that adds event listeners to clicking the "Read audio for CAPTCHA" and allowing visitors to press the space bar in the confirmation code box to read the CAPTCHA was also trying to add an event listener to the image (allowing visitors to click it to create a new image). But if the image is not present, then the JavaScript would fail. I've made a couple of changes to the JavaScript file to only add that event listener if the image is present. Let me know if that resolves your problem.

[aepaegayah]

I posted about it on the other thread, but the "Forbidden" error seems to be happening whenever a post contains a string that looks like an HTTP request's first line:
viewtopic.php?p=64923#p64923

---

Still seeing 500 responses. Trying to boil this down to the bare minimum, can we test the request-response flow without any Javascript? From the CLI, I am seeing the same 500 with this flow:

Code: Select all

$ curl -vLo /dev/null 'https://projecteuler.net/sign_in'
...
set-cookie: PHPSESSID=<id>; path=/; secure; HttpOnly; SameSite=Lax
...
$ cookie='PHPSESSID=<id>'
$ curl -vLo /dev/null --cookie "$cookie" 'https://projecteuler.net/captcha/read_captcha.php?0.7633826107002479'
...
< HTTP/2 500
...

[euler]

I think I've just spotted the error. Could you try again?

[aepaegayah]

Progress! A code successfully plays from edbrowse.

However, it keeps telling me that the code I enter is incorrect. It seems like the code is re-generated at every request, so maybe there's an "off by one" issue when the code get re-initialized upon requests to the read captcha url?

If possible, it would be nice to have the ability to play the audio more than once, anyway, since it's sometimes hard for users to hold a 5-digit number in their head after a single hearing.

[euler]

That's good to hear that there has been progress.

I'm not quite sure why that is happening. At the moment, when the page is loaded for image compliant browsers, the JavaScript triggers to load the image and in doing so, the CAPTCHA value is stored in the session. Calling the read_captcha.php script will read that value. Repeatedly calling that function will read the same 5-digit number. However, if the session variable for the CAPTCHA value is not detected by the read_captcha.php script, then it will generate a session variable, but it will not generate a new one if the script is called a second time. In contrast, each time the image script is called a new value is generated.

So as long as you don't trigger the show_captcha.php file at any point, then the 5-digit number will not change when the read_captcha.php script is called. The only other way it will change is when the session expires. Calling the read_captcha script then will result in no session variable being detected and a new value will be generated.

With regards to the reading the image again. If the space bar is pressed in the confirmation code box, the JavaScript will call the read_captcha.php file, allowing the code to be read as often as needed.

[aepaegayah]

Okay. This turned last issue turned out to be user error. Doh!
The way I was attempting to play the audio was simply dropping the cookie every time.

Thank you for working with us to get this working!

Now that I've logged in successfully. Funnily enough, I'm unable to sign out! The Sign Out button appears to not actually be a button? Will have to investigate.

[euler]

I'm really happy to hear that the reading CAPTCHA is working properly now.

Regarding the signing out button, it is a form control. In this instance it is a clickable image. The reason is to stop a cheap cross site request forgery exploit that could have someone being served a link on another site like projecteuler.net/sign_out. The same protection is in place on other critical action elements throughout the site. They contain a reference to a unique token that is generated on each page view and must match a corresponding session variable. Generally these will be form images or form submit buttons. The submit buttons are styled to look like links.

Are there any ARIA attributes or something equivalent that I could add to these to make it clearer to screen readers?

[aepaegayah]

Okay. That makes a lot of sense. Thank you for the explanation.
I will discuss this with the other edbrowse devs and see what we can do.