[Javascript] JavaScript to PHP variable transfer

[David Lovering]

Thanks guys!  It is wonderfully refreshing to hear folks agreeing with one's
own negative assessments of a situation like this, rather than the
customer's complaints about absurd performance issues.

-- Dave Lovering

----- Original Message ----- 
From: "John Warner" <john at jwarner.com>
To: "'[JavaScript List]'" <javascript at LaTech.edu>
Sent: Friday, August 22, 2003 1:19 PM
Subject: RE: [Javascript] JavaScript to PHP variable transfer


> Dave, let me second that, your client can't have it both ways.
>
> John Warner
> mailto:john at jwarner.com
>
> > -----Original Message-----
> > From: javascript-bounces at LaTech.edu
> > [mailto:javascript-bounces at LaTech.edu] On Behalf Of Roger Roelofs
> > Sent: Friday, August 22, 2003 2:19 PM
> > To: [JavaScript List]
> > Subject: Re: [Javascript] JavaScript to PHP variable transfer
> >
> >
> > Dave,
> >
> > Get a new client!  Seriously. I mean it!  User complaint 2
> > and security
> > recommendation 3 are mutually exclusive.  In order for any server to
> > maintain state info in a stateless protocol like http, it
> > must be able
> > to tag all relevant communication.  In the case of http, cookies, GET
> > data (like url query strings) and POST data are the only way to do
> > this.  PHP can either save the session id in a cookie, or as part of
> > the url.  The user requirement and security requirement removes both
> > options.
> >
> > On Friday, August 22, 2003, at 12:50  PM, David Lovering wrote:
> >
> > > Sigh.  I was hoping to save folks the pain --
> > >
> > > Apparently, some of the customer's staff objected to an earlier
> > > application
> > > which used all the conventional "forms" stuff to manage a telecom
> > > database
> > > program.  Their major complaints were (and I'm not kidding!):
> > >
> > >     (1)    They didn't like the screen flashing when the
> > forms updated
> > >     (2)    They didn't like the gobblety-gook (the URL &
> > variables) on
> > > the
> > > status and link bars
> > >     (3)    They wanted it to be faster (much, much faster)
> > >     (4)    The IT guys objected to the bandwidth being used
> > every time
> > > a
> > > form updated
> > >
> > > This was the state of things -- right up to the time that they got
> > > "hacked"
> > > (presumably through their web application, although nobody
> > has shown
> > > me a
> > > P.M. of the event). They called in some high-powered security
> > > consultant who
> > > said (and again, I'm not kidding!)
> > >
> > >     (1)    Disable all forms-related transfers
> > >     (2)    Only do transactions over SSLv3 (makes sense)
> > >     (3)    Don't use cookies on the client machines -- FOR
> > ANYTHING!!!
> > >
> > > The VP in charge of software development (who, in my
> > opinion shouldn't
> > > be in
> > > charge of shoelaces) agreed to all of these considerations, carte
> > > blanche.
> > >
> > > Now I have to rebuild the application (which merges bits of Remedy
> > > with bits
> > > of GoldMine) with both sets of constraints in mind -- however
> > > unpleasant and
> > > impossible they are.  I have ways of beating all of these,
> > but it is
> > > sort of
> > > like sucking spaghetti through a straw while standing on your head;
> > > messy,
> > > highly unorthodox, and very, very strange to see.  Having done a
> > > simple-minded scheduling and traffic analysis, it was
> > decided to dump
> > > Remedy
> > > and Goldmine altogether (security, speed, and a lousy user interface
> > > probably had a lot to do with that), and some prior bad experiences
> > > with
> > > Microsoft IIS servers moved everything over to Apache, with
> > a hardened
> > > enterprise server edition.  Having decided that transforming
> > > everything to a
> > > pure-Java environment would exceed the pain tolerance for initial
> > > applet
> > > down-load delays, the only bits left were PHP, JavaScript,
> > and whatever
> > > XML/DHTML fragments could continue to function in this lame
> > > environment.
> > > All this was before they brought me on board.
> > >
> > > Ugly, ain't it?
> > >
> > > -- Dave Lovering
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
> >
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>