Page History

...

1. Define the database schema for the Authenticator model (Foo or Password in the above examples; Foo will be used going forward) in schema.xml as usual, and create the Model file (Foo.ctp) as usual.
2. If your Plugin supports a single Authenticator per instantiation
   1. Create two symlinks in your Plugin's View/Foos directory:
      1. info.ctp -> ../../../../View/Authenticators/info.ctp
      2. manage.ctp -> ../../../../View/Standard/edit.ctp
   2. Create a fields.inc file in the same directory that contains the form elements you need for your Plugin. (See other Authenticator plugins in the AvailablePlugins directory for examples.) The plugin configuration will be available in $vv_authenticator.
   3. Implement Model/FooAuthenticator.php as described above. Specifically, you must
      1. Override current() so that it returns the current record(s) based on the parameters passed via the function signature. The results from this function will be passed to your fields.inc View via the $vv_current variable.
         1.  As of Registry v4.0.0, there is now a default implementation of this function implemented in AuthenticatorBackend that should work for most simple models. This function will also be used to provide data to Provisioner Plugins.
      2. Override manage() so that it implements whatever backend logic your plugin requires, including data validation and the actual saving to the database. You should also create a history record indicating that the Authenticator was updated, as part of this call.
      3. As of Registry v4.0.0, plugins may override lock() and unlock() if plugin-specific actions are required when the Authenticator is locked or unlocked. (Ordinarily, locking or unlocking disables the COmanage management interface and removes the Authenticator from provisioning data.) When doing so, the plugin must manually manage AuthenticatorStatus records, or else locked data may be provided to Provisio
   4. Implement the reset() call.
3. If your Plugin supports multiple Authenticators per instantiation
   1. Implement an index view. If you follow the typical add/delete/edit pattern used by other controllers, the parent SAMController will take care of much of the busy work for you, and you can simply provide a fields.inc with the typical contents (and symlinks to the Standard views).
   2. reset() is not automatically supported. You can either use the standard delete action to remove an Authenticator, or add your own custom action to the index view (with the usual supporting MVC requirements to implement it).
4. Implement the status() call. If your Plugin supports multiple Authenticators per instantiation, the result should aggregate status across all Authenticators attached to the Backend.
5. FoosController.php should use $this->calculateParentPermissions() to calculate permissions for the required actions in isAuthorized().

...

In the Complex method, the plugin is expected to override the controller's manage() action (and reset() if appropriate) instead of overriding the model's functions as described above. In other words, if you override SAMController::manage(), you do not need to worry about overriding AuthenticatorBackend::manage() or current(). This gives your plugin the ability to perform whatever logic and process flow it needs.

 As As of Registry v4.0.0 it may be necessary to override current() to provide information to Provisioner Plugins, unless the default implementation in AuthenticatorBackend is sufficient.

Your controller's manage and (if appropriate) reset actions must manually call provisioning at the appropriate point in your plugin's logic.  As of Registry v3.3.0, Authenticators may be established during enrollment. Authenticator plugins should not trigger provisioning during enrollment.

As of Registry v4.0.0, the plugin must also trigger notification when the Authenticator is updated. The easiest way to do this is with AuthenticatorBackend::notify(), which will handle all the necessary steps.

When you are finished, your controller should return control to Registry by calling $this->performRedirect().

...
// Finished updating our Authenticator's state in the database
if(!isset($this->request->params['named']['copetitionid'])) {
  // Don't provision or notify if we're in an enrollment
  $this->Authenticator->provision($coPersonId);
  $this->Authenticator->notify($coPersonId);
}
 
// All done
$this->performRedirect();

...

Use $this->calculateParentPermissions() to calculate permissions for the required actions in isAuthorized().

...