[Javascript] JavaScript to PHP variable transfer

[David Lovering]

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

----- Original Message ----- 
From: "Chris Tifer" <christ at saeweb.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Friday, August 22, 2003 5:39 AM
Subject: Re: [Javascript] JavaScript to PHP variable transfer


> If you strictly want this for session variables, why are cookies not an
> option again? And what could possibly be needed on the server if they've
> turned off all functionality as you've implied.
>
> I still do not get the gist of this project you're working on at all. It's
> just a bunch of vague talk about how hundreds of form elements must stay
the
> same and you can't do anything with them on the server.  Sounds more like
a
> quiz to me and one of us has to come up with the best theoretical
> scenario...
>
> Chris Tifer
> http://emailajoke.com
>
>
>
>
>
>
> ----- Original Message ----- 
> From: "David Lovering" <dlovering at gazos.com>
> To: "[JavaScript List]" <javascript at LaTech.edu>
> Sent: Thursday, August 21, 2003 4:42 PM
> Subject: Re: [Javascript] JavaScript to PHP variable transfer
>
>
> > Legacy issue -- fist-fights are even now being fought on that point.
Good
> > call!
> >
> > Yep.  I've put on the table "wish-list" items for the next generation -- 
> but
> > for now,
> > the show is driven by pushing the status-quo forward.  I'd like to see
> > one-time-use
> > session-id variables (encrypted by MD5 or better), force-scrubbed
> > immediately after use,
> > and running on top of a hardware-expedited IPSECv2 pipe to do all of
this.
> > Now if
> > Santa Claus can only come through...
> >
> > -- Dave Lovering
> >
> > ----- Original Message ----- 
> > From: "Mike Dougherty" <mdougherty at pbp.com>
> > To: "'[JavaScript List]'" <javascript at LaTech.edu>
> > Sent: Thursday, August 21, 2003 12:32 PM
> > Subject: RE: [Javascript] JavaScript to PHP variable transfer
> >
> >
> > > You're running the webserver on the same box as the SQL server?
> > >
> > > I would think that would be the first problem to convince the customer
> > > to focus on :)
> > >
> > > >That is precisely the point -- we want the server to spend its spare
> > > CPU
> > > >cycles resolving big gnarly SQL queries, and not doing big gnarly
forms
> > > >transfers -- particularly if 80% of the form isn't applicable to
> > > generating
> > > >the necessary SQL queries.  This may cause many additional small
> > > sessions of
> > > >variable transfers, but it also generates lots and lots of "idle"
time
> > > >between output dumps while the queries are in process.  Anyhow, the
> > > most
> > > >annoying constraints were set in stone by the customer, and I have to
> > > play
> > > >along however I can.  Frankly, I wish YOU were my customer -- your
> > > viewpoint
> > > >is much like mine was prior to this project.
> > >
> > >
> > > It also sounds like the customer is being a bit extreme (and
potentially
> > > misguided) about "security" and the ideal usage of bandwidth.  By the
> > > time you build a sufficiently clever mechanism for working in the
> > > specifications they've given you, they will have spent enough that
they
> > > could have thrown hardware and bandwidth at this problem until a far
> > > less clever developer could maintain it.  I'm guessing you can't bring
> > > this up, but would it be worth it to discuss a more flexible
> > > configuration for basic assumptions to start with?
> > >
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>