Utility Links block is aggressively cached, displays wrong username.

I've had the same issue. Sometimes it is the person who logged in previously, and sometimes it is the same name over and over.

My quick work around just to fix the output on the live sat was to change the display name to simply print "My Profile".

You can do this in the Utilities module :
profiles/commons/modules/contrib/commons_utility_links/commons_utility_links.module
Change the title parameter to My Profile.
Change :
'title' => format_username($account),
to :
'title' => 'My Profile',

Not elegant, but works for now.

Sounds like block caching is an issue. I've seen this before but only on drupal 6 sites. our fix for it was to do what you suggested and remove the username from the block.

Can anyone point to steps to reproduce this problem from a fresh install?

Hi Ezra - I'm not really sure how to reproduce.
In my case, I had a list of 50 email addresses that I used to "pre-register" their accounts.
I would enter in their first name, last name, email address, organization and I assigned the same password for each user.
Then I would check off their pre-assigned Group membership as well as "Notify the User by Email".
The users were emailed the one-time login link and were asked to immediately change their password.
I did all 50 users manually like this.

I then started getting emails from the user saying that their name was not being displayed, but another valid name was being displayed. When they clicked the user name link, it took them to their correct profile.

It was not consistent, and did not happen to every body. In my own testing it was happening every single time - butnot always the same name. I chalked it up to some sort of weird caching, or token issue and moved on.

Sorry I can't provide more detail to the cause.

What are your performance settings set to? do you have block caching on?

Marking as needs more info. Specifically:

• What are the performance settings set to
• Are you using memcache or any other external caching system

These are two examples where I've seen the wrong username show up in the block, for other sites (not commons). Many sites just remove the name to make caching easier.

I'm seeing the same behavior when all default Drupal caching options are enabled on admin/config/development/performance. Disabling "Cache blocks" corrects the issue. This seems curious since commons_utility_links.module specifies DRUPAL_NO_CACHE in commons_utility_links_block_info().

Looking for a workaround I tried DRUPAL_CACHE_PER_USER with no success. One hack that did work was disabling commons_utility_links and simply creating the links inside my theme as a region--header.tpl.php:

<div class="<?php print $classes; ?>">
    <div class="region-inner clearfix">
  <ul class="commons-utility-links">
    <?php global $user; 
    if ($user->uid): ?>
      <li class="name first"><a href="/user"><?php print format_username($user); ?></a></li>
      <li class="logout"><a href="/user/logout">Logout</a></li>
      <li class="settings last"><a href="/user/<?php print $user->uid ?>/notification-settings">Settings</a></li>
<?php else: ?>
      <li class="signup first"><a href="/user/register">Signup</a></li>
      <li class="login last"><a href="/user/login">Login</a></li>
<?php endif; ?>
  </ul>
    <?php print $content; ?>
  </div>
</div>

I have seen this same block behavior on other Drupal (not Commons) sites that supplied user information in a block. I suspect it may be a core bug, but I don't have the code to prove it yet. As I a read the API Docs both DRUPAL_NO_CACHE and DRUPAL_CACHE_PER_USER should work in this scenario. I found a few old issues in the Core Queue that point to similar problems but most are marked as dups of patched issues. I can replicate this problem on both my development environment and production machine with block caching enabled.

UPDATE - added $user->uid to code above to correct omission.

Good idea re: the region--header.tpl.php file.
Thanks for suggesting.

Just noticed I forgot to add $user->uid to Settings link above....

The same problem has arisen in Drupal 6.28.

This is more serious than it at first appears, at least on one of our sites (www.pitchmybook.com) where we have found this problem.

On login as a user, regardless of role (i.e. authenticated or other role)

a) the correct permissions are granted

b) the user account operates with reference to the correct account

so that's as expected.

But,

1. as with others in this discussion, the account name is wrong (in the case of this site, it shows the username of the super-admin user. That's bad.

2. clicking on "track" shows the full history of the super-admin user. That's really bad.

If (and I don't know how this could happen) some other user's details were shown, that would lead to a considerable breach of confidentiality, action under data protection laws and a storm similar to that facing Bloomberg for allowing journalists access to user access data - except here in Drupal it would be even worse because absolutely any user could gain access to that data.

The database shows no hint as why the incorrect data is being picked up.

We have a number of websites where client data security is of vital importance.

Ideas of how to identify and fix this urgently would be welcome.

==============

UPDATE

Found it. Fixed it. And yes, you can all laugh at my dumb mistake.

When creating the menu item for My Account, I had inadvertently copied /user/1

Removing the 1 (but leaving the trailing/) has solved the problem.

I've left this note here so that anyone who has the same problem can see if the same simple fix works for them.

VortexCentrum you may also want to check your permissions on User > View user profiles sounds like your permission settings allow anyone to view another's profile and tracking history and it sounds like this is not the permissions you want for your use case.

The bug described above should be corrected by disabling block caching.

Hi, Stupiddingo

Thanks for that but that wasn't the problem. It was much more fundamental than a permissions issue. But your comment encouraged me to look further into this. The effect of my error was not, as I had first thought, to re-assign the logged in user to become, for one limited purpose, user 1 i.e. superadmin. The limited purpose was in relation to the profile only. In fact, it simply opens the superadmin's user profile page. And that is accessible to anyone who can see profiles just by using /user/n where n is the user's numerical ID. As these are allocated sequentially, it's easy to walk through a full list of users, even if no user list is published.

So that's one security / data protection issue we need to address (although we already do this with a mix of public and private information).

But my stupidity did highlight a risk in Drupal security that I had not noticed before: user activity is available on all profile pages. How this has escaped the data protection monitors I have no idea. It's not a new issue: it was raised here - http://drupal.org/node/288770

It all seems very complicated and ad hoc for something so important. For now, we're just turning off tracking which, of course, has an impact on site management.

You can find a discussion of tracker with a link to a good solution in this comment.

The short version for d6 is go to views, enable the tracker view and change the access permissions to a specific permission (such as access user profiles) or a role.

In this thread is also a link to an issue #762962: Add permissions for the tracker pages and patch (originally for 6.x, but is now a 8.x issue to be backported later). As stated in this issue, this is not a data protection problem, because tracker displays the public content posted by a users after appropriately passing through a "view published content" permission. The "track" tab is a bit of a creepy moniker I'll admit.

Tracker 6.x track tab visibility is unrelated to this issue. If you have more questions about tracker, they would be appropriate in this discussion or this issue. I'd also happily entertain questions if you contact me directly.

To clearly answer #3 & #6

Problem/Motivation

If block caching is enabled the wrong username is displayed in the "Utility Links" section in the upper-right for users with the same role. This error is the result of the block table being written with a cache value of "1" for module "commons_utility_links", delta "utility_links".

Steps to Reproduce

On a clean install:

1. Turn on block caching
2. Login as User1
3. In a new browser login as User2 with the same roles.
   • User1 will appear rather than User2 in the Utility Links section

Additionally, you may manually add the block "commons_utility_links" to your display and it will be enabled with no cache correctly displaying the username, while the utility section configured from the installation profile is set to cache by role and will remain incorrect.

Proposed resolution

Attached are two patches:

• Commons-Install--Wrong-username-displayed_1984068_14.patch
  
  Edits the install of the commons_utility_links/utility_links block to set the cache value to 2 (DRUPAL_CACHE_PER_USER).
• Commons-Utility-Links--Wrong-username-displayed_1984068_14.patch
  
  Updates commons_utility_links_block_info() to less aggressive DRUPAL_CACHE_PER_USER rather than DRUPAL_NO_CACHE. This patch is not necessary to correct the issue above. If DRUPAL_NO_CACHE is in fact what we want, then I can reroll the first patch and omit this patch entirely.

Remaining tasks

Needs review and someone with more experience with block caching to verify the choice of DRUPAL_CACHE_PER_USER is correct for all installations.

So after talking with Ezra, we decided to not have the block be cached for now. Below are two commits to Commons and the Utility Links contrib. We completely moved all block configuration for Utility Links out of the Commons profile install script to the Commons Utility Links hook_block_info.

If at a later point we find out that the need to cache this block is great, and is causing a big enough performance issue, we can reopen and address it at that time.

http://drupalcode.org/project/commons.git/commitdiff/543c084
http://drupalcode.org/project/commons_utility_links.git/commitdiff/c1aef99

Agree with this going forward for now.
I'll run and test. Thanks for the work guys.

I've tried reinstalling commons, and get this error at the top:

The block Commons utility links was assigned to the invalid region header and has been disabled.

So the issue here is that the error message is displayed because the theme 'adaptivetheme_admin' in use as the administrative theme doesn't have a 'header' region, so when the block is enabled, it has nowhere to go for that theme, and is thus disabled for that theme. All the other themes (including Commons Origins) have a header region, and are unaffected.

The attached patch should rectify the problem. Instead of forcing the block into the 'header' region on every theme, simply just update the block for Commons Origins to be in the header region upon install, all other themes it will be disabled by default.

#19 works great in my testing.

Committed to dev.

http://drupalcode.org/project/commons_utility_links.git/commit/811d397

This seems to have caused an issue with a fresh install. The module is active, but the block is not placed nor available in the block administration. Rolling back this commit brings it back.

A patch to stop enabling "extra" themes during installation. The patch also disables the Bartik theme (which is automatically enabled by the system) and switches from using theme_enable() to directly interacting with the database, as is done in standard.install, which saves a number of listings and rebuilds that are unnecessary during installation.

Unfortunately, due to #2011128: theme_disable() can disable the wrong theme writing an update hook to disable any unused themes would be a bit clunky but leaving existing "extra" themes enabled doesn't cause any issues and can be taken care of in a followup.

Tested #24 using a number of fresh installations and haven't seen the error message/block placement problems or run into any issues.

Committed #24 to Drupal Commons 7.x-3.x.

http://drupalcode.org/project/commons.git/commit/03eec5e

The utility links block is not placed on a fresh install, built with build-commons-dev.make this morning.

If I do a manual SQL query to add the block, and re-run the update, it works (displays on page). However it doesn't show up in the block admin UI. Investigating...

Okay I've fixed utility links I believe by creating the db entry instead of updating it. There is no row in the database, so thats why its failing on the update.

http://drupalcode.org/project/commons_utility_links.git/commit/3d6be2a

Stupiddingo: thanks for that. Sorry for late response - several more pressing matters got in the way. I'll have a look at your suggestions. Thanks also for the data protection comment. With this particular site, we've got literally thousands of permissions boxes to tick or not tick, some in multiple layers depending on modules, views, etc. It's a horrendously complex task to make sure the permissions are correct whenever we change anything. So I'm really looking forward to having another set to look at :)