Pluggable authentication for Deploy

Okey, great to see you like the idea! We will maintain and reroll the patch further here in the queue!

Yeah, too bad you couldn't come to Sweden! The Kitten Killers will definitely not disappear ;) Who knows, maybe Kitten Killers will be on stage in San Francisco next year!?

Nice!

Yeah, unattended deployment would be possible with some tweaks. But I see the security risk with storing API key and domain key equal to storing username and password as those are the combination of keys that gives you access to the service. Although, username and password are more serious as those are sent with the request each time, and could give you access to a whole site...

But, for making this possible I think settings like this should be stored on a per-server basis. Maybe add a data column to the deploy_servers table where we could store whatever suits the authentication type best (like API keys etc.). To do so, some AHAH sweetness should be added to the "add server" form, so the necessary data fields adds to the form when selecting the authentication type.

Just noticed a small spelling error here:

+/**
+ * Implementation of hook_update().
+ *
+ * Add new auth_type field for pluggable authentication 
+ * and drop unused api_jey field.
+ */
+function deploy_update_6003() {

I'll give it a deeper look soon.

After some some consideration I think that storing the settings for the deploy_key implementation in plain text is ok. After all, that is how it usually works for other modules/applications. The API key isn't passed with any request and aren't exposed in an insecure fashion. Look at the Mollom module for example.

Two new features are introduced in this patch which is based on #3 with the spelling fix:

1) The form where servers are created now has the possibility to save settings specific to the authentication type (API keys etc.). All these settings are saved serialized in a new column in deploy_servers.settings. Note that saving settings is optional! It's up to the user to decide whether or not to store possibly sensible information in the database.

2) Both deployment callbacks (admin/build/deploy/push and node_operations/deploy_now) can now take an additional argument - a server id. If a server id is passed, and the server has stored settings, deployment will happen immediately with these settings. I'll leave the actual implementation of this to #537488: Add the ability to push deployment plans without user input (for instance from cron) after this is committed.

Along side of these changes I also renamed some functions relevant to this issue, to have better consistency.

Additional features we could consider:

3) Add a flag to each authentication type to tell if the settings are storable or not. We could flag the deploy_sessid implementation as not storable. Maybe this should be done on a per-setting-level, so we could store username, but not password?

The patch still needs some love.

When (if) we get this committed I'd really love to see a cleanup/renaming issue to get better consistency over function names, and menu callbacks etc, before a stable release. The code is starting to get quite complex.

Here is a reroll that applies to DRUPAL-6--1 with some adjustments and a little better documented.

After the IRC discussion yesterday with heyrocker I decided to removed the experimental storage possibilities for authentication settings. Obviously because of the security implications this will have. So this patch is a little more lightweight.

I don't know how strict conventions are about breaking function naming during 1.x-dev development. But I've tried to introduce a little more consistent naming throughout the deployment flow.

Basically, the flow looks like this:

One module can declare one or more authentication methods. The declaration looks similar to the array in hook_menu().

• deploy_plan_push_form() - From for selecting the server. Invokes the "form callback" for auth modules and appends server settings (username, password ord api key and domain name) via AHAH.
• deploy_plan_init() - Is called during the form submission above. Initiates depoyment. Also invokes the "init callback" for the server's auth method. Session auth method will connect and log in to the server at this stage. The key auth method doesn't need to do anything.
• The form redirects to the Batch API that invokes the "arguments callback" in every operation. This populates the XMLRPC request with appropriate arguments for the method call.
• deploy_plan_cleanup() - Is the last function that will be called during batching. This also invokes the "cleanup callback" which lets the auth method cleanup after it self.

Because of lack of time, and the recent changes to the patch I haven't got the time to implement this for other sub modules than node_deploy.module. I will continue work on this next week!

And here comes the patch...

Here is the first complete patch! With this node, comment and taxonomy deployments should work with the new pluggable authentication system.

Here is a new cleaner and better performing patch! I also added more flexibility to the system by making it possible to alter authentication types.

New hook introduced: hook_deploy_auth_type_alter()

Here is a new reroll that should apply with the latest code in DRUPAL-6--1. The important thing with these two latest patches, as mentioned in #15, is the introduction of hook_deploy_auth_type_alter() that let modules alter authentication types.

Wonderful! I been very busy the last few months but I'll give it a look before I head to Copenhagen this weekend!

I've done some extensive testing with this today, and can't find any problems with it.

I've tested deployment with...

• both authentication methods (sessions and keys)
• nodes (with various dependency modules like nodereferences etc)
• users
• comments
• views
• taxonomy (both as a dependency for nodes, but also single deployment of a vocabulary)
• system settings
• content types

I've also tested the upgrade path. And the auth_type column gets successfully applied and session authentication is set as the default for all existing servers... Man, we need SimpleTest for Deploy 2.x :)

So, everything seems to work as expected with your reroll from #16. Patch committed. Yay!