[albatross-users] Authentication/Login example for RandomModules

Sheila King sheila at thinkspot.net
Thu May 22 19:11:41 EST 2003


OK, I have finally got a working example (rudimentary/proof-of-concept type 
of thing) of using RandomModularSessionFileApp for an authentication login 
type of system.

Example has four possible pages:
login
myaccount
logout
expired

where the login page has the possibility of displaying error messages also.

Upon successful login, session is initiated and is valid for up to five 
minutes of inactivity.

Successful login takes you to the 'myaccount' page.

Because it is a random modular app, it is possible to go directly to any of 
the pages with a specific URL. However, I've made it so that valid sessions 
redirect to the myaccount page, regardless of the URL.

If you log out or allow the session to expire, attempts to access the 
myaccount page by URL take you to a "session expired" page.

To maintain a valid session for as long as you like (prevent it from 
expiring) just keep reloading the myaccount page or revisiting the login 
page (which will redirect to myaccount if session is still valid).

I have a live example here:
http://www.mathxy.com/cgi-bin/authex/myapp.py

a valid username/password is guest/guest

I'll leave it up for a little while.

Code, in zipped format, is available here:
<http://mathxy.com/authex/auth_examp.zip>

and all the files for the project are in .txt format in that same 
directory.
http://mathxy.com/authex/

(If anyone wants my debug version, with all my inane debugging statements 
that print out to a file, tracing all through the execution path...you can 
ask in private email.)

I would welcome commentary and review of the code.

I'm still not pleased with the 301 codes returned by the redirect 
statements, but I will think about how to deal with that later. I really 
don't like returning a code that says something "moved permanently" when 
nothing of the sort has happened.

In Message-ID: <m3k7clud8i.fsf at ferret.object-craft.com.au> Dave Cole 
<djc at object-craft.com.au> wrote:

> What might make more sense is to do something like this in every page
> module.  Place all of the application logic in the display function.
> Let a common module check the state of the session and have it force
> global behaviour if necessary.

> Something as simple as this should do the trick.

>   import myapp

>   def page_display(ctx):
>       if myapp.check_session(ctx):
>           ctx.run_template('this-page-template.html')

> Then in the myapp module you just need to something like.

>   def check_session(ctx):
>       if ctx.locals._user:
>           return 1
>       if ctx.req_equals('login'):
>           if user_is_valid(ctx.locals.user, ctx.locals.passwd):
>               ctx.locals._user = ctx.locals.user
>               ctx.add_session_vars('_user')
>               return 1
>       ctx.run_template('login.html')
>       return 0

Actually, what I found to work best for me was the following:

Put the code for testing validity and possible redirection in 
page_process() and then put the display only in page_display(). One of the 
things that had me tearing my hair out, was that when I initially put 
validation tests and redirects in page_display, it would not redirect to 
the new page. That's because (I believe) it was already at the point where 
it was displaying the page. Too late to redirect. FWIW, this is also the 
method used for the Random Page example in section 4.8 of the 
documentation. Just took me a while to get it all sorted out (was having 
trouble with my logic process on authentication methods at the same time).

In Message-ID: <m3k7clp6e6.fsf at ferret.object-craft.com.au> Dave Cole 
<djc at object-craft.com.au> wrote:

> Sheila> the docs. Although the comment information is presented
> Sheila> elsewhere in the manual, cross-correlating is quite a chore
> Sheila> for the newbie attempting to just familiarize themselves with
> Sheila> and use the package.

> You are not alone in finding the manual less than helpful as a
> reference.  I have been (slowly) working on improving this.

Not at all. I think the manual is impressive. RoundUp and Albatross are 
some of the most well-documented free software projects I've seen. 
Actually, even compared to commercial software. In fact, that is one of the 
reasons I selected Albatross to work with. (Not that there isn't room for 
improvement.)

I think that for some people, reading docs isn't enough, and you actually 
need to toss it back and forth with someone else a few times for it to 
"gel". At least, that sure helps me!

Dave continues, in the same message:

> If you have any suggestions about improving the manual, now is the
> time to tell me.  I cannot guarantee that I will be able to fix
> everything, but some things will be possible.

One thing that I would find helpful: consider alphabetizing the lists of 
functions/attributes in the places where the manual lists them all out for 
a particular class or module. In some of the diagrams I had to scan the 
list three times to convince myself that a certain function wasn't part of 
that class, as opposed to me just not seeing it there.

Figure 8.16 is mislabled. i.e. the "caption" is incorrect.

The manual would benefit from more examples of Random Page apps. You are 
welcome to use my example, or adapt it, if you think it would be useful.

If I think of anything else, I'll let you know.

By the way, I'm sure I will still be around. I hope I haven't worn out my 
welcome or used up my quota of questions. ;)

-- 
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org




More information about the Albatross-users mailing list