[Javascript] JavaScript to PHP variable transfer

[John Warner]

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
>