Jifty::CurrentUser - Base class and basic implementation of current user object

Jifty documentation Contained in the Jifty distribution.

Index

Code Index:

NAME

Top

Jifty::CurrentUser - Base class and basic implementation of current user object

DESCRIPTION

Top

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

Top

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

Top

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

Top

Jifty::Object, Jifty::Plugin::User

LICENSE

Top

Jifty is Copyright 2005-2010 Best Practical Solutions, LLC. Jifty is distributed under the same terms as Perl itself.

Jifty documentation Contained in the Jifty distribution. 
use warnings;
use strict;

package Jifty::CurrentUser;

use base qw/Jifty::Object Class::Accessor::Fast/;
use Scalar::Util qw();

__PACKAGE__->mk_accessors(qw(is_superuser is_bootstrap_user));


sub new {
    my $class = shift;
    my $self  = {};
    bless $self, (ref $class || $class);
    my %args = (@_);

    # Make this user a bootstrap user if in bootstrap mode
    if ( delete $args{'_bootstrap'} ) { $self->is_bootstrap_user(1); }

    # Call _init for app-specific initialization
    $self->_init(%args);

    return $self;
}


sub _init {
    my $self = shift;
    my %args = (@_);

    # Duck-typing to check to for a user class
    my $user_class = Jifty->app_class({require => 0}, 'Model', 'User');
    if (keys %args and UNIVERSAL::can($user_class, 'new')  ) {
        $self->user_object($user_class->new(current_user => $self));
        $self->user_object->load_by_cols(%args);
    }

    return 1;
}


sub superuser {
    my $class = shift;
    $class = ref( $class ) if ref $class;

    # Create the current user object
    my $self = $class->new();

    # Make it superuser and send it out
    $self->is_superuser(1);
    return $self;
}


sub user_object {
    my $self = shift;
    return $self->{'user_object'} unless @_;
    $self->{'user_object'} = shift;

    # protect ourself from circular refereces to prevent memory leaks
    if ( $self->{'user_object'}{'_current_user'} == $self ) {
        Scalar::Util::weaken( $self->{'user_object'}{'_current_user'} )
            unless Scalar::Util::isweak( $self->{'user_object'}{'_current_user'} );
        $self->{'user_object'}{'_resurrect_current_user'} = 1;
    }

    return $self->{'user_object'};
}


sub id {
    my $self = shift;

    # This can be a hotspot, so we don't use method calls, instead
    # directly accessing the value.

    # Make sure we have a user object before trying to ID it
    return $self->{user_object}->id if $self->{user_object};

    # No user object, return a null ID
    return 0;
}


sub current_user {
    my $self = shift;
    return $self;
}


sub password_is {
    my $self = shift;
    return undef unless ($self->user_object);
    return($self->user_object->password_is(@_));

}


sub username {
    my $self = shift;
    return undef unless ($self->user_object);
    return($self->user_object->brief_description(@_));
}


sub auth_token {
    my $self = shift;
    return undef unless ($self->user_object);
    return ($self->user_object->auth_token);

}


# XXX Is this actually used?
sub current_user_can {
    my $self = shift;
    my $action = shift;
    return (1) if $action eq 'read';
    return (0);
}


sub jifty_serialize_format {
    my $self = shift;
    return {} if !$self->user_object;
    return $self->user_object->jifty_serialize_format(@_);
}


1;