Delete distributed node on the retrieving server through Content Distribution

I'm not sure without checking, and it's been a while, but my gut feeling is the content type on #2 lacks the CCK field required to store the original NID. I can't remember if this is still a CCK field. It shouldn't be (not for Joachim! ;-) but it was, and if it's missing then #2 has no way to link it's "distributed" node back to the original node, because the NIDs will be different.

That *might* be it... =/

Original nids / local nids are stored in a special table {content_retriever}, from prior to my involvement.

Ok, so we must've used CCK when we prototyped it and then made it a "proper" node field later. Told you my memory was fuzzy!

Then that's weird. Sounds like a bug. Would need to test.

Bumping the version.

But I just tested this, and it does work properly. Granted, there are some things to tidy up:

- no docs on how to set this up
- services are called with no API key. Is this a security hole?
- for that matter, they are called with no login. XMLRPC is still black magic to me -- so what stops ANYONE from hitting your site with an XMLRPC call to node.deleteDistributedNode, a nid at random, and deleting a node?

Nothing, I think. Or rather, in the case of the production site I think the firewall does.

But this should use keys. At the time API key support in Services was pretty broken. It works now and we should use it.

What if we just check that the incoming Service method call to delete a node comes from the defined $endpoint domain, by looking at
$_SERVER['SERVER_NAME'] and comparing with the setting? Would that be sufficient?

Actually, thinking about it, the firewall can't. Hmm. Are you *sure* it doesn't use API key?

[replying to myself in #6]

... because writing a UI on the Distributor to save an API key for every Retriever site is going to be rather tedious.
At this right, it would be more efficient to move to become a Clients plugin, which (in theory, when it's ready) will handle all the Services connection setup for us.

@#7 -- look at distributor_service_delete_node() and content_distribution_nodeapi() op 'delete'. I see no key there!

In the meantime, I think the hole can be closed by not enabling Services on the Retriever, and not enabling node.deleteDistributedNode for the Distributor's API key. It does mean you lose the deletion feature.

And we can downgrade this from critical now.