With 2FA enabled, when the user types in their token with a space, we should automatically remove that before verifying the code.
As per:
https://twitter.com/simoncozens/status/1021743003344535552
Tidy 2FA code before verification: Pixipea suggested automatically removing spaces from 2FA codes before verification, citing a tweet from Simon Cozens. maja pointed out that the current maxlength="6" attribute would prevent codes with spaces from being entered. However, Pixipea noted that this wasn’t an issue when setting up 2FA, and suggested making the input field numeric-only. maja confirmed that the maxlength limit was only in place for the login input field, not the 2FA setup field. The issue has since been fixed in a GitHub commit by maja.
With 2FA enabled, when the user types in their token with a space, we should automatically remove that before verifying the code.
As per:
https://twitter.com/simoncozens/status/1021743003344535552
We have a limit for how many characters can be entered into the input field and with additional spaces the 2FA code doesn’t fit (which makes it obvious that only numbers should be entered). Should the maxlength="6" attribute of the input field really be loosened to allow any number of spaces the user might want to add?
Perhaps this is just a problem when putting the 2FA code into the enable field, when first setting up 2FA.
Admittedly I am viewing this from more of a plebeian angle, but when I entered my 2FA code from Google Authenticator, which looks like this ### ###, I had no problems entering all 6 characters with the space in between.
Shouldn’t the maxlength=“6” have prevented this?
Maybe change the field input site to be numeric only?
does any of this make sense?
It should indeed, I only checked the input field which is part of login, looks like the other one which is part of enabling 2FA doesn’t have a limit in place. Will change that ![]()
Fixed while ago in:
https://github.com/discourse/discourse/commit/e8d82f48bca79bcb531d769cda4ed6a24e321bbe