API change: make authentication management pluggable
| Project: | Version Control API |
| Version: | 6.x-1.0-rc2 |
| Component: | API module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
So, we have the following issues:
- Not all admins will want or require to manage their (CVS) account passwords with Drupal, as it needs to be hooked up with the VCS - that assumes that you have the permission to manage those accounts at all! Furthermore, it won't be necessary if you just want to use the "viewer" functionality of a backend.
- Subversion, Git and Mercurial use the same kind of user authentication systems - HTTP(s), or SSH (probably with an .ssh_keys based solution). Subversion also has an additional "svnserve" possibility, so backend specific and backend agnostic authentication methods need to co-exist side by side.
So let's make those authentications pluggable. What constitues an authentication method plugin?
- Storing the password that the user has entered in the registration form.
- And based on that, import/export functionality.
The idea is to let authentication method plugins register themselves with Version Control API (much like hook_versioncontrol_backends()) and let backend modules specify which authentication methods they support, as additional info that we get from hook_versioncontrol_backends(). The Version Control API will determine if those plugins exist, and let the admin choose which authentication methods should be enabled for each repository. On the register page, the user can then select which one of the predefined authentication methods he wants to use (HTTPs or SSH, for example), and if no method has been enabled by the admin then the user doesn't get to enter a password at all.
Authentication methods will be specified with unique string identifiers that they pass with the registration hook. More details (or a finished implementation in the first place) to follow soon.

#1
Oops, still not implemented in 5.x-2.x? Well, seems I was a little too confident. Still important, because a) the VCS account "subsystem" needs to be improved anyways, and b) account synchronization for anything else but CVS is pretty much impossible with the current system. Guess I should have outlined my design with a bit more detail (of course I forgot nearly everything since I wrote the original issue), but then again it should still not be all too difficult to just separate authentication from Drupal/VCS account associations. Input, help & everything appreciated.
#2
Oh hey, and I totally forgot to link to my analysis of this issue (and the subsequent findings in the comments section): http://groups.drupal.org/node/8527
#3
Just to point dhax review: http://groups.drupal.org/node/23464 really related and where it _is_ proposed a solution :-D