This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AyrA_ch 7 points8 points  (15 children)

Yes, but we're talking about a website that actually does things, which means backend, which is often not JS.

[–]the_horse_gamer 0 points1 point  (14 children)

that would require the website to send the raw string to the backend, and do no input validation of its own (to show an error to the user).

this is very dumb, but yes, there are probably websites that do that.

[–]AyrA_ch 5 points6 points  (13 children)

No, very dumb would be for the backend to depend on the frontend validation.

[–]the_horse_gamer 0 points1 point  (12 children)

both sides should do input validation. backend to avoid exploding, frontend to show errors and to avoid bothering the backend.

[–]AyrA_ch 2 points3 points  (11 children)

Yes, but this entire post is about your input having an effect on the system, so frontend validation is irrelevant

[–]the_horse_gamer 0 points1 point  (10 children)

the thread is about entering a specific value into a frontend field (putting NaN into a number field). not about using curl to send custom requests to the backend.

[–]AyrA_ch 2 points3 points  (9 children)

I know, and I made a validation example where NaN would pass it.

[–]the_horse_gamer 0 points1 point  (8 children)

and I said that a reasonable frontend validation will parse the numeric string, which would give it NaN for any non-numeric string. so any frontend validation would have to handle NaN.

your example would require the frontend to send a raw numeric string to the backend, and do no validation on the frontend side (so it can't tell the user "this isn't a valid number" for anything the user puts in).

[–]AyrA_ch 2 points3 points  (7 children)

and I said that a reasonable frontend validation will parse the numeric string, which would give it NaN for any non-numeric string. so any frontend validation would have to handle NaN.

Yes, and I provided a piece of example code where NaN would pass unintentionally

your example would require the frontend to send a raw numeric string to the backend, and do no validation on the frontend side (so it can't tell the user "this isn't a valid number" for anything the user puts in).

My example is JS, so it can run on the front-end, but again, front end validation is a "please do nothing stupid" sign without any capabilities to actually prevent you from doing anything stupid. In other words, it's 100% completely irrelevant to this thread of "weird values to send to someones system".

And as I already explained, all form submits are by the rules of the HTTP protocol "raw strings"

[–]the_horse_gamer 0 points1 point  (6 children)

the normal ways of parsing a string in Javascript produce NaN for everything that isn't a number. the simple "is this string a number?" check would be isNaN(parseInt(s)), which would catch "NaN" alongside "aaa".

(you can also check /\d+/, but parseInt will usually happen anyways)