Logging In As Superuser In Drupal 6 SimpleTest

19th May 2011 - 4 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 I will endeavour to correct.

Sometimes the most complex part of using SimpleTest is making sure that everything is working as it should before you start your tests. This means setting up the correct modules and creating the correct content types in advance. Because SimpleTest works by issuing CURL requests to pages the most reliable way of doing certain tasks is to use the administration forms as you normally would. Taking an example, if you want to enable a block from a module you should submit the block form, adding the blocks you need to the various different regions this like.

// Enable the different blocks
$blocks = array(
    'my_awesome_block' => 'header'
);
 
$this->drupalPost('admin/build/block', $blocks, 'Save blocks');

However, if you haven't given the current user 'administer blocks' access, or have forgotten to log them in, then you will get an access denied error when you try to do this.

This is fine when only one form is in question. The problem occurs when when testing complex modules that rely on quite a few other system elements being enabled. Adding a large list of permissions is largely unnecessary and probably irrelevant to what you are trying to test. The best solution to this is to log in as the Drupal superuser and bypass all of the setup permissions issues. This might seem straightforward to do, but when SimpleTest installs Drupal (as it does at the start of every test) it will create a placeholder for the superuser and not activate it. Therefore, to login as the superuser you need to activate the user and reload them so you can log in using that account.

The SimpleTest method drupalLogin() is used to log a user into the system, and this takes a user object as a single parameter. You will also need to add an attribute called 'pass_raw' to the user object before you try to login with it. This is the password in raw text form which SimpleTest will use on the login form.

To log in with the superuser use the following code.

public function setUp() {
    // Enable any modules required for the test.
    parent::setUp('views', 'views_ui', 'views_export', 'profile', 'taxonomy');
 
    // Update the master user so we can use it, setting the username and password fields
    db_query("UPDATE {users} SET name = 'master', pass = MD5('wibble'), status = 1 WHERE uid = 1");
 
    // Load the master user
    $admin_user = user_load(1);
 
    // Give it a pass_raw value so SimpleTest can login with it
    $admin_user->pass_raw = 'wibble';
 
    // Login
    $this->drupalLogin($admin_user);
 
    // run through some complex tasks here...
}

This step is especially important if you are trying to import a view as it turns out that only the superusers can import views. Even if you enable all of the correct modules and give your created user all of the correct permissions you will still get access denied messages if you try to access the import view page.

Before you start your tests it is probably a good idea to log out of the superuser account. This can be done with the drupalLogout() method in the following way.

$this->drupalLogout();

Drupal

Drupal 6

Comments

Permalink

First of all, thanks for the blog post, it really helped me!

Just one thing I'd like to note though; I did manage to successfully access the Views import page with a regular user with all permissions using the following code:

// Create a user with ALL available permissions and log in...
$permissions = module_invoke_all('perm');
$full_user = $this->drupalCreateUser($permissions);
$this->drupalLogin($full_user);
// load the value of a "view export" (stored in a file in my case)...
$view_import = file_get_contents('PATH_TO_FILE_CONTAINING_EXPORT');
// check if you can access the import page (with "verbose message")
$this->drupalGet('admin/build/views/import');
// import the view by submitting the import form
$this->drupalPost('admin/build/views/import', array('view' => $view_import), 'Import');
// now you're on the "edit View" page, and still need to save it!
$this->drupalPost(null, array(), 'Save');

Hope this helps someone...

Permalink

Hi Ben! Thanks for that snippet. Very interesting :)

Add new comment

Related Content

Drupal 9: Some Strategies For Developing Update Hooks

Drupal's update hook system is a powerful way of updating your site to introduce things that wouldn't be handled using the configuration system.

Modules will use update hooks to bring sites that have the old version of the module in line with the latest additions to the module. For example, if a new field is added to a table that the module uses then an update hook will be needed to add that field to all sites that are current using the old version. This update hook will be in addition to the install hook that would install the table with the added field in the first place.

Drupal 9: Cascading Ajax Select Forms

Tying together different select elements in a form is done with very little effort thanks to the ajax and states system built into Drupal 9. This means that any Drupal form can have a select element that shows and updates options into another select element within the same form. Using this system you can create a hierarchical system where one select will show and populate another select element with items dependent on the first. This is great for giving the user the ability to drill down into options that are dependent on each other.

Drupal 9: Preventing Enumeration Attacks

A recent Wired article about the Parler data hack talked about how a hacker group was able to steal publicly available information from the Parler website using an Insecure Direct Object Reference (IDOR) or enumeration attack. This type of attack involves a hacker looking at the structure of the site and attempting to guess the next available resource by looking at the URL. Apparently, terabytes of Parler's data was downloaded by simply enumerating through the ID's of their publicly available posts.

Drupal 9: Auto Injecting Paragraph Forms On Node Edit Pages

I tried to do something the other day that I thought would be quite simple, but turned out to be really hard to get my head around. I had a Drupal 9 site with Paragraphs installed and I wanted a user to click a button on the node edit form and inject a particular Paragraph into a Paragraph field.

I found 2 solutions to this problem that solve it in slight different ways.

Drupal 9: Using Taxonomy Terms To Create A Related Content Views Block

For the last few years I have been tagging articles as I write them on this site. This tagging has largely been to tie posts together in an aggregated list of other posts tagged with that term. I recently wondered if I could use those tags to show related content below each article. I have struggled with this feature on client websites in the past and it either boils down to a manually curated list or some sort of complex content analysis and Solr search.

Drupal 8: Creating Custom Fields In Search API

Pushing data from Drupal into Solr is a really convenient way of creating a robust and extensible search solution. The Search API module has a number of different fields available that can be used to integrate with all sorts of fields, but what isn't included is computed fields or other data.

Thankfully, adding a custom field into the Search API system doesn't need a lot of code. A single class, with an optional hook, is all that's needed to het everything working.