Lan Barnes wrote:
FRONT END <--> MIDDLEWARE <--> BACK END
Middleware is business rules, processing, magic. I don't care where it
lives, but likely it'll be on the back end server or its own server
where I can:
And? I never suggested otherwise.
Javascript has its uses in UI. At no point did I suggest it should go
further than that.
Now we all tend to want to push the middleware to one end or the other,
because writing the extra interfaces is a pain, and the temptation is to
push it to the front end BUT THIS SHOULD BE RESISTED (raise a chant:
"Thin client, thin client ..."). Integrity checking and data massaging
DO NOT belong in the front end and required fields should NEVER be
enforced in the form. Send your data over to the server and let the
server either fix it up or send back a scolding message.
The AJAX stuff allows you to send the data up to the server, get it
processed, and get a response without making a full rerender of the web
page. Looks like a thin client to me ...
So now you're telling me that I'll miss javascript because without it, I
can't do cool processing on my client. Hmm ... is Andrew telling me that
I should not just want a FAT client, but an obese client, a client with
its waistline flowing over its belt? No thank you.
You might want to go back and reread what I said. I never said the
client should do processing. All of my examples were about the UI.
"But," you say, "the whole reason for thin clients is to avoid the
hassle of continuously redistributing updates and supporting a variety
of versions. And javascript on a browser gives you a universal platform
on which your server can call for nifty client actions, kinda like
inter-machine call-backs."
GAH! A universal platform? Who said that? I sure didn't.
In fact, I gave you an example to the contrary. Javascript is often
used to work around CSS implementation bugs *just to get your static web
page to render correctly*.
And is there, perchance, a tiny security issue
in letting unknown people run stuff on your machine?
Absolutely.
However, the reverse is also true. Allowing external people to toggle
the state of your server is a tiny security issue, too. And hacking the
state on the server is generally far more enticing than any state on the
client.
But what really scratches Lan's itches are the Application Direct URLs,
which basically means, hit this URL, trigger this back-end action.
You just lost the moral high ground on security, right there. Sorry.
Application Direct URLs with state are a *HUGE* security nightmare.
There have been *lots* of exploits where someone figured out, spoofed or
intercepted an "active" URL like you propose to open an entire server.
I'm not going to argue that AJAX magically makes security easier.
However, your proposal certainly does not help, either.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
