++ed by:
CAMSPI JROBINSON AWNCORP KEEDI AERO

11 PAUSE users
15 non-PAUSE users.

Henry Van Styn

NAME

RapidApp::DirectLink::Redirector

SYNOPSIS

  package MyController;
  use Moose;
  use namespace::autoclean;
  BEGIN { extends 'Catalyst::Controller'; }
  with 'RapidApp::DirectLink::Redirector';
  
  sub directLink: Path("/DirectLink") {
    my ($self, $c, @args)= @_;
    my $linkUid= $c->req->params->{id};
    my $link= $c->model('DB')->directLink->loadByUid($linkUid);
    $self->dispatchToLink($c, $link);
    - or -
    $self->redirectToLink($c, $link);
  }
  
  # optional custom handling for when a session already exists
  sub directLink_handleAuthDiscrepancy {
    my ($self, $c, $curUser, $newUser)= @_;
    ...
  }
  
  1;
  

DESCRIPTION

This Moose Role provides the functionality of doing everything needed in order for a user to get to a RapidApp module.

If the user does not have a session, this module will first create one, using the data in the link, and then respond to the client with a redirect to come back to the desired URL.

If the user does have a session, this module will check to see whether the same user is being used, and if not, attempt to dispatch to the specified link as the current user, WITHOUT augmenting the permissions. (rationale: switching the user would require killing the active session, which would lead to all sorts of problems in the other browser window. Alternatively, augmenting the current user with the other user's permissions might indicate a violation of security)

Note: we should probably actually redirect to a page explaining that the user should log out first before following the link.

Some useful things to know regarding this module's interaction with the rest of the system:

Catalyst::Session tries to instantiate a session (deliver a cookie, etc) as soon as you write something to the "->session" field. Assuming the user has cookies enabled, you can simply create the session on the spot and continue to fill the first request. Or, if you like, you can send a redirect with the cookie to ensure that the session looks valid after a round trip, before showing the user anything.

Catalyst::Authentication writes a user object into the session after you call ->authenticate, assuming it succeeds. ->authenticate simply passes your hash to a plugin which does something with that hash to determine whether the login succeeds or fails. It also runs that hash through Store plugin, which will find an actual blessed User object based on the hash values. Calling ->authenticate is currently the only published method for officially initializing a user into the session.

METHODS

Processes a link's authentication parts, and then dispatches to the target of the link.

Returns a hash containing a 'success' key, and possibly diagnostics.

Returns a hash specifying a boolean 'success' key, and possible diagnostics.

This method handles the creation of a session and user authentication from the auth parameter of the DirectLink. The default behavior should fit most situations, but you can override it for special handling.

The users are objects generated by your Catalyst::Authentication::Store plugin.

Returns a hash specifying a boolean 'success' key, and possible diagnostics.

This is a sub-step of the default directLink_handleAuth. It resolves the differences between the current user and the user specified by the DirectLink. The default behavior is to inherit any permissions from the DirectLink user into the current user if and only if they are the same user id. Otherwise a warning is logged and no permissions are changed.

Override this method for custom processing.

SEE ALSO

Catalyst::Plugin::Session

Catalyst::Plugin::Authentication

Catalyst::Authentication::User

RapidApp::DirectLink::Link

RapidApp::DirectLink::LinkFactory