Blog API can bypass default "Published" setting for content type

Issue Summary

I noticed this issue while implementing workflow for a blog site I'm building.

Normally only users with the 'administer nodes' setting have permissions to change the 'Published' setting while creating or updating a node. Implementing a basic workflow for a particular content type consists of setting the default for 'Published' on the content type to unchecked.

Then, for example, a writer role will have create and edit own permissions for a content type, while an editor role has the 'administer nodes' permission. When an editor is satisfied with a peice of content from a writer, they can update the node and tick 'Published' so it is available to the world.

However, if a writer is manging their content using the Blog API with something like Windows Live Writer or ScribeFire, they're able to create/update nodes and set the "Published" flag, even when they don't have the administer nodes permission. This is potentially dangerous because 1) Writers could mistakenly publish drafts to a live site or 2) Publish crude content to the front page of a site if they had grief with the site owners/management/whoever.

Attached is a patch that adds some logic to blogapi_blogger_new_post() and blogapi_blogger_edit_post(). The idea is if the published setting on the post is being set/changed to the non-default value for the content type, and the user does not have 'administer nodes', then display the proper error message.

The reason I have the logic after node_invoke_nodeapi() is to give modules a chance to react and modify the node prior to the logic. For example, a module might force $node->status or $edit['status'] to be the default value, preventing the logic from kicking in. In my case, I wrote a module that allows users with a particular permission to publish content without needing the administer nodes permission. It integrates with the Workflow module to automatically update a node's workflow state depending on the publish option set through the blog API. I wanted the site to automatically put the node in a proper published state depending on the users roles.

I should have backports of this for D6 and D5 later tonight.