Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

fxsitecompat.dev

Post reply on HN
Print view View original

61–70 of 145 posts

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#61

Post by tambre »

Someone1234 wrote: post #17
JakeWesorick wrote: post #12

Earlier quoted context omitted.

It's important to use form elements for accessibility even if your submitting another way. Also at least for me its a lot better to use the built in form validation then creating your own. https://dev.to/addyosmani/accessibility-tips-for-web-develop...

Your link doesn't support your statement, or even attempt to. Screen readers have no concept of elements, nor do they differentiate on what happens behind the curtain when a button is pressed (e.g. aJax Vs. submit). If you have an article that does explain your argument, please link it. > Also at least for me its a lot better to use the built in form validation then creating your own. This change removes that very va…

>This change removes that very validation.

How? The form can't be submitted until it's fixed.

>The form cannot be submitted until the user fixes the error [...]. The user will typically see a red border around the text field along with a validation message [...]

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#63

Post by gruez »

jeroenhd wrote: post #29
Someone1234 wrote: post #10

> The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text or password (a server-side validation has to be put in place anyway.) However, this could potentially affect a front-end implementation if it expects the entered text never to exceed maxlength. What century are Mozilla living in? Most, even simple forms, don't use elements and submit buttons anymore…

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. If you use the proper HTML API for gathering data properly, you're most likely not affected badly functionality wise; only your UI will be affected because the form will refuse to be posted without proper explanation. If the change really does get byp…

>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).

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#64

Post by danaliv »

remus wrote: post #53
cxr wrote: post #49

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?

This is a backend concern, not a frontend one. The backend shouldn’t naively accept input without making sure the input is within the backend’s limitations.

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#65

Post by danaliv »

at_a_remove wrote: post #56
nikanj wrote: post #15

Why would you have a maxlength on password in the first place?!

Because someone would inevitably try to submit a four megabyte password, or an eight gigabyte password, or whatever.

Limit request size and/or time at the HTTP server, and validate input on the backend.

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#66

Post by gbear605 »

rkagerer wrote: post #43

Highlights from the bug report[1][2]: - HTML spec allows it; says MAY, not MUST [3] - Affects only user pastes, not javascript edits - Affects all input boxes, not just password ones - New preference editor.truncate_user_pastes can restore old behavior As a developer, I personally find the inconsistent behavior of maxLength unintuitive and am surprised a potentially-breaking change like this didn't have more discussi…

As someone whose user agent is Firefox, I’d rather that maxLength didn’t exist at all, and given that it does, my user agent ignoring that seems like the best solution to me.

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#68

Post by oefrha »

danaliv wrote: post #64
remus wrote: post #53

Earlier quoted context omitted.

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?

This is a backend concern, not a frontend one. The backend shouldn’t naively accept input without making sure the input is within the backend’s limitations.

Client side validation does not replace server side validation, and vice versa. Just because you validate server side doesn’t mean you can’t also do it client side and avoid a round trip.

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#70

Post by franga2000 »

rubyn00bie wrote: post #55
Wowfunhappy wrote: post #35

Earlier quoted context omitted.

...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?

Nope. Not reasonable, and likely of no benefit to anyone. That'd be like 50kb... assuming it doesn't cause your hashing algorithm to take a shit causing breakage. 50kb to on one request, sitting pretty much at rest 99.9% of the time, is nothing to even bother with. Most folks should probably spend more time worry about optimizing their own payloads instead of their users [1]. [1] To that point, most people want to sp…

Not allowing a 50k char password is entirely reasonable. For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). That's already ridiculous. Some sites also check passwords for dumb things like taking the username and doing 1337-type substitutions, which would (if implemented badly) take even longer.

More importantly though, a 50k character password is barely more secure than a 20 character one, but it gives the user a false sense of security. Passwords are inherently flawed and we shouldn't kid ourselves that just making them longer makes a difference.

If you're in a situation that calls for a 2^400 keyspace, you probably shouldn't be using passwords anyways.

Post reply on HN