[Catalyst] Authentication and architecture

Yuval Kogman nothingmuch at woobling.org
Mon Dec 19 20:29:28 CET 2005


On Mon, Dec 19, 2005 at 19:46:47 +0100, Jon Molin wrote:
> Hi list,
> 
> I just started testing Catalyst, TT and Class::DBI yesterday. I've only used
> (Apache::)DBI, (Apache::)CGI and similar 'classic' modules prior when
> working with perl, so this way of thinking is all new to me. I've got a site
> I've been wanting to do for some time and figured I could use it to learn
> about this stuff.
> 
> I figured it'd suit me best to put all the logic in the ::C:: modules and
> only handle plain db stuff in the ::M:: classes. From looking at the
> documentation (and the 'best practices') I figured Authentication::CDBI,
> Authentication, Session, Session::State Session::Store where the modules I
> wanted to help me out with it.

You've found Catalyst in a somewhat transitional period. We've just
finished rewriting authentication and session handling, so you might
hit some old stuff (like Authentication::CDBI).

Both the new session plugin and the new authentication plugin are
pluggable themselves- they tie together several backends.

For example, if you want to use sessions you load the session
plugin, and then you load the store plugin for the backend you want
(Session::Store::DBI, Session::Store::FastMmap, etc - but not
Session::Store itself which is just a base class), and the state
plugin - like Session::State::Cookie.

Then the Session plugin will use Session::State::Cookie and
Session::Store::FastMmap to manage the session automatically.

Authentication is similar:

	use Catalyst qw/
		-Debug

		Session
		Session::Store::FastMmap
		Session::State::Cookie

		Authentication
		Authentication::Store::DBIC
		Authentication::Credential::Password
	/;

This is probably what you wanted. It means that you'll be using
Cache::FastMmap to store the session data, cookies to maintain the
session state across requests, DBIx::Class or Class::DBI to store
users in a database table, and login/password to verify the users.

> My plan was to have /, /login and /register
> accessible to all and let my ::C::Member module handle all sessions, account
> creation/modifications and logins/logouts.

( Are you using an up to date version of Catalyst? Please double
check. )

	package MyApp::Controller::Member;

	sub login : Global {
		my ( $self, $c ) = @_;

		$c->login; # should be enough if you use standard form
		# parameters... See
		# Catalyst::Plugin::Authentication::Credential::Password's
		# documenation

		$c->stash->{template} = 'login.tt'; # displays login
		# successful [% IF c.user_exists %], failed otherwise
	}


> Using thoose modules in Member
> and let it have the subs needed; store_session_data etc. That doesn't seems
> to work at all though, it seems as I must use all plugins in the 'main'
> module and therefor also have the store_session... functions there as well?

This seems like a misunderstanding - these are provided by the
plugins you didn't use - see the above description.

> my $ok_paths = { '' => 1, 'user/login' => 1, 'user/register' => 1 };

I think you really want Catalyst::Plugin::Authorization::ACL. This
code should be enough to make the checks happen automatically:

	# deny access to everything unless a user is logged in
	__PACKAGE__->deny_access_unless( "/", sub { $_[0]->user_exists });

	# allow access to the permitted areas.
	# note that /member/login etc corresponds to the controller, not
	# the URI
	__PACKAGE__->allow_access_if( "/member", sub { 1 } )


> # taken from documentation:
> sub auto : Private {
>     my ($self, $c) = @_;
>     my $login_path = 'login';
>     # allow people to actually reach the login page!
>     if ($ok_paths->{$c->req->path}) {
>         return 1;
>     }

This is, as I said before, better handled using the ACL plugin.

>     if ( $c->req->user ) {
>       $c->session->{'authed_user'} =
>         MyApp::Module::MyAppDB::Member->retrieve(
>                              'username' => $c->req->user
>                              );

This is handled automatically by Catalyst::Plugin::Authentication's
on-by-default integration with Catalyst::Plugin::Session. 

>     }
>     else {
>      $c->res->redirect($c->req->base . $login_path);

	$c->res->redirect( $c->uri_for( $login_path ) );

but you can probably handle this better without redirects.

> ps the example 'Hops' you link to from your first page doesn't work, I dunno
> for how long it's been like that but I guess it'd be good to fix Hops or
> temporarily remove the link as it confuses

This is actually a very informative mail in general - you've really
helped us get some direction in terms of where our documentation
efforts should go in, how clearly we should document that things are
deprecated, and how to improve our error handling.

Thanks!

-- 
 ()  Yuval Kogman <nothingmuch at woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: /me sushi-spin-kicks : neeyah!!!!!!!!!!!!!!!!!!!!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20051219/546d450f/attachment-0001.pgp


More information about the Catalyst mailing list