[Twisted-web] HTTP-AUTH for web2 / Kudos on web2's operation

[Clark C. Evans]

On Thu, Nov 17, 2005 at 08:17:25AM -0500, glyph at divmod.com wrote:
| On Wed, 16 Nov 2005 11:11:49 -0500, James Y Knight <foom at fuhm.net> wrote:
| > I think of something like parsing user authentication information at a 
| > high level up in the resource tree and making it available to a  
| > Resource low in the tree.

Must we assume that resources form a Tree?  Mine form a Graph; I have
many resources which can be entered in any number of contexts with 
different "parent" resources.   Viewed this way, the resources which
a _request_ has passed through forms a stack; but it isn't a tree.  

| >It is fairly clearly a per-request bit of  
| >state which may be useful to a some subset of the pages, and as such  
| >seems like it should be attached to the Request. Just going and  adding 
| >random attributes onto Request is not nice thing to do, so  I'll pretend 
| >I didn't just consider it. But it really seems like some  designated 
| >storage spot for extra data is necessary.

Currently, it is my application; and I modify the request object to
my heart's content.  It may seem dangerous, but I've yet to hit a 
single bug from this usage.

| Abstractly: if you have a page which requires some "per-request state" to 
| be set by a resource higher up in the tree, and can't operate without it, 
| how do you guarantee it's been set?  Can we come up with any declarative 
| interface for specifying this relationship?  I've never seen one and it 
| seems like it would be insanely hard to do. 

Each of my Resources 'assert' pre- and post- conditions.  If the assertion
fails, I get a nice internal server error and a stack trace.  What more
could a programmer want ;)

| Concretely: come to think of it I've never heard of a legitimate 
| requirement other than "currently logged in user", which ought to be 
| handled by another system anyway. 

See my previous email.  My resources go through many stages of
processing and are heavily modified by the time I'm ready to
generate a Response.

| Though I missed the conversation, I imagine the handwavy stuff that JP 
| was suggesting was "the top resource, which is a proxy for the user, 
| should pass information down to its children as it creates them".  Some 
| kind of explicit relationship is required.

This statement, I don't get at all.  As I understand it, a resource
processes more than one request; and hence, will be associated with
more than one user.

| I'll here backpedal just a tiny bit on my earlier adamance on getSession 
| and say that perhaps there is a valid use for access to the currently 
| logged-in user as request data.  By "currently logged-in user" I mean 
| "'topmost' resource object".

Sorry, I'm lost.   Are you saying that:
  
    (a) An Avatar is a "auto-generated" resource perhaps constructed
        from the SessionManager resource?

    (b) Each Request object would have a 'stack' of 'previous-resources'
        that it has visited?  And that I could ask for the 'Avatar'
        resource in that 'stack' via a method on the request object?

If so, it sounds more complicated than plain-old getSession().  Perhaps
I just don't understand what problems you've had with getSession?

| Sketch of an interface:
| 
| Site resources call Request.setSiteResource() in locateChild - this 
| method takes no arguments, and preserves the current URL being processed 
| as well as the current resource.
| 
| Regular resources can, at any time, call Request.getSiteResource() or 
| Request.getSiteURL() which return, respectively, the last resource to 
| call setSiteResource() and a nevow.url-style object that indicates its 
| location.

Ok.  That's very nice.   Just remove the word 'Resource' and you're all
set; just let it be a regular object.

    request.setSite(myobject that complies with ISite)

| I still think that this sort of interface should be used sparingly, but 
| it has several advantages over the context as manifested in Nevow.
| 
| - The relationship between objects which require implicit state and 
| objects which provide it is more explicit.  They must both be resources, 
| one calls setSiteResource, one calls getSiteResource.
| 
| - By default, no site resource is set, so you must always implement both 
| halves of the interface.  In other words, this is entirely a facility for 
| an application to communicate with itself, no framework code should ever 
| provide a site resource, and no framework code should ever expect to find 
| anything useful from the site resource.

This similar system would work with Session then?

   request.setSession( my ISession object )
   
| - All information required by a given application must be encapsulated by 
| the single top-level resource.  No piecemeal assembling of required 
| information from 5 different interfaces set by 5 different systems during 
| resource traversal.  If you need information from a different system, the 
| top-level resource can aggregate it using traditional means (methods 
| returning different objects, attributes, adaptation, etc)

Ok.  This is where I get confused.  The top level resource can handle
multiple requests.  I think you're just referring to one's application
data?  Perhaps...

   request.setAppData(an IAppData object)
  
where IAppData is any old object that the application wants.
  
| - All information is specifically "per HTTP request" rather than "per 
| abstract transaction execution" - Nevow (or other templating / page 
| generating mechanisms used with web2) can be expected to do any necessary 
| translations at render time and not abuse the same mechanism used by the 
| dispatch mechanism.

A big problem with my current codebase is that I don't have the 
notion of a Transaction.  I need one.  My back-end system has the
notion of 'Actions'.  Typically, you have one Action per Request,
but sometimes you have more than one Action per request and 
they need to all succeed or all fail.   

In my system, each Action has its own URL, and is essentially its own
mini Request, only that the "parent" request aggregates the results.


| - By providing a URL as well as a site object, sub-applications can 
| properly link to resources defined by the application.  I'm sure that 
| most people will ignore that and link directly to / most of the time, but 
| at least it is the kind of issue which *can* be resolved by using this 
| interface.
|
| - As I mentioned previously, error messages can be more detailed, since 
| they will indicate what type the current site resource is, and thereby 
| provide the developer some indication of how the offending resource got 
| where it is.  Furthermore the URL can also be used to aid in error 
| reporting, so the developer can tell "where" the path traversal went 
| wrong.  If we want to push the error reporting even harder, we can have 
| an explicit 'interface' argument which has to be passed to both 
| setSiteResource and getSiteResource, used for nothing but matching up to 
| make sure that the implicit state matches the application's expectations.

Sorry; I don't get this one -- do you mind explaining a bit more?

Best,

Clark