Salesforce notification endpoint relies on access content permission

@andreigg thanks for debugging and submitting a patch.

In your setup, can you try removing 'access arguments' altogether and see if outbound messages will go through?

If not, we can go the route you are suggesting, although this adds a bit more complexity and would require adding documentation to the module and handbook about how to configure SF Notifications (i.e. always grant the 'access salesforce notifications' permission to anonymous users, explain why, etc).

@kostajh-
I have independently confirmed that merely removing the 'access arguments' line altogether was insufficient to grant access. Could it be inheriting the permission from another menu item? Or maybe it is a default Drupal menu system understanding that in absence of all other access() requirements, that anonymous must be able to access content before proceeding?

I found @andreigg (#1) patch to successfully resolve my issue that Salesforce.com Message (as "Anonymous user") could not reach the Drupal menu item /sf_notifications/endpoint and also adds an Access Denies to watchdog (before even getting to ip address check). Thanks for the patch!

For anyone else testing: Be sure to flush menu cache while making changes to the patched menu.

If anything were changed on this simple patch: maybe the wording of the permission "access salesforce notifications" should be something like "access local salesforce endpoint" to be clearer and more precise.

@texas-bronius thanks for the report. I am cool with this change but before the patch is committed, we need documentation in the README - just a sentence explaining what this permission is and why it should be granted to anonymous users. I would also welcome an updated patch that grants the "access local salesforce endpoint" permission to anonymous users by default in hook_install and via hook_update_N().

Hi @kostajh: Took a stab at this this afternoon but am stuck with assigned Anonymous -> "access local salesforce endpoint" on _install and _update_N. Closest I found is this as a guide:
http://patrickteglia.com/blog/adding-permissions-role-programatically
Is it really that convoluted in D6? Any lighter suggestions short of a "enabled, now add some permissions" message?

#kostajh: Oops-- turns out to be much simpler to change the menu item access from 'access arguments' (necessitating a permission, necessitating a role) to 'access callback' returning TRUE (bypass it all). With this simpler change, no change in documentation and no additional update and install hooks were necessary. There's a hair of a chance that someone might want a hook_update_N to rebuild the menu for this new permission check, but it will not stop working for someone who applies this patch and those for whom it wasn't working are already in this queue looking for @andreigg's original solution! :)

    'access arguments' => array('access content'),
    // .. or from the earlier patch ..
    'access arguments' => array('access salesforce notifications'),
    // .. becomes ..
    'access callback' => TRUE,

Attached is said patch against the 6.x-2.x-dev branch. Happy weekend!

Ok, I am fine with this. Committed to 6.x-2.x (http://drupalcode.org/project/salesforce.git/commit/c7a82e9) and 7.x-2.x (http://drupalcode.org/project/salesforce.git/commit/3e2a5e3). Thanks!