form validation

[ken]

I am trying to validate a form with the following code but the code is not
working like I wish. How can I check to see that if status=closed then a
date is entered in the cloaseddate field. Also if a date is entered in the
closeddate field then the status= closed

Thanks
Ken

<script>
if(document.Form1.Status.value=="Closed" &&
document.Form1.Closeddate.value=="") {
window.alert ("Please Enter a Closed Date!");
return false;
}
if(document.Form1.closeddate.value<>"" &&
document.Form1.Status.value<>"Closed") {
window.alert ("Please change the status to Closed!");
return false;
}
</script>

 

[Rudi Ahlers]

Relating to this question, and stop me if I'm wrong, but isn't it better to
address form validation from the server side, in this case ASP, than from
the client side?
What if the user's browser is Links / LYNX / Nokia browser / WebTV / some
other funny browser that doesn't support all the JAVA, or even any JAVA at
all?
Or rather, what if the user is paranoid and turned it off totally? Wouldn't
it be better to then see if the necessary fields are filled in, and if it
should be number (phone / fax / id number / bank account) that it's only
numbers and of the correct length?

--

Kind Regards
Rudi Ahlers
+27 (82) 926 1689

Greater love has no one than this, that he lay down his life for his friends
(John 15:13).

I am trying to validate a form with the following code but the code is not
working like I wish. How can I check to see that if status=closed then a
date is entered in the cloaseddate field. Also if a date is entered in the
closeddate field then the status= closed

Wrong group. This is a JavaScript question, not an ASP question. You will
get better results in a JavaScript group.

Regards,
Peter Foti

 

[Bob Barrows [MVP]]

Relating to this question, and stop me if I'm wrong, but isn't it
better to address form validation from the server side, in this case
ASP, than from the client side?
What if the user's browser is Links / LYNX / Nokia browser / WebTV /
some other funny browser that doesn't support all the JAVA, or even
any JAVA at all?
Or rather, what if the user is paranoid and turned it off totally?
Wouldn't it be better to then see if the necessary fields are filled
in, and if it should be number (phone / fax / id number / bank
account) that it's only numbers and of the correct length?

Actually, both client and server-side validation should be done if possible.

Client-side validation is good because it avoids extra trips to the server
just to find out, for example, that a number field had alpha characters
entered into it.

Server-side validation must be done because hackers have been known to
submit data to server-side code without using our well-thought-out data
entry forms. Also, as you say, browser capability may prevent the
client-side code from running.

Bob Barrows

 

[CJM]

Actually, both client and server-side validation should be done if possible.

Client-side validation is good because it avoids extra trips to the server
just to find out, for example, that a number field had alpha characters
entered into it.

Server-side validation must be done because hackers have been known to
submit data to server-side code without using our well-thought-out data
entry forms. Also, as you say, browser capability may prevent the
client-side code from running.

Ditto.

I have a client-side validation script (js) which cuts out most of the crap
at source, but then again most of my apps are intranet apps so I have this
freedom. For internet sites, I tend to use server-side validation for
obvious reasons.

I like the 'hackers have been know to...' bit! The two simplest and most
common ways of hacking a site are using SQL-injection and by manipulating
QueryStrings. So the I have another (server-side) script that filters
certain naughty characters out of the user input. I also try to hide errors
if I can, and display my error msg, rather that one from the server that
might reveal more than I would like to to.

Then once all this is done you then have to figure out not only if the user
input is valid but that it actually makes sense. Often, with my users this
is not the case!

CJM

 

[Rudi Ahlers]

how do hackers make use of SQL-injection strings? and how would one avoid
this scenario?

--

Kind Regards
Rudi Ahlers
+27 (82) 926 1689

Greater love has no one than this, that he lay down his life for his friends
(John 15:13).

Actually, both client and server-side validation should be done if possible.

Client-side validation is good because it avoids extra trips to the server
just to find out, for example, that a number field had alpha characters
entered into it.

Server-side validation must be done because hackers have been known to
submit data to server-side code without using our well-thought-out data
entry forms. Also, as you say, browser capability may prevent the
client-side code from running.

Ditto.

I have a client-side validation script (js) which cuts out most of the crap
at source, but then again most of my apps are intranet apps so I have this
freedom. For internet sites, I tend to use server-side validation for
obvious reasons.

I like the 'hackers have been know to...' bit! The two simplest and most
common ways of hacking a site are using SQL-injection and by manipulating
QueryStrings. So the I have another (server-side) script that filters
certain naughty characters out of the user input. I also try to hide errors
if I can, and display my error msg, rather that one from the server that
might reveal more than I would like to to.

Then once all this is done you then have to figure out not only if the user
input is valid but that it actually makes sense. Often, with my users this
is not the case!

CJM

 

[Bob Barrows [MVP]]

how do hackers make use of SQL-injection strings? and how would one
avoid this scenario?

See the SQL Injection FAQ at www.sqlsecurity.com
There is also a more-detailed white paper on the subject at:
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf


Bottom-line: SQL Injection depends on the use of dynamic sql. If you avoid
dynamic sql and use stored procedures with parameters and don't use dynamic
sql to execute them, then you will not be vulnerable to SQL Injection.

Bob Barrows