[Bug]: Page scaling causes verification to fail
Nooreenzentso opened this issue · 3 comments
Bug report requirements
- I have confirmed that this is a bug and not a configuration/user error.
- I have searched for existing issues and confirmed that my issue has not been reported before.
IconCaptcha version
latest
ASP.NET version
ASP.NET Core 6.0
Browsers affected
Google Chrome, Microsoft Edge
Expectation
When I select the icon that appears least with my browser's zoom at 67%, I expect the verification to succeed
Actual behaviour
Verification fails, receiving the "UH OH. You've selected the wrong image." message.
Relevant log information
icon-captcha.min.js:2
POST http://localhost:5000/iconcaptcha 500 (Internal Server Error)
ajax @ icon-captcha.min.js:2
b @ icon-captcha.min.js:2
(anonymous) @ icon-captcha.min.js:2
setTimeout (async)
click @ icon-captcha.min.js:2Additional information
While I encounter this issue with IconCaptcha implemented in my own solution, the same behaviour is observed using the demo project from the "3.x develop" branch.
This issue also occurs for users with custom scaling on their computers (though I do not have exact scaling settings to share), but is reproduceable when setting the browser zoom to 67%. This occurs specifically when the captcha is loaded with the browser at this zoom; if the browser zoom is at any other setting when the captcha is loaded, then the zoom is changed to 67% and the correct image is selected, the verification is completed successfully.
Hi! Thanks for the report. I'll investigate this further and will inform you once I have an update.
After some investigating, it appears that when setting the browser to 67%, the image width sent to the server for validation is no longer an integer. An integer value (usually a width of 320) is expected, but at this scale, the image width read by JS turns into 319.992. As the server expects an integer and not a float/double, this will thrown an exception. The same issue appears to occurs in the PHP version of IconCaptcha.
I will fix this in the 3x-develop branch so that this no longer occurs once that version is ready.
Hi! I forgot to post a comment last week, but this issue has been resolved in the 3.x-develop branch.