Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)
-   -   Dumb Newbie Question (http://www.velocityreviews.com/forums/t871908-dumb-newbie-question.html)

Balance 08-27-2003 12:30 PM

Dumb Newbie Question
 
Is it possible to trigger a function to check entries on an HTML field when
the user leaves the field?

I suspect that it is but have not figured out how - but if it is, is it
possible to embed php into the javascript.

What I'm trying to do is something along the lines of an input screen for
clients and I want to check when a phone number is entered that the phone
number is not already in my database ie I'm not registering the same client
twice.

Unfortunately I've not the foggiest how to start so any help would be
greatly appreciated.

Thanks.



spaminator 08-28-2003 11:13 AM

Re: Dumb Newbie Question
 
Jim Dabell <jim-usenet@jimdabell.com> wrote in message news:<Mo2dnc9mEJDOU9GiRVn-jw@giganews.com>...
> Balance wrote:
>
> > Is it possible to trigger a function to check entries on an HTML field
> > when the user leaves the field?

>
> Use the onblur event.


onchange event validates when user leaves the fiels

> You need to validate your input on the server. Client-side scripting cannot
> be trusted.


Client-side scripting can be trusted if it is done right.

> There seems little point to adding Javascript to validate this
> when you need a round-trip to the server anyway.


I think the best way here is a mix. You validate some data on the
client some on the server. At the end of the day it all comes down to
design issues.

spaminator 08-29-2003 07:40 AM

Re: Dumb Newbie Question
 
> You are kidding, right? With every client-side function, variable, event
> handler, DOM element, etc. open to change by the user at any time there
> is nothing on the client-side that can be trusted. (If you think I am
> wrong you could try to provide a demonstration of a client-side script
> that can be trusted.).


Well i admit i could be wrong , but i am talking about my experience
here.

go to msn.com and follow the hotmail link.

I have noticed this side uses client side validation on the password
field and username field to prevent the user from submitting an empty
field etc. Can you explain to me why this is not to be trusted.

Svend Tofte 08-29-2003 10:44 AM

Re: Dumb Newbie Question
 
An old adage in security goes: You can't trust the client. Ever.

> Well i admit i could be wrong , but i am talking about my experience
> here.
>
> go to msn.com and follow the hotmail link.
>
> I have noticed this side uses client side validation on the password
> field and username field to prevent the user from submitting an empty
> field etc. Can you explain to me why this is not to be trusted.


*Svend turns of scripting

How much is that validation worth now? Plus, if IE had proper DOM tools, I
could probably be fancy about it, such as firing up a DOM editor like
program, and programmatically modify the contents of the value attribute of
the appropiate fields. Hell, if I don't want to turn of scripting (let's
assume the form won't submit then), I could enter JavaScript of my own
choice, into the URL field. Most browsers execute that code in the context
of the current page. And don't think "onchange" will save you, remember,
I'm scripting too, so I can just turn off/override all of your event
handlers. I can overwrite your form check, from:

function formCheck(this) {
//imagine normal form check script
}

into:

function formCheck(this) {
return true;
}

The list is endless. Much like trying to protect ones images on a webpage,
it's a futile fight. The client can not be trusted with anything, or be
trusted to deliver ANY correct input data. If you have been using this for
two years, I suggest you go and fix your wide open gaping security holes
you've left out there.

Regards,
Svend

Lasse Reichstein Nielsen 08-29-2003 10:50 AM

Re: Dumb Newbie Question
 
bruce_lee_978@hotmail.com (spaminator) writes:

> > > Client-side scripting can be trusted if it is done right.

>
> We have been doing it for 2 years now. it works fine.


That might just mean that you have not met anyone determined to ruin
your day. It is not a proof that nobody can. And they can, if you
actively use unverified user inputs on the server.

> Thats what we are doing. Saves us a lot of unnecessary traffic


Absolutely, and client side verification is very good at that. It just
won't stop people turning it off and sending malicious, unverified
values instead.

> The server handles any input , but if the data is not valid it needs
> to do a lot of prossesing to handle the errors that are generated.


So you have expensive error recovery for the cases where client-side
verification has failed instead of less expensive server-side
verification applied to all transactions.

That should work, and it shows that you have considered what happens for
illegal input. How you then handle it is a ressource tradeoff, and your
choice is definitly a valid one.

> This is all about design issues, some web based systems have a lot of
> customers and traffic and want to limit unnecessary traffic.


Then you are doing it the right way: Test on client to save time, but
test again on the server to be safe. Your test on the serverside is
just geared to be inexpensive when it succeedes and expensive when it
fails, instead of adding a flat overhead to all transactions, but it
is there.

This doesn't contradict the statement that client-side verification
cannot be trusted. If it could, you wouldn't need error handling code
on the server at all.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

Lasse Reichstein Nielsen 08-29-2003 10:53 AM

Re: Dumb Newbie Question
 
bruce_lee_978@hotmail.com (spaminator) writes:

> I have noticed this side uses client side validation on the password
> field and username field to prevent the user from submitting an empty
> field etc. Can you explain to me why this is not to be trusted.


Because I can turn Javascript off and send an empty password.
Because I can telnet to the server and craft my own request with no
limits on what I can do. Great for doing buffer overflows.

It's not that it doesn't work most of the time. It's just that the server
has to be prepared for the cases where its input wouldn't have been accepted
by the client verification. I.e., it must verify its input in some way.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

spaminator 08-29-2003 01:57 PM

Re: Dumb Newbie Question
 
> That might just mean that you have not met anyone determined to ruin
> your day. It is not a proof that nobody can. And they can, if you
> actively use unverified user inputs on the server.


We have a controller servlet which controlls the input /output in
addition to the client side scripting

> > Thats what we are doing. Saves us a lot of unnecessary traffic

>
> Absolutely, and client side verification is very good at that. It just
> won't stop people turning it off and sending malicious, unverified
> values instead.


We have a controller servlet which controlls the input /output in
addition to the client side scripting.

> So you have expensive error recovery for the cases where client-side
> verification has failed instead of less expensive server-side
> verification applied to all transactions.


Yes

> That should work, and it shows that you have considered what happens for
> illegal input. How you then handle it is a ressource tradeoff, and your
> choice is definitly a valid one.


Yes

> Then you are doing it the right way: Test on client to save time, but
> test again on the server to be safe.


We have a controller servlet which controlls the input /output in
addition to the client side scripting.

> Your test on the serverside is
> just geared to be inexpensive when it succeedes and expensive when it
> fails,


Why.

> This doesn't contradict the statement that client-side verification
> cannot be trusted.


I agree , you shouldent put all your money on client side validation

> If it could, you wouldn't need error handling code
> on the server at all.


How would you build this system and with which technology
How would you build a system for n clients with only server validation


All times are GMT. The time now is 09:54 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.