> I like the interface you have described for your module. I would just
suggest
> instead of having the validate routine simply return true on success, have
it
> return the user's session data, or even a session object of some sort.
I've decided to mostly remove support for sessions from the module as it
stands, and instead include it in a different way. I did this because I want
the session functions the be available to all instances of a CGI::App and
not just in the CGI::App::Login module, read more to see what I did.
Based on the feedback that I've been getting, here's how the project
currently stands.
CGI::Application::Login (or so I will call it for ease of recognition ) is
an actual CGI::App with a setup function and several application functions,
many of which can be over-ridden. This app requires an instance script to
run properly and has some optional PARAMS{} that should be set for best
results ( including : cookie_name, session_dir, login_template,
success_url ). Additionally you can (obviously) set any other app params in
the instance script that you may require should you be overloading any of
the supplied functions. Currently what this app does is the following:
1. (optionally) prompt for input (although it makes no assumptions as to
what it is prompting for, just so long as the information is returned to the
instance script <form action="/cgi-bin/login.cgi">). you can specify a
template file to load, defaults to loading via html::template but the
login_screen() function can be overloaded.
2. Automatically validate the user and set a cookie ( name of cookie /
cookie properties depend on CGI::APP params you set in the instance script
( login.cgi ) ). Validate routine can be overloaded to allow you to make use
of the form fields in your login template ( see step 1. ) and check form
values against a database, internal hash, single password, etc. whatever you
choose. overloaded validate() routine should return true on success and
nothing on failure.
3. If the validation fails (this will only be the case if you override the
validation routine as the default validate function always returns true)
then the user is returned to the cgi::app param supplied login screen. if
the validation is a success, the module sets the cookie, and sends the user
to the cgi::app param supplied 'success' URL.
The way I am currently handling sessions is by creating a sub-class of
CGI::App that all my new app's use as base. The new super class (
CGI::App::Session ) has a couple of functions, read_session(),
write_session(), init_session() and session(). the session() function is the
exact same (borrowed code) as CGI::App's param() function. so saying
$self->session( 'access_level' => 'full' ); will set a session param.
So in response to Spencer's suggestion of having the validate() routine
return a hash instead of simple true / null, I've decided to keep with the
returning true / null, and additionally call $self->session( name =>
'value' ); for each session variable i want to set. Upon success,
CGI::App::Login will attempt to write the session file automatically, at
which point anything stored using $self->session() will be written to disk.
read_session() and write_session() can also be easily overloaded.
Here's the parts that are still a little messy.
a) all scripts must now use base CGI::App::Session instead of CGI::App.
b) main project apps need the following in the cgiapp_init() function
$self->param( 'session_dir' => '/dir/to/save/session/files' );
unless ( $self->init_session( 'name_of_cookie' ) )
{
$self->header_type('redirect');
$self->header_props( -location => 'http://location/of/login.cgi' );
return;
}
c) all main project apps need the following in the teardown() function
$self->write_session();
There's a couple of things I still find clunky about this interface. I don't
like saving session_dir as a CGI::App param, I'd rather have a better
interface ( maybe I should do something like tmpl_path() ). I don't like
having to specify $self->write_session() in the teardown. and I don't like
having to utilize a super class to make everything work.
I mean .. it's not that big of a deal for ME to make it work this way for my
own applications, but in terms of other people's ease of use I wonder what
you think about the current interface, and suggestions for improvements.
===
steve comrie :: senior developer
www.shrinkingplanet.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
