On Tue, Jun 19, 2001 at 02:23:17PM -0700, Thomas McManus wrote:
> The form won't submit unless JavaScript is on and the validation
> conditions are met. To prevent user perversion, such as saving
> the form locally and editing out the validation - by changing it to
> a regular "Submit" type input or something - check the environment
> HTTP_REFERER to make sure it is coming from your domain
> ( m/^http\:\/\/www\.mydomain/) and bounce them if it isn't. Of
> course, there is no guarantee that JS will still be on two seconds
> after they submit the tested request, but hey, if they are trying to
> screw it up, so what? It will work okay for any user who isn't
> intentionally trying to monkey wrench it...T
I don't think it's really an issue of intent on the part of the user, but rather
general application design. Unless one can be absolutely sure that all of one's end
users will be viewing the app via IE or Netscape, using javascript for critical
functionalities is evil, bad, and wrong.
The idea of putting application logic on the client side is fine if you know in
advance the type of environment your users will be viewing your pages in (e.g., a
macintosh-specific site, or an intranet). However,I disagree whole-heartedly with
using anything flashier (no pun intended :) than HTML 3.2 for a public application.
Using client-dependant technologies like javascript or flash effectively exclude
certain segments of the user population.
In any case, using javascript should not be necessary for anything other than
presentational fluff. If the form validation is so sensitive that it cannot withstand
mistyped data or garbage, perhaps it should be revamped.
just $.02,
--john
>
>
> ----- Original Message -----
> From: "Christopher K. St. John" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 19, 2001 11:00 AM
> Subject: Re: JavaScript Enabled?
>
>
> > Deb Shuvabrata wrote:
> > >
> > > Consider a date validation on an HTML page.
> > >
> >
> > You can't depend on client-side validation. Since the users
> > have control of the client, the users can do any perverse
> > thing they want, and there's no way to always catch them.
> > So assume all the data coming from the client is trashed and
> > revalidate it on the server-side.
> >
> > > Is there any way I can find out from my ... if the request
> > > came from a JavaScript enabled browser or not.
> > >
> >
> > No. A malicious user can always fake it, see part 1. ('But
> > we don't have any malicious users' is not a good excuse,
> > since stupidity is often indistinguishable from malice :-)
> > Make sure to always validate on the server side, and you
> > don't have to worry about javascript being turned off...
> >
> >
> > --
> > Christopher St. John [EMAIL PROTECTED]
> > DistribuTopia http://www.distributopia.com
> >
> >
> ___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
