[albatross-users] login integration challenges again

[Michael C. Neel]

This is of cource my preference, but I don't think doing authencation
inside of albatross is the way to go.  Rather wrap the auth code around
the albatross app.  Since I'm using mod_python, this is farily easy - I
just define a auth handler for apache.  If the auth handler fails, the
content handler (albatross) is never called.

I don't think this would be too much trouble in a cgi app; just before
you start up the albatross code, preform the needed login/premisson
checks.

Once we passed the auth code, I pass into the albatross request object
any auth data it might need, like such:

myReq = Request(req)
myReq.username = username
return app.run(myReq)

and then access these members though ctx.request (i.e.
ctx.request.username).

I've found this to work well no matter the auth scheme (http-auth,
cookie, even referer).  

Mike

> -----Original Message-----
> From: Eric S. Johansson [mailto:esj at harvee.org] 
> Sent: Wednesday, September 24, 2003 2:09 PM
> To: albatross-users
> Subject: [albatross-users] login integration challenges again
> 
> 
> I started trying to integrate the login code into one of my 
> applications and I 
> discovered a few things that show me it is time to learn more 
> about albatross.
> 
> The working model for albatross use was the single file for 
> all methods and 
> functions plus the glue code for activating albatross.  The 
> working model broke 
> out the code in the following fashion:
> 
> Includes
> independent functions
> classes
> albatross glue class with methods
>        page_enter
>        page_process
>        page_display
> and last, glue code
> instance of SimpleApp
> register page (binding glue class to albatross)
> then run (request())
> 
> Granted, many of the features around the glue code still 
> escape me and I take 
> the simpleminded view that page_enter is used to create 
> initial values, 
> page_process is used to perform work based on a button push 
> and set up data for 
> use during page_display.  Page_display is used for any 
> calculations necessary 
> for page display independent of whether or not page 
> page_display has run.
> 
> Adding login semantics to this style of coding doesn't work 
> well.  For example, 
> page_enter would use some form of login object instantiation 
> and then storing 
> that object as part of context.locals.  Next during 
> page_process the first thing 
> one must do is validate that someone is logged in and a token 
> is valid.  If not 
> control passes to a login page, potentially preserving the 
> current state of the 
> submit.  Same thing is true for page_display because someone 
> may just access the 
> page for data display.  Unfortunately, I do not remember if 
> page_process 
> executes every time you access the page or not.
> 
> Conceptually, the big problem is the redirecting control to a 
> login page and 
> then picking up again from where you left off.
> 
> So, is there any way to embed my login capabilities into 
> albatross so that I can 
> minimize the amount of work a user needs to remember to do in 
> order to get 
> authentication working with their application?  Ideally, the 
> most they should 
> have to do would be to define a login authentication instance 
> in the page_enter 
> section and everything else should happen automatically and invisibly.
> 
> I don't think I'm too far off base on usability model, I just 
> need to know how 
> to integrate with albatross better (I think)
> 
> Suggestions?  Ideas?
> 
> ---eric
> 
> 
> _______________________________________________
> Albatross-users mailing list
> Albatross-users at object-craft.com.au
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat
ross-users