TextArea Max length

[djr33]

Yeah... i had the same feeling as you at first, then realized that everything you can do you should in case someone thought they got around it and that was final.

[mwinter]

True, but it should be as secure as possible because someone might get around it, assuming that's ok, then send more "important" information that will just get chopped off serverside.

In that instance, though, the code server-side would be at fault. Silently truncating input, which seems to be your implication, is very bad behaviour. Excess data should be considered an error, rejected, and returned to the user for editing.

Mike

[djr33]

If there is no error check sending the data back to them (something that's basically excess coding and stupid... they shouldn't get too much data... it's the person's fault for adding more in there), it should just be clear in the first place that they can't have more. It's an entire page (or mode of a page) less to code.
Yes, people can fake the system, but it might just be someone who is, yes, "cheating" but aside from that is quite innocent. We're not talking about security here... this is just to save time for those who read the submission or whatever.

[mwinter]

If there is no error check sending the data back to them (something that's basically excess coding and stupid... they shouldn't get too much data... it's the person's fault for adding more in there), it should just be clear in the first place that they can't have more. It's an entire page (or mode of a page) less to code.

If I understand that correctly, you're suggesting that the check I just suggested shouldn't be done, apparently because it's more work for the author than you consider necessary.

Is that assessment correct?

Mike

[djr33]

I'm not saying it shouldn't be, and, in fact, think it should.
However, if someone gets around the system, then it doesn't seem like its the designers job to spend a long time writing up an error page just to help the people who are trying to hack their script.
But... if it can be done, sure, go ahead and add that. But what does checking first with JS hurt?

And, either way, it makes sense to just limit with JS as much as possible before sending to the php to check and/or clip the message.
Right?

Ok, let me put it this way:
If all you need to do is check with php, what's the point of this script at all. It's totally worthless and should just be replaced with "Maximum length for this is 40 characters.", then, when submitted, if it's longer than 40, the user will be sent back.
Right?
//sarcasm.
But... seriously, if it's not worth making the script as strong as possible, then it's not worth having it, really. It's designed to show the visitor a live render of what will be submitted, not submit then get a "too long, please rewrite" response.

[Twey]

However, if someone gets around the system, then it doesn't seem like its the designers job to spend a long time writing up an error page just to help the people who are trying to hack their script.

And non-JS users?

[djr33]

True.

But then you are just again supporting the reasoning for not having the script at all.

If you have the script, then it should work as well as possible.

That's like saying you shouldn't run for president because some people might not like you.
Or, better yet, you shouldn't do a good job as president because some people might not like you.

I mean... the script, though not perfect, should function as well as possible for what it does, right?

[mwinter]

However, if someone gets around the system, then it doesn't seem like its the designers job to spend a long time writing up an error page just to help the people who are trying to hack their script.

It's the developer's job to write robust programs. It doesn't matter why the error occurs, it should be dealt with sensibly. Moreover, as error messages should be meaningful to the average user, not state dumps (that's right, printing MySQL error messages and exit()ing is a bad thing to do), it won't help malicious users.

But then you are just again supporting the reasoning for not having the script at all.

Not at all. Yes, the server-side check must always be present, and it must be prepared to serve data back to the user for correction, but that doesn't negate the value of client-side validation.

In the majority of cases, client-side code will be executed, as least with regard to form validation. For trivial mistakes, there is no need for the user to wait for a full request/response exchange with the server; the user obtains immediate feedback regarding the data supplied. It may not be possible to validate all of the information client-side, but what can be will be done rapidly. Not only does this lower the load on the server - in most cases, it will only have to deal with complex errors, not the trivial as well - it lowers bandwidth usage for the user, too.

Mike

[djr33]

I don't disagree, but the client side script should be as powerful as possible.

If there's no effort to make it so, then what is the point in making the effort to add it to the page.

Bottom line-- make it work as well as possible. then, check server side.

[Rockonmetal]

wouldn't the tag inside of the textarea tag maxlength="whatever" prevent more than the max length?