I know that while you should be doing proper validation on the server side
and everything, you could somewhat diminish the risk of someone building
their own form and just posting. If you were to check the referring site
which made the post then you could be pretty sure someone didn't make their
own form. Although this too is insecure, since all you need is a Firefox
extension, firebug or grease monkey which let you execute JavaScript could
let you change the page however you want while it's live, the refer would be
proper, etc. What I'm really saying is there is NO secure way to validate
client side, none, absolutely none.
Check that the date coming in is a valid date then create a date object with
it, that way even if they somehow do slip past your date validation then the
object just won't be created correctly.
There's lots to validate.
- Dan
""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message
news:7dd2dc0b0711020841h1d569a76mced0fc441cf6da68@xxxxxxxxxxxxxxxxx
On 11/2/07, Stut <stuttle@xxxxxxxxx> wrote:
Dan Shirah wrote:
> That is correct, the due_date field should only accept a valid date
format,
> such as MM/DD/YYYY. To bypass the need for a validation check for this
> field I simply set the text field to disabled and supplied the user
> with
a
> javascript popup calendar that upon selection populates the date in the
> format I want. :)
Client-side limits are not an effective defense against dangerous
inputs. Server-side validation is a must regardless of any client-side
checking that goes on.
this is an excellent point; consider the scenario where someone posts
directly
to your page, bypasing the client side checks. this is a trival
technique;
inspect the form attributes; determine the submission url and the
submission
method. look at the name attributes of inputs on the page; and then build
a
simple
form that posts those inputs to the same url with the same method.
-nathan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
