Dumb Newbie Question

Discussion in 'Javascript' started by Balance, Aug 27, 2003.

  1. Balance

    Balance Guest

    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.
    Balance, Aug 27, 2003
    #1
    1. Advertising

  2. Balance

    spaminator Guest

    Jim Dabell <> wrote in message news:<>...
    > 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, Aug 28, 2003
    #2
    1. Advertising

  3. Balance

    spaminator 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.
    spaminator, Aug 29, 2003
    #3
  4. Balance

    Svend Tofte Guest

    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
    Svend Tofte, Aug 29, 2003
    #4
  5. (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 -
    Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Aug 29, 2003
    #5
  6. (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 -
    Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Aug 29, 2003
    #6
  7. Balance

    spaminator 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

    > > 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
    spaminator, Aug 29, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John

    Dumb newbie question

    John, Mar 8, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    352
    Kevin Spencer
    Mar 8, 2006
  2. Mike Pence
    Replies:
    2
    Views:
    95
    Edward Faulkner
    Sep 28, 2005
  3. Steckly, Ron
    Replies:
    2
    Views:
    87
    Tim Hunter
    Dec 8, 2007
  4. Marc Wilson

    Dumb newbie question- object references

    Marc Wilson, Nov 25, 2003, in forum: Javascript
    Replies:
    4
    Views:
    129
    Marc Wilson
    Nov 26, 2003
  5. Jerry C.
    Replies:
    8
    Views:
    223
    Uri Guttman
    Nov 23, 2003
Loading...

Share This Page