NYCPHP Meetup

NYPHP.org

[nycphp-talk] JavaScript List?

Kyle Tuskey ktuskey at exostream.com
Fri Jul 19 19:15:31 EDT 2002


A strictly JS authentication system is a BAD idea.  There are several
ways to get around it.  If you are going to use JS to authenticate data
it should only be to save the user or your servers stress.  There should
be always be server side checking as well... well unless you really
don't give a.



Kyle




-----Original Message-----
From: Edgar Reyes [mailto:ereyes at totalcreations.com] 
Sent: Friday, July 19, 2002 11:36 AM
To: NYPHP Talk
Subject: Re: [nycphp-talk] JavaScript List?

First of all you can download the HTML and do what ever you want with
it,
but unless you have FTP access to that server you will not be able to
submit
that page and even if you change the action on the form, with in all my
scripts I check where the page is coming from and if is not from my
domain
is not going to be executed.  Lets just face it there are many ways of
doing
things if you don't like to use JavaScript to save time and resources
that's
your purgative, but I've been doing it for years and it works fine for
me
and my clients, and some of my clients do well over $100,000 a month  on
there sites.

Just one more opinion.

----- Original Message -----
From: "Analysis & Solutions" <danielc at analysisandsolutions.com>
To: "NYPHP Talk" <talk at nyphp.org>
Sent: Friday, July 19, 2002 11:01 AM
Subject: Re: [nycphp-talk] JavaScript List?


> Hi Jim:
>
> On Fri, Jul 19, 2002 at 10:44:12AM -0400, Jim Hendricks wrote:
> > > You still need to do validation on the server anyway, so now
you're
> > > maintaining two code bases.
> >
> > I disagree.  If there is a validation to be done on the client, I do
it
> > there, no form
> > processing will allow submit without the data having been validated.
>
> So, what's keeping me from saving your HTML to disk, editing it to
remove
> the Java'sCrap validation, refreshing, entering bogus data that'll
mess up
> your system into the reworked form and then submitting the form?
> Nothing.  Even if you do referrer checking, I can forge that.  In
short,
> if you want security, data must be validated on the server.
First of you can download the HTML and do what ever you want with it,
but
unless you have FTP access to that server you will not be able to submit
that page and even if you change the action on the form, with in all my
scripts I check where the page is coming from and if is not from my
domain
is not going to be executed.  Lets just face it there are many ways of
doing
things if you don't like to use Javascript to save time and resources
thats
your poragative, but I've been doing it for years and it works fine for
me
and my clients in which we do well over $100,000 a month  I think it
work.

Just my opinion.



>
> > > Then, if the user has Java'sCrap turned off or not present, are
they
even
> > > able to submit your form.  I've seen plenty of forms that won't.
> >
> > Haven't had a user complain yet, and I own my own software dev
company
in
> > which we have produced a number of web apps that use javascript.
>
> Perhaps because they figure it's not worth doing business with such a
> firm.  I certainly don't.
>
>
> > > But they all fall flat on their face when JS is off/unavailable,
making
> > > your site unusable.
> >
> > True, but if the client wants to get rid of the page redraw &
associated
> > delay
> > during validation, then you WILL do JS and let the client know that
the
app
> > will not work with JS turned off.
>
> Nope.  If a firm doesn't trust my professional judgement, we're not
meant
> to be doing business together.
>
> --Dan
>
> --
>                PHP classes that make web design easier
>         SQL Solution  |   Layout Solution   |  Form Solution
>     sqlsolution.info  | layoutsolution.info |  formsolution.info
>  T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
>  4015 7 Av #4AJ, Brooklyn NY     v: 718-854-0335     f: 718-854-0409
>
>
>






More information about the talk mailing list