Printable View
Hi , I have found bug in textarea maxlength code.
The steps to reproduce the bug.
1) Copy some text from anywhere.
2) Right click in the text area and paste it.
3) Note, you will have text area with more than 10 chars.
http://www.dynamicdrive.com/dynamici.../maxlength.htm
There are ways to hack this.
I think, though, that the point is simply to limit people and make it CLEAR that you have a limit of 10 or 30 or whatever.
After that, it's up to the form interpretation page to cut it off at 10 or 30, etc, for security, just in case someone did decide to get around this.
with enough messing around, you can type a couple extra characters too.
OR just turn off javascript in your browser.
It's not secure, but it's clear that you can't have more than that.
About your specific point---
yes, you can paste into it.
if you type after that, though, it removes the excess... typing causes it to render.
I think one way to make it slightly better would be to add an "onBlur" command to the text field like this:
<textarea maxlength="40" onkeyup="return ismaxlength(this)" onBlur="return ismaxlength(this)"></textarea>
I think this is very much worth adding to the script, actually.
onBlur is the opposite of onFocus... meaning when you click out of the text box, it will check if its too long. So... there's no way to submit this with it being too long. Except turning off javascript.
Also... might work to do it if you clicked directly on the submit button from the textarea, but I think that would count as "blur".
IE supports 'onPaste' event but other browsers don't. So I think onblur is good option.
I'd say go ahead and add onPaste as well, then... doesn't hurt.
the problem, though, is that this is a bunch for people who are using to script to add to each textarea... the idea is to be userfriendly.
I'm not incredibly well versed in JS.... is there a way to simplify the code?
Like this, or something:
onkeyup;onBlur;onPaste=""
???
I used onPaste ="return false". I am not allowing user to paste anything.
<textarea name="txtMessage" onPaste="return false" onblur="validate()" >
function validate()
{
var msg,mainMsg;
msg="";mainMsg="";
msg=document.frmMessage.txtMessage.value;
mainMsg=msg.substring(0,10);
document.frmMessage.txtMessage.value=mainMsg;
}
wish we had something like textArea_changed
hmm... yeah.
onChange? Heh. Probly not though. That works for dropdowns, anyway.
On good idea you had, though, is to use "validate" as the function.
Why not just use a single letter... saves some space.
onblur="a()", etc etc. Heh.
Edit: onChange info:
http://www.devguru.com/Technologies/.../textarea.html
Not exactly what is wanted, but maybe helpful. Slightly better than onBlur if nothing else.Quote:
onChange Event handler
This event handler executes some specified JavaScript code on the occurrence of a change event (when the Textarea object loses focus and its value has altered).
If you intend to limit entry lengths, do so in response to the change and submit events:Quote:
Originally Posted by javascripter
Code:var maximumLength = 40;
function checkLength(control, maximum) {
var length = control.value.length;
if (length > maximum) {
alert('Please limit your message to ' + maximumLength
+ ' characters. There are currently ' + length + '.');
return false;
}
return true;
}
function validate(form) {
var controls = form.elements;
if (!checkLength(controls.textArea, maximumLength))
return false;
return true;
}
MikeHTML Code:<form action="..." onsubmit="return validate(this);">
<!-- ... -->
<textarea ... onchange="checkLength(this, maximumLength);"></textarea>
<!-- ... -->
</form>
This script is client-side validation; it's never going to be secure. There's no real point getting upset if someone can paste something into it and override the limits, because it's a simple matter to step around the validation anyway.
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. Ouch. Heh.
Good point. Fair 'nuff.
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.
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.Quote:
Originally Posted by djr33
Mike
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.
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.Quote:
Originally Posted by djr33
Is that assessment correct?
Mike
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.
And non-JS users?Quote:
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.
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?
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.Quote:
Originally Posted by djr33
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.Quote:
But then you are just again supporting the reasoning for not having the script at all.
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
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.
wouldn't the tag inside of the textarea tag maxlength="whatever" prevent more than the max length?
Heaven forbid HTML simply recognized maxlength within a textarea!!!Quote:
Originally Posted by javascripter