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 Provisioning 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.)
   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().

...

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

...