Mark Hedges wrote:
On Mon, 29 Dec 2008, David Ihnen wrote:
Though that is, of course, specific to the application
being programmed, utilizing client-side javascript active
stuff rather than particular web server programming to
transparently handle it on the server side using basic
html2.0 type structure.
I have to agree with others that a whole proxying layer to
allow it seems... excessive.
I don't know who's recommending a proxying layer or who's
agreeing with you... are you aware of how OpenID works or
what it is?
I think that any system that stores a post for later retrieval on a
separate request is, indeed, proxying that request for later use in a
different situation. Thus, to program your system to hold onto a form
put/post amounts to inserting a proxy-delay-for-authentication for that
action - even if semantically you want to say its not a proxy because
its not a separate application/codebase. I admit to introducing the
term proxy here without explaining why I consider the concept to be proxy.
Yes, I am aware of how OpenID works. And it works in-band unless the
application explicitly sidelines it - there is no inherent side-band
communication that the client and server will use - otherwise, you
wouldn't EVER do a main state redirect. The moment you have to redirect
to that openid server page, you have sidelined the entire stream of
browser-server communication - and as you have found in the problem
you're trying to solve - the state inherent therein, including the
content of the original request. Is the utilization of the stored form
data going to be through a different connection/request entirely after
authentication verification? Would require some tests to see if the
client behaves that way or not. I suspect its not defined to be one way
or the other, but I may be wrong.
Did you understand that the Apache2::Controller framework is
intended to be a general application framework, and should
not require you to implement pages in a certain way?
Not explicitly, but implicitly I would expect that, yes.
Is the controller framework going to require me to depend my web system
operations on some sort of semi-persistent pan-server correlated session
state system? Would that not be requiring me to implement my web
application in a particular way? Okay, that may indeed be the role of a
framework though I'd no doubt chafe at the limitations myself. If I
have to write my web application a certain way, is it so unusual to have
my pages need to interact with that application a certain way? They're
almost inevitably closely coupled.
This is a fairly sticky issue - if you have run out of local
authentication token, its impolite to drop data they were submitting.
But on the other hand, there's no particularly good way of *not*
dropping it - you can't really handle information if they're not
authenticated for it. And out of pure defensive network traffic
handling, we do the absolute minimum for people who aren't authenticated
- so they can't consume our system resources, be that
posts-to-sessions-that-don't-exist or what. I can see programming the
client side of the web application to handle this kind of
token-loss-recovery automatically - the client has the form state and
being able to recover the session state is valuable, and entirely
independent from the framework utilized. But I'm not convinced that the
web server should be jumping through hoops/proxies to make it happen.
(not that you have to convince me, I'm trying to present a perspective
that may be novel and generally be helpful in improving your software,
and we may just disagree on the role of the software involved)
David
