I would, and have for one project, set-up a DBIC family/schema exactly as normal and related in the various DBIC (and Authn/Authz Cat) docs; MyApp::Schema::User, MyApp::Schema::Role, and MyApp::Schema::UserRole. And then you just add a method to the user class. E.g. (semi-tested):
# In MyApp::Schema::Class =item B<has_role> Takes a role object, an id, or a name. =cut sub has_role : method { my $self = shift; my $role = shift || return; if ( blessed $role ) { return first { $role->id == $_->id } $self->roles; } elsif ( $role =~ /\A\d+\z/ ) { return first { $role == $_->id } $self->roles; } else { return first { $role eq $_->name } $self->roles; } return; }
I don't think that the snippet above relies on this but I find it handy for the the Role to stringify to its name instead of its id.
# in MyApp::Schema::Role use overload '""' => sub { return +shift->name; }, fallback => 1;
Then you can-
if ( $user->has_role("admin") ) { # authorized for admin stuff... }
Remember, the whole point of the MyApp::Schema class in Cat apps is to have schema code that is not married to Catalyst. So any of the examples along those lines are fine for a non-Cat application.
Update: I would do this with the modern namespacing. It allows for much more complex behavior while keeping the code quite clean.
MyApp::Schema::Result::User MyApp::Schema::Result::Role MyApp::Schema::Result::UserRole
In reply to Re: Simple Authorization?
by Your Mother
in thread Simple Authorization?
by pileofrogs
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |