The user just logged in.

The user just logged in.


pfrenssen’s picture

You can use this hook to redirect users to a different page on login, but you will have to make sure the password reset functionality is not impaired.

Here how the Login Destination module does it:

 * Implements hook_user_login
function login_destination_user_login(&$edit, $account) {
  if (!isset($_POST['form_id']) || $_POST['form_id'] != 'user_pass_reset' || variable_get('login_destination_immediate_redirect', FALSE)) {
lmeurs’s picture

@pfrenssen: can you elaborate on impairing password reset functionality?

The next lines of code seem to work for me on Drupal 7.12, without the use of the Login Destination module:

function hook_user_login(&$edit, $account) {
  $edit['redirect'] = 'node/123';

Works for both regular login page and login forms loaded through drupal_get_form('user_login'). The user login block redirects to the page the user logged on to.

akki123’s picture

function hook_user_login(&$edit, $account) {
  $edit['redirect'] = 'node/123';

is working , $_GET['destination'] failed to produce desired result.

mstrelan’s picture

When using the one-time login link user_pass_reset() calls drupal_goto() after user_login_finalize() has invoked hook_user_login(), so this is not an issue.

stevesmename’s picture

@pfrenssen - Huge help, thanks! Unchecking a single checkbox in Login Destination module solved the horrible password reset loop problem. I had to still force logged in users to be logged out when they request a new password.

weboide’s picture

pfrenssen's comment is actually very valuable, as it also checks to see if the user is not currently using a one-time link to reset his password.

Here's a piece of code that I use:

function mymodule_user_login(&$edit, $account)
  // Your logic will set $redirection to the desired location
  $redirection = 'node/394';

  // Unless there is already a redirection going, or the user is trying to reset his password, we redirect to $redirection.
  if (empty($_GET['destination'])
    && !is_null($redirection)
    && (!isset($_POST['form_id']) || $_POST['form_id'] != 'user_pass_reset'))
    $_GET['destination'] = $redirection; // Should we use $edit['redirect'] instead..?
bsandor’s picture

Perhaps it should be because of other functions change $edit['redirect'] after my module changes it.
I have a working function, i've double checked that it is called, just $edit['redirect'] = 'destination' doesnt take affect.
I presume there's some system logic issue here.

mxh’s picture

I had to redirect logged in users who use the login block. I checked the edit array and I noticed that the redirect value was already filled with the user/uid path. However, the default behaviour was that the user will be directed automatically to the current page where he was before.

So $edit['destination'] didn't work for me, but $_GET['destination'] does.

drupal_master’s picture

I have tried all the way given here but, but these are not working for me, then i tried
$GLOBALS['destination'] = 'your/path'

and its works for me

stomerfull’s picture

$GLOBALS['destination'] = 'your/path' work for me too


iMaze’s picture

Probably a silly question. But, how can I register some code to be execute after a user has submitted their user name and password and have been successfully logged into the system? I am looking to inject some code for execution before the logged in redirect takes place, Where can I do that?

So, I want the user to submit their login info, log the user in, perform some processing, then allow the redirect to take place and allow the user to go on their way.


netgenius.co.uk’s picture

In other situations you can check if user has logged in from a one-time login link by checking for $_GET['pass-reset-token']. However, it seems that when hook_user_login runs, Drupal has not yet run its processing of the request URL, and $_GET will contain something like:

'q' => 'user/reset/29676/1455558915/qLL74sLI8Yzkqr3z6gCXNFnkl3tuXQpHDYzCjwK2jnk/login'

... So, test for 'user/reset/' in $_GET['q'] instead of testing for $_GET['pass-reset-token']. Works for me anyway!

DarrellDuane’s picture

Yes, I like this better because if you're using the "Separate Password Form" module, the example that is at the top of the page won't work.
I used this code at the top of hook_user_login()

  $refering_url = $_GET['q'];
  if(strpos('user/reset/', $refering_url ) )
sandip.prajapati’s picture


nicxvan’s picture

Is there a reason it's called $edit if it's just $form_state?

Fool2’s picture

Nicxvan, this is a relic of the original hooks in Drupal. They existed before forms API which defined form_state etc. They are likely still this way for backwards compatibility.

nealhene’s picture

I was working on an issue with one of my sites, trying to get one of the user variables to update on login with data from SAML. I am using this hook and I used Devel dpm() to print the $edit and $account variables to the screen. Whilst testing I was shocked to see my own password in plain text printed on the screen. Surely this a security issue?
It would be quite easy to write a little PHP to have usernames and plain-text passwords sent in an email or saved in the DB.

milos.kroulik’s picture

Please submit your concern to Drupal security team at https://www.drupal.org/node/101494. Thanks!

nealhene’s picture

I have created an issue here https://security.drupal.org/node/161732. Thanks for pointing me in the right direction.