This discussion has been transferred to the issue queue: http://drupal.org/node/806918 and http://drupal.org/node/807638
I am currently using the Services module for a project where an external application is responsible for creating, updating and deleting user accounts in a Drupal based intranet.
Most things are working just fine, however there are a few points which I have doubts about:
- The
user.getservice - Requiring the external application to know the
uidof the user account a priori doesn't seem to make much sense to me. It would be better to 'get' the user via user-name or e-mail IMHO. This could be implemented with an additonaluser.getbyservice. - The
user.saveservice - Drupal's special users (uids 0 and 1) require some configurable protection against being changed. I don't want the external application to be able to change the values of these accounts.
- There are other users (such as site editors or administrators) that I'd prefer the external application not change (signs of creeping paranoia?). These can be designated - and distinguished - by special roles.
- The
user.deleteservice - For the same reasons as above, I don't want the external application deleting uids 0 or 1, or any specially designated users.
It would seem a reasonably good idea to add a User tab to the Services administration page (admin/build/services) where:
- a checkbox allowing write (save) permissions for uids 0 and 1.
- a checkbox allowing delete permissions for uids 0 and 1.
- a checkbox list disallowing write (save) permissions for roles.
- a checkbox list disallowing delete permissions for roles.
This way the default values would protect uids 0 and 1 - which I think is "A Good Idea"™
I'd like to kick these ideas around in this community before offering a patch to the module.
Best regards,
John
This discussion has been transferred to the issue queue: http://drupal.org/node/806918 and http://drupal.org/node/807638
Comments
User Protect
I don't like adding new functionality into Services that differs from how Drupal core works, so I'm not inclined to add the protection features. You may want to look into a module like http://drupal.org/project/userprotect which SHOULD protect for those changes with Services. If it doesn't let us know. That would be worth supporting.
The user.get change I'm more inclined to accept, since it is in line with how core works. Feel free to supply a patch there.
Also in general I'm in favor of having the community discussions around new features happen in the issue queue. It makes them more visible to people coming into the project new, and provides a single source of decisionmaking history.
Hi jhl.verona, I think these
Hi jhl.verona,
I think these features make a lot of sense from a security stand. I think I agree they may not have a place in services core by default since as heyrocker said, it alters the default way drupal works. But I'd be interested in something like that if provided by a contrib module for those of us who want those features. Have you arrived at any new conclusions?
It still remains as a patch
It still remains as a patch to the version 2.0 services module, see http://drupal.org/node/807638