The user/create and user/register services are aliases of one another. They both have _user_resource_create() as their callback.

This performs a programmatic submission of the 'user_register_form' form, rather than use user_save().

This means that any alterations to that form are included. This is perhaps a good thing when it comes to Profile2 fields, but on site that's running CAPTCHA module it means the form validation always fails because the system using the service can't supply the right answer.

We can't change the callback to go via the API at this point, as we'd lose the ability to set Profile2 fields and that would be an API change.

But could we add a service that creates a user via the API rather than with a form submission?

Comments

marcingy’s picture

marcingy commented

There is a project that provides x_save based services https://drupal.org/sandbox/mhrabovcin/1424044

kylebrowning’s picture

kylebrowning commented

Im really not opposed to offering both types the, value add of having form submission is all the hooks, but a lot of people seem to think that sucks royally.

As long as tests exist Im down with adding another user resource call Raw or something?

joachim’s picture

joachim commented

> value add of having form submission is all the hooks,

If they're hooks at the form level, they're surely to do with the form submission itself. Things to do with reacting to the creation or editing of a user are best done in hook_user_[create/update](), I think.

After all, it might be reasonable for a site to want to redirect the user to another page on login, or return something wacky in the form ('Go see our great promotions!') which would totally mess up what Services expects to get back.

> As long as tests exist Im down with adding another user resource call Raw or something?

We don't need the whole of the user resource in raw format -- Services Entity (https://drupal.org/project/services_entity) provides CRUD resources for all entities that go via Entity API.

user/create is covered there, however, it's subject to 'administer users' permissions because of the way Entity API provides support for access to users via its APIs -- which is perfectly reasonable.

I'm not sure whether a raw 'user/register' service should go in Services or Services Entity -- it's going to end up as a special case in either.

Either way I'm happy to work on a patch -- just not sure where is best yet.

joachim’s picture

joachim commented

I took the plunge and tried doing this in Services Entity, just to see how fiddly it was.

Turns out it's only 3 lines of code. Services Entity already copies over any additional services from the core entities, so entity_user/register is already defined as a straight copy of user/register.

All I need to do is undo a bit of that copying to have entity_user/register use the same API-style callback as entity_user/create.

We do however need to keep the user/register access callback, as that allows anonymous users to create accounts over services.

kylebrowning’s picture

kylebrowning commented

How should we handle this moving forward with services.

Is there a way to hook into Captcha and disable it for services submitted forms?

It would be nice to provide code here to do so, but I can't picture putting this edge case into services.

tyler.frankenstein’s picture

tyler.frankenstein commented

I've recently come across this issue with a few apps. Here's an easy workaround for those wishing to use a custom module to get around this:

function my_module_form_alter(&$form, &$form_state, $form_id) {
  // Disable captcha on Services user register form.
  if ($form_id == 'user_register_form') {
    if (arg(0) == 'my_services_endpoint_path') {
      unset($form['captcha']);
    }
  }
}
kylebrowning’s picture

kylebrowning commented
Category: Bug report » Support request
Status: Active » Closed (won't fix)

AS this is a stance we've had before, Im inclined to say Services module maintainers can't be expected to maintain code thats related to captcha without understanding what captcha does with its code.

Hence, I don't think this is a bug in services but rather captcha.

At any rate, the above work around will work.

joachim’s picture

joachim commented

Hmm but the converse of that is that Captcha can't be expected to know that Services is going to be pretending to be submitting forms...

Or can it? Is there a way to signal that a form is being submitted programmatically rather than by a human user?

marcingy’s picture

marcingy commented

I believe is drupal_form_submit sets

$form_state['programmed'] = TRUE;