Dumb Newbie Question

[Balance]

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.

 

[Guest]

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.

 

[Guest]

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]

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]

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]

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

 

[Guest]

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

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