[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