Re: Proof of concept structs for 2.0

[Adam Thompson <..hidden..>]

Chris Travers wrote:
> LedgerSMB::Web::Request is designed specifically to provide HTTP
> wrappers for workflow scripts.  Thick clients wouldn't use it.

I'm not sure this is really the best way to handle workflow - what about 
workflow in the non-web (CLI, thick client, etc.) scenario?  OTOH, I 
don't have any better suggestions right now.  For that matter, I'm not 
even sure that the workflow concept (à la LSMB) is valid in non-web cases.

> In 2.0, I see the anti-XSRF functions still tied to the session, but
> since the emphasis would be on allowing the same session framework to
> be useful across thick and web clients (for example, having long batch
> payment processes allow "locking" of transactions to a session on a
> thick client without preventing most other operations).  There might
> be other ways of doing this with advisory locks and thick clients but
> it might be simpler not to reinvent the wheel.

Interesting... I'm accustomed to simply using transaction isolation 
levels to accomplish this.  Since Pg defaults to READ COMMITTED, 
wouldn't converting the affected SQL to use ...FOR UPDATE solve the same 
problem?  I get that batch runs typically can't all be run inside a 
single transaction, but I think in almost all cases I've worked around 
that by using some sort of checkpointing scheme, even at the expense of 
performance.  Horrid memories of Clipper apps permanently locking files 
that could never be unlocked probably causes this bias.

> However, since session handles some things beyond web
> interfaces, and this is web-interface-specific, I figured it shoudl be
> broken off.

That rationale seems sound.

> First, ideally the authentication mechanism for a given installation
> should be admin-defined.  For example, if you use HTTP_KRB5, you
> really don't want users confused if they get authentication prompts so
> it would be rather concerning if this were to change.

That's my point - if a user switched auth methods in the middle of a 
session, I would assume that was an attack of some sort, not a valid 
sequence of events.

> struct LedgerSMB::Session, {
>      id     =>  '$',
>      token  =>  '$',
>      dbclient =>  '$', # Pg type inet, connection of client connecting to Pg
>      type =>  '$', #type of session (web, etc)
>      auth_module =>  '$', #name of auth module
> };
> This could be subclassed for web interfaces by also adding a remote_addr field:
> struct LedgerSMB::Session::Web, {

That makes more sense to me, seems more obvious and more likely to help 
ensure correctness of implementation.  A change in auth_module would 
thus represent a new session altogether - which is sane IMHO, as an 
attack in that mode would be indistinguishable from an administrative 
configuration change or simply a valid connection from another web 
instance or another type of client.

--
-Adam Thompson
 <..hidden..>
 (204) 291-7950