On Wed, 16 Nov 2005 13:48:12 -0500, "Clark C. Evans" <[EMAIL PROTECTED]> wrote:
We had a chat on IRC today, and a few random notes/ideas emerged:
a) There was a strong preference to keep Session and Authentication
completely separate. Currently Nevow's Guard mixes the two and
thus is overly complicated and non-modular. Nevow also uses
Componentized, which is depreciated (in favor of... ?)
http://divmod.org/trac/browser/trunk/Nevow/nevow/guard.py
http://divmod.org/trac/browser/import/Nevow/sandbox/mg/guarded/guard.py
I'm not sure what "completely separate" means in this context. I don't think I
agree, although I'm not sure about the specifics of the implementation. I do think that
there should be no public session-management API divorced from authentication though.
The use of getSession() is a mistake in every single case where it's used,
except those in guard itself. What resource you're viewing should implicitly
represent what session you are talking to. The whole idea of a session is
entirely internal state that should not be exposed to the user. What it
amounts to is a rewrite of Python's argument-passing convention, used to pass
stuff in an implicit, out-of-band way that's hard to document and impossible to
test for. All the discussion of Componentized and Context and all these other
objects that are pretty much just different names for a free-form dictionary
are indications that session-management == encapsulation violation, if it's
exposed to the user.
Every session is associated with a user. The representation of the session is
the top of the resource tree. If you need to persist information about the
session, your resource tree should be pointed at a persistence system of some
kind. Perhaps the session manager should have better/more explicit support for
simultaneous distinct sessions; in the case of anonymous sessions that would
certainly be helpful.
As JP stipulated, this all *must* go through cred. A separate session
interface is unacceptable. It is already hard enough managing the insanity of
HTTP in a multi-protocol server.
I am aware that this is not how "most" appservers do things. However, "most" appservers
also spawn hundreds of threads, and operate by putting conditional structures in a special-purpose scripting
language into templates. Add "exposed session interface" to the list of common design mistakes :).
All that said, I don't think that your requirements are wrong, and I do think
that the implementation specifics of the Nevow session initiation
implementation are pretty bad, and they are mostly my fault.
c) Exarkun expressed a strong (ok, mandatory) preference for the
use of tw.cred in any Authentication solution. However, it was
noted that tw.cred does not allow for challenge-response
authentication mechanisms (which all of mine are). Specific
examples were noted: twisted.protocols.sip, SASL, OTP
Hmm. How did you get this idea? Cred's design was specifically to facilitate
challenge-response authentication. That's why login() takes credentials and
returns a Deferred. The assumption is that the credentials object will
encapsulate whatever facets of the user's connection are required to do the
negotiation process.
Again, this may be a place that Nevow's current session-initialization strategy
falls down; IIRC it wouldn't allow for that Deferred to be fired by multiple
different web-page hits, since it is a Deferred which is expected to itself
return a Resource. That's a limitation of guard though, not cred.
d) There was talk that the Session manager should actually be
a filter on the Response object; so that it can rewite paths
and/or inject cookies as needed before the response is sent.
This seems a bit complicated, no?
Seems so to me. Then again, the implementation specifics of the session
manager are often pretty horrible. This is another major reason that I think
that the API for sessions should be kept as far away from the user as possible.
e) I can probalby help in some ways, but I'm not a Twisted expert.
I could continue to collect requirements and post; but I have
short term deadlines (as usual). If you wish I could put two
files in twisted.web2, marked 'experimental':
session.py This would contain session manager, how ever
it is eventually implemented.
guard.py This would contain the gule to link tw.cred
to web2.
web2 is itself experimental, and you are taking a risk by doing work with
short-term deadlines on something unfinished. Keep in mind that if these files
are determined to be a bad idea later, they may be removed without warning and
without regard for your project or deadlines. You may want to work in a branch
to provide yourself (and your employer) with some guarantee of stability.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
