Drupal 7: Login Destination Based On User Role

19th August 2011 - 3 minutes read time

Note: This post is over a year old and so the information contained here might be out of date. If you do spot something please leave a comment and we will endeavour to correct.

The Login Destination module is a neat little module that allows site admins to customize where the user will be sent to when they login. It provides a few of different ways of customizing, including a PHP snippet box that allows fine grained control.

What I needed to do on a recent project was to change the login destination for a single user role, but redirect everyone else to their user profile page. This required the use of the PHP snippet box. In order to get access to the current user object I had to include it into the scope of the PHP snippet code by using the following.

global $user;

With this in hand I could then use the roles property of the $user object to find out what role the current user. However, because the roles property is an array (due to the ability assign users to more than one role) a direct comparison is not possible. So I used PHP function in_array() to search the array for the role name. The following snippet is what I came up with, it redirects any user assigned to "An Awesome Role" to the create new page form, everyone else gets redirected to their user profile. Note that you should not use the php tags in the snippet area.

global $user;
if (in_array('An Awesome Role', $user->roles)) {
  return 'node/add/page';
} else{
  return 'user';
}

This works for most circumstances, but site admins do actually have the ability to edit the role names, which will mean that if they do your rules will no longer work. This won't happen much, but when it does you will have to update the redirect rules with the new role names. It is possible to use the role ID instead as this won't change, even if the role names are updated. In order to use this you'll need to get the keys of the roles array as the keys contain the role IDs. This can be done using the array_keys() function in the following manner.

global $user;
if (in_array(3, array_keys($user->roles))) {
  return 'node/add/page';
} else{
  return 'user';
}

This means that no matter what you change your user roles to this rule will always work.

PHP

Drupal

Drupal 7

Comments

Permalink

I use Login Destination and use it for this exact purpose, user roles that is. However, I also use LoginToboggan to display the user login form on access denied pages so that a user that tries to directly access a page in which they must login first to view via a bookmark or in my case, a notification email, they can simply login and they will be redirected to the page they were trying to view. This worked perfectly until I used the same logic you describe in Login Destination. Do you know how you would preserve this functionality while still using Login Destination to redirect based on role?

Permalink

I think there is probably an overlap between the LoginToboggan and Login Destination modules, in which case one is overriding the functionality of the other. In this case I think the Login Destination module takes precidence. I haven't tested anything, but I think removing the else block of the if statement in Login Destination should stop it overriding anything that LoginToboggan is trying to do.

Worth a shot anyway...

Permalink

I figured this out and it is very simple to preserve the LoginToboggan functionality. There is a fieldset titled "Redirection Conditions" in the Login Destination settings page. Here, it simply asks, when do you want redirection to occur? I checked the PHP snippet option and entered:

return !isset($_REQUEST['destination']);

This way it won't redirect if another module, like LoginToboggan, has set the destination. I imagine this is not desirable behavior for all situations, but it worked perfectly in my case.

Add new comment

Related Content

Drupal 9: Configuring Drupal To Be An Identity Provider With SimpleSAMLphp

I have previously talked about configuring a Drupal site to authenticate against a remote SimpleSAMLphp install, but as Drupal is an excellent user management system I wanted to turn it around and use Drupal as the identity provider. This means that Drupal would allow users to log into other systems using their Drupal username and password by leveraging the power of SimpleSAMLphp.

Drupal 9: Configuring Drupal To Authenticate Against A Remote SimpleSAMLphp Identity Provider

I have previously talked about installing SimpleSAMLphp using composer, so the next step is setting up the system to actually provide authentication against a SimpleSAMLphp system. As I spend a lot of time using Drupal I wanted to set up the authentication with Drupal and SimpleSAMLphp in order to see how things worked.

First, let's define a couple of terms that are important to this setup.

Installing SimpleSAMLphp Using Composer

Security Assertion Markup Language (SAML) is a standard that passes authentication credentials between hosts and essentially allows for a single sign on solution to be created. The standard uses XML files that get passed between the authentication system (known as the identity provider or IdP) and the service users want to sign into (known as the service provider or SP).

Drupal 9: Creating A GET Form

I've been building Drupal forms for a number of years so I'm quite familiar with to putting together a Drupal form using the FormBase class and the form API. When I attempted to create a GET form this week I realised that there is actually quite a bit to think about. All forms are build using GET requests, it's the submission that I am specifically talking about. By default, forms in Drupal use POST requests to submit their data, and although it is possible to convert a form to use GET to submit data, it isn't well documented.

Drupal 9: Blocking Common Exploit Paths

If you run a Drupal site for any length of time you will quickly realise that a few paths that have nothing to do with Drupal will receive a lot of traffic. All of these paths result in page not found errors so the only impact is taking up your server resources. It's common to see paths like wp-login, xmlrpc.php, phpBB/page_header.php, postnuke/article.php, as well as a multitude of others. These requests are clearly bots probing the site to see what sort of CMS is in use and if they can exploit it or not.

Drupal 9: Changing Config Through Update Hooks

Drupal configuration is normally changed or removed through the configuration import and export process. For example, the process I follow is to make the change in the configuration locally, export the configuration into the source code, deploy the source code to a remote server and import the configuration. Using this mechanism, configuration changes that were exported locally are imported into the site and are ready to use.