0

I'm using user_login_finalize() in my code to login a user (right before the review page), and this works because I can see the log in drush watchdog-list. However, it only works behind the scenes: the browser session remains anonymous. The browser has a new anonymous session though.

It's almost like a new PHP thread is spawned for the user instead of using the old one (thus, Drupal logs the user and spawns a new thread, so the user is still anonymous even though Drupal has logged the old user). I don't know whether it does that, but that's what it looks like.

I know this doesn't help you per se, but I'd like at least to know how to debug that. I'm really lost there.

FWIW, here is the drush watchdog-show 66341 for the login:

 Wid        :  66341
 Type       :  user
 Message    :  Session opened for dsdsdsdsdsdsdsdsdsd@sdsdsds.com.
 Severity   :  notice
 Location   :  http://test.lxc:81/checkout/11
 Referer    :  http://test.lxc:81/checkout/11
 Hostname   :  192.168.120.1
 Date       :  08/oct 16:20
 Username   :  dsdsdsdsdsdsdsdsdsd@sdsdsds.com

More information: I'm using the following code where I call user_login_finalize:

global $user;

$account = new stdClass();
$account->is_new = TRUE;

$edit = array(
  // More to come later, but this is the only constraint
  'name' => 'some random name',
);

$user = user_save($account, $edit);

// Checking $user here, it has the correct UID of a new user.

user_login_finalize();
Improve this question
0

You mean that the user remains anonymous in the browser session, right? (In Drush, you must pass -u uid on every invocation to specify the user, because Drush is stateless.)

Make sure that the Drupal session cookie is being set in the browser. If, for example, you set the cookie in the secure context (https) and then redirect to http, the cookie will be inaccessible, and the user will remain anonymous.

Edit: user_login_finalize requires a $form_state parameter; see: http://api.drupal.org/api/drupal/modules%21user%21user.module/function/user_login_submit/7 It's hard to see which fields of the form state are relevant, since it is just passed to user_module_invoke. However, if you compare what is in $form_state during a normal Drupal login, and supply the same information in your function, then it should work fine.

Improve this answer
  • There is no context switch (it remains http all the time), and the cookie exists. However, the session cookie ID is regenerated. Which makes me think that the user_login_finalize() worked, but somehow not all the way. There's no session for the UID created, but that may be because its session is closed. And yes, I meant that the user remains anonymous in the browser session. – Florian Margaine Oct 8 '12 at 14:58
  • I updated my question to add some relevant details. – Florian Margaine Oct 8 '12 at 15:18
  • I have already tried using the $form_state (the same as during a Drupal login), with no success unfortunately. So I'm trying to find what's "in between", to no avail. This is also why I asked in the question but I'd like to know *how* to debug – Florian Margaine Oct 8 '12 at 16:08
  • With the devel module, you can use drush fn-hook user to see all of the implementations of hook_user, which may give you some ideas about what to put into $form_state. You could also try stepping through the login function with xdebug (drupal.org/node/147267). – greg_1_anderson Oct 8 '12 at 16:38
  • I just looked at user_pass_reset() in user.pages.inc, and it appears that user_login_finalize does not need anything in $form_state. Maybe you could try outputting a password reset link (get one via user_pass_reset($account)) instead of calling user_session_finalize(), and compare the behavior + trace the execution of this code path (clicking on the pw reset link) vs. the code you want (calling user finalize directly). The only thing I can really think of is that drupal_session_regenerate() might be failing e.g. because you output text before calling finalize. Maybe call it sooner. – greg_1_anderson Oct 9 '12 at 2:34
0

I ended up bypassing user_login_finalize and invokes the hooks myself with module_invoke_all('hook_user_login');.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.