81–90 of 145 posts
Why would you have a maxlength on password in the first place?!
It's common in practice even if it shouldn't be. Also many bcrypt implementations truncate input longer than 72 characters.
Now how can we reclaim `onpaste` events? If I'm in an input box and paste text, are there any legit use cases of _blocking_ paste of text in text entry fields?
Earlier quoted context omitted.
>Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this. You don't even need to use "the proper form validation API". It's as simple as changing your ajax call from an onclick (on the submit button) to an onsubmit (on the form).
Agreed. Though, as a developer, I like to extend the submission actions a little bit to make error messages fit in with the rest of the site and maybe suggest what to do in order to correct the input (e.g. remove letters from phone numbers, pick a better password, etc.) I do consider using the HTML5 form validation to be the proper validation API. Browser can do a lot without javascript and relying on their default b…
Earlier quoted context omitted.
You haven't answered the question. > Lest a user submit a 50,000 character password? What's wrong with that?
You should be doing some fairly expensive hashing if you're storing the password correctly. Maybe not an issue for a 50k char password, but how about a 50 billion char password?
Exactly. You aren't storing those bytes.
> Maybe not an issue for a 50k char password, but how about a 50 billion char password?
We're back to a place where the response to the question is another question, but it just ends up failing to give an answer, opting to just keep throwing out larger and larger numbers. My response: "Yeah, okay. How about it?" Why stop at 50 billion? 99 trillion, let's go there next. Again: why not?
Because 50 billion chars is over 46 GiB of data. There are natural consequences of very large payloads and limits that you're going to reach as a result of those consequences (e.g. being prohibitively expensive for the client to send in the first place, or it will max out the server's connectivity lifetimes for extant requests before the payload can be delivered). If "CPU utilization crosses threshold" is the real reason, then let that be the real reason—and let the safeguards you have in place for handling those problems do their jobs. And if "we cap passwords to X chars" is your safeguard, then you have bigger problems.
From the WHATWG/W3C definitions of the maxlength attribute: > Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the code-unit length of the element’s value is greater than the element’s maximum allowed value length, then the element is suffering from being too long. > User agen…
Arguably truncating the text is against the specification as it only specifies that the user agent may prevent the user from going beyond the max-length, not that it may do arbitrary stuff to make the text fit. I also hope it will make at least some developers realise that client-side validation is a bad idea.
Big if, of course, but a man can dream...
Earlier quoted context omitted.
Agreed. Though, as a developer, I like to extend the submission actions a little bit to make error messages fit in with the rest of the site and maybe suggest what to do in order to correct the input (e.g. remove letters from phone numbers, pick a better password, etc.) I do consider using the HTML5 form validation to be the proper validation API. Browser can do a lot without javascript and relying on their default b…
You can do a lot with setCustomValidity to improve error messages while still using the rest of the HTML5 validation API.
I do think that people generally overlook the built-in form validation though, and I like to use them as a fallback for Javascriptless environments to ensure everyone can get proper validation.
Earlier quoted context omitted.
I have used password-store (pass) to generate passwords and paste them to forms without realizing they were truncated and simultaneously those sites don't have the same maxlength on their login form.
Ah. On first read, I assumed you meant you had a webapp which was broken by these changes.
This is a welcome change, but what would make it even more awesome is a little red bar at the last character that fits into the maxlength. A semi-common thing I do is paste a long thing of text into an exerpt text area, let it truncate to maxlength and manually tweak the ending. A little red bar to tell me where it would've gotten truncated would make that still possible, while fixing the dangerous behavior with trun…
Or even better, some kind of warning when the paste happens, giving the user the option of truncating, canceling or continuing anyway?