Jifty::Object(3pm) User Contributed Perl Documentation Jifty::Object(3pm)NAME
Jifty::Object - Base class for most of Jifty's objects
DESCRIPTION
"Jifty::Object" is the superclass of most of Jifty's objects. It is used to provide convenient accessors to important global objects like
the database handle or the logger object, while still allowing individual classes to overload these methods.
We ought to be able to mix-in "Jifty::Object" with any other class; thus, we will not define "new" or "_init" in "Jifty::Object". We do
assume, however, that $self is a blessed hash reference.
METHODS
current_user [USER]
Gets/sets a user for the current user for this object. You often do not need to call this explicitly; Jifty will inspect your caller's
"current_user", and so on up the call stack.
PRIVATE _get_current_user
Takes the ARGS paramhash passed to _init. Find the current user. First, try to see if it's explicit. After that, check the caller's
current_user. After that, look at Jifty->web->current_user
Fills in current_user with that value
log
Returns a Log::Log4perl logger object; the category of the logger is the same as the class of $self.
perl v5.14.2 2010-09-25 Jifty::Object(3pm)
Check Out this Related Man Page
Jifty::CurrentUser(3pm) User Contributed Perl Documentation Jifty::CurrentUser(3pm)NAME
Jifty::CurrentUser - Base class and basic implementation of current user object
DESCRIPTION
Most applications need to have a concept of who the current user is. So Jifty supports this concept internally. Every Jifty::Object (which
most things in Jifty are descended from) except the CurrentUser itself is instantiated with a Jifty::CurrentUser subclass as a parameter to
the creator.
This class describes (and implements a trivial version) of the access control API that a Jifty application needs to implement to provide
user-based access control
It's generally expected that your application will override this class if you want any sort of access control.
new
Creates a new Jifty::CurrentUser object. Calls _init, an app-specific initialization routine.
If you call it with the "_bootstrap" argument, Jifty will set the user up as a bootstrap user, who's usually allowed to do just about
anything without any access control
_init
Applications should override this method to provide any application-specific user loading code. The built-in
If you do nothing, code similar to this will be called by _init.
sub _init {
my $self = shift;
my %args = (@_);
if (keys %args and UNIVERSAL::can(Jifty->app_class('Model', 'User'), 'new')) {
$self->user_object(Jifty->app_class('Model', 'User')->new(current_user => $self));
$self->user_object->load_by_cols(%args);
}
return 1;
}
That is, it will attempt to load the columns given in the model named "App::Model::User" (where App is the name of your application class).
If your notion of a user object isn't a typical Jifty model or named something else, you will definitely need to override this method. If
you need to perform any additional initialization for user objects, you may want to override this as well.
superuser
A convenience constructor that returns a new CurrentUser object that's marked as a superuser. Can be called either as a class or object
method.
user_object
This gets or sets your application's user object for the current user. Generally, you're expected to set and load it in the "_init" method
in your Jifty::CurrentUser subclass.
id
Returns 0 if we don't have a user_object. When we do have a user_object, return that user's id.
current_user
Every class in a Jifty application has a "current_user" method that returns the user who's doing things, in the form of a
Jifty::CurrentUser object a subclass thereof. For the somewhat obvious reason that you can't actually lift yourself up by tugging on your
own bootstraps, a Jifty::CurrentUser object return itself rather than another "Jifty::CurrentUser" object.
AUTHENTICATION AND AUTHORIZATION
To use Jifty's built-in authentication and authorization system, your user objects need to implement the following API methods:
password_is STRING
Your user_object should have a method called "password_is" which returns true if passed a string that matches the user's current password.
username
Return a string which identifies the user in some way.
auth_token
Return a string which proves that the user is who they claim to be. A simple way to do this, for example, would be to hash the username
and some server-side secret.
RIGHTS AND ACCESS CONTROL
In any system that relies on users' rights to perform actions, it's sometimes necessary to walk around the access control system. There are
two primary cases for this:
is_superuser
Sometimes, while the system is running, you need to do something on behalf of a user that they shouldn't be able to do themselves. Maybe
you need to let a new user sign up for your service (You don't want to let any user create more users, right?) or to write an entry to a
changelog. If the user has the "is_superuser" flag set, things still get read from the database, but the user can walk around any and all
ACL checks. Think "Neo" from the Matrix. The superuser can walk through walls, stop bullets and so on.
is_bootstrap_user
When your system is first getting going, you can't assume anything. There probably aren't any rights in the system to check. A user with
the "is_bootstrap_user" flag set is a self-reliant superuser. Nothing is read from the database, no ACLs are checked. You probably never
need to do anything with bootstrap users.
current_user_can ACTION
For a current user object, the current user can always "read", but never write or do anything else.
jifty_serialize_format
Serializes as the user_object.
SEE ALSO
Jifty::Object, Jifty::Plugin::User
LICENSE
Jifty is Copyright 2005-2010 Best Practical Solutions, LLC. Jifty is distributed under the same terms as Perl itself.
perl v5.14.2 2010-12-10 Jifty::CurrentUser(3pm)