Voting starts in March for the Drupal Association Board election.
As the result of a security issue, changes were made in the default values for access callbacks in service definitions. This has introduced the following changes.
Default access callbacks
As of 2.1, if you have not specified an '#access callback' key in your service, then the service will default to using Drupal's user_access() function. This function requires a permission string to be specified. Access is checked against this permission, which is passed by your service in the '#access arguments' key. This '#access arguments' key is required by user_access(), and thus services that do not have either '#access callback' or '#access arguments' specified will throw a PHP error.
There are two solutions to this.
- Add an '#access arguments' key to your services, containing the string of a permission to check. If the user accessing your service has the appropriate permissions, then the service will run. Otherwise Services will return Access Denied. For instance
'#access arguments' => array('administer nodes')
Will allow any user with the 'administer nodes' permission to access this service. Note that if you are using API Keys without user sessions, then all your services are running as the anonymous user.
This is the recommended solution for most modules. In many cases you will not be able to use internal Drupal permissions, because you are using API Keys and don't want to allow anonymous users access to a permission like 'administer nodes' or 'administer taxonomy'. In this case you should create a new permission for your each of your services using hook_perm() and give anonymous users access to that permission. This will allow you to protect your services via API Keys but prevent unauthorized users from having access to any other protected content on your site.
- Write your own access checking function and specify it in '#access callback'. Arguments can be passed to this function in '#access arguments'. This function can check whatever data is appropriate and return TRUE or FALSE as necessary.
The security implications of these decisions are important. If you have any questions feel free to contact the maintaner through his contact form, or come to #drupal-services on IRC where we will be glad to help.
Three core services now have custom permissions
Access permissions were added to the following three core services:
While the underlying functions did check user access and protected sensitive data, we felt it was prudent to have explicit access checks for all services. In order to use these services you will have to give users the 'access taxonomy from remote' or 'get menu information' permissions as appropriate.