PAPI::Cookie_Handler - mod_perl Apache handler to process requests from PAPI authentication servers.

SYNOPSIS

 sub handler {
    $r=shift;
    $url=$r->uri;
 
    if ($url =~ /$pa->{Auth_Location}/) {
# Redirection to an AS to reauthenticate user
       if ($url =~ /PAPIASRedirector/) {
          ....
       }
       else {
          $r->handler("perl-script");
          $r->set_handlers(PerlAccessHandler => undef);
          $r->set_handlers(PerlHandler => [PAPI::Cookie_Handler]);
          return DECLINED;
       }
    } 
 
    ....
 
 }

REQUIRES

Apache mod_perl >= 1.26, URI::Escape

DESCRIPTION

The handler function in this package processes the request according to the ACTION field received from the user's browser:

ACTION=LOGIN
The function checks the signature in the DATA field, and if it is correct, it generates new Hcook and Lcook tokens, sending it to the user's browser along with the object designated to be used for meaning acceptance: either an HTTP redirection to the URL defined by the AURL parameter of the request or the object configured to be used for meaning acceptance by default (see Accept_file in the configuration).
If the signature cannot be correctly verified, the function just sends the object designated for meaning rejection: either an HTTP redirection to the URL defined by the RURL parameter of the request or the object configured to be used for meaning rejection by default (see Reject_File in the configuration).
ACTION=TEST
The function checks whether the user has access to the resource controlled by the PAPI PoA, i. e., it looks for acceptable Lcook and/or Hcook tokens. If the test succeeds, it returns the object designated for acceptance to the user's browser, as described above. If not, it returns the object designated for rejection.
ACTION=LOGOUT
The function checks whether the user has access to the resource controlled by the PAPI PoA. If this is the case, it generates new empty cookies and sends them to the user's browser along with the object designated for acceptance, so all the cookies necessary to accessing the resource will be deleted from the user's browser. If the test for access rights fails, the function just sends the object designated for rejection.
ACTION=CHECK
This action is going to be requested from an automatic redirection made when a user tries to access a PoA under a certain GPoA (see GPoA_URL in the configuration). The function checks for a valid Hcook authentication token. If it is found, it generates new Hcook and Lcook tokens and send them along with a redirect to the original PoA URL, using ACTION=CHECKED and the data requested by the original PoA to generate its own cookies, signed with the GPoA private key (see GPoA_Priv_Key in the configuration).
If no Hcook is found, a parent GPoA is looked for in the configuration, and a request with ACTION=CHECK is scaled up in the GPoA hierarchy, or directly to an authentication server through a WAYF interface. This allows for GPoA hierarchies of arbitrary depth, and the combination of them with direct requests to PAPI authentication servers.
In the cases where redirecting the request is not allowed, or when the received Hcook is invalid, the redirect to the origin PoA is also performed, using ACTION=CHECKED, but with an ``ERROR'' flag set.
ACTION=CHECKED
This action is going to be requested as the result of a response coming from the parent GPoA of the PoA this handler is running for (either an actual GPoA or an AS answering to a ATTREQ query). The function checks the contents of the DATA field, and if it is correct, it generates new Hcook and Lcook tokens and send them along with a redirection to the URL immediately below in the GPoA hierarchy using ACTION=CHECKED as described above. If the check fails or the ``ERROR'' flag is set, the functions returns FORBIDDEN to block the progression down the GPoA hierarchy.

SEE ALSO

PAPI Configuration

PAPI Main Handler