[Javascript] JavaScript to PHP variable transfer

Fri Aug 22 12:01:20 CDT 2003

Here's *A* solution:

1.  Build a client-server app using a 15 year old language like VB
2.  Train some monkeys to input data using this new app
3.  Require the user to make transactions through a phone call to the
pool of data entry monkeys

This new solution guarantees that the interface will be fully robust and
feature rich while being within response time requirements, the operator
monkeys provide low initial and ongoing cost as well as a high ROI, and
the phone system has far less evil hackers waiting to steal transactions
than the big bad internet.

Overall, I think this "solution" will be easier to implement.  <g>

-----Original Message-----
From: javascript-bounces at LaTech.edu
[mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
Sent: Friday, August 22, 2003 11:50 AM
To: [JavaScript List]
Subject: Re: [Javascript] JavaScript to PHP variable transfer

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
>
>

_______________________________________________
Javascript mailing list
Javascript at LaTech.edu
https://lists.LaTech.edu/mailman/listinfo/javascript