What is the purpose of _services_controller_execute_preserve_user_switch_anonymous()?

Question

I have been having a problem persisting the authenticated session after a successful registration using Services 7.x.3.11 in Drupal 7.

I've sort of solved that issue by commenting out the call to _services_controller_execute_preserve_user_switch_anonymous() inside of sites\all\modules\services\includes\services.runtime.inc. The file's comments read:

As authentication methods should authenticate user themselves changing global $user variable we preserve incoming session authenticated user and his session so changes made by authentication do not interfere.

Aside the grammer, I do not understand the purpose of this method nor how Services authentication works and integrates with Drupal's core. Can anyone explain why this is necessary for Services to honor Drupal's roles and permissions.

Answer 1

The user register action (which is essentially just an alias of the user.create resource) executes the user register form. Doing so affects the global $user object, which overwrites any existing $user object. Other resources related to the user will also do the same thing.

This is undesirable, as it replaces the global user that you're using to authenticate against the endpoint. So the Services module saves your session before executing any callbacks, and restores it afterwards. This ensures the integrity of the original session.

I think the misunderstanding is simply that you're expecting the user register resource to automatically invalidate the current session, and replace it with a session for the newly created user. I can't see anything in the code that would suggest that's supposed to happen, and it makes sense that it wouldn't...

Imagine your app needed to register 10 users in a batch; if your session was invalidated each time you made a call to user.register, and replaced with a session for the new user, you'd have to logout and potentially re-authenticate before each subsequent registration. Not an ideal situation to be in.

Answer 2

I know this is old but just for the record in case someone else came to the same problem, Drupal Services are preserving the user session who originally requested the service resource and restoring it after fulfilling the requested service resource. This is intentionally desired as long as the resource used will not login or log out the customers in drupal site.

An exception to this is dealing with other login provider like LDAP or Social Login through services, Thus the added service definition need to authenticate the user and log him in so he can resume using the other services.

Solution to this is to include the "login" word in your service call back definition, as this will grantee that drupal will keep the session that you created and consider it as valid session.

An example is as below for service definition

$definition['my_module']['actions']['connect'] = array(
'help' => 'Services login using my_module_logic ',
  // Please note that login is mandatory in the name of call back 
  // this will allow drupal to preserve the session that we get here
  // check _services_controller_execute_preserve_user_switch_anonymous
'callback' => 'services_my_module_login',
'args' => array(
 array(
    'name' => 'provider',
    'type' => 'string',
    'description' => 'A valid my_module login provider ',
    'source' => 'data',
    'optional' => FALSE,
  ),
),
'access callback' => 'services_access_menu',
);

You can get more information by checking the code here

_services_controller_execute_restore_user    

_services_controller_execute_preserve_user_switch_anonymous