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
<[email protected]>
(204) 291-7950
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
