access arguments on admin/views/ajax/autocomplete/user ajax call

This seems to be a bug for me.

Perhaps this was just fast written code, and 'access content' is used on hook_menu per default.

Changing 'access content' to 'access user profiles' will have an impact on running sites. The possible side-effect is to provide user filtering on views to users which do not have 'access user profiles' permission. These users will no more have access to the autocomplete feature.

Such change needs to be document.

subscribe

Here is the patch.

Makes totally sense from my perspective.

See

  $items['user/autocomplete'] = array(
    'title' => 'User autocomplete',
    'page callback' => 'user_autocomplete',
    'access callback' => 'user_access',
    'access arguments' => array('access user profiles'),
    'type' => MENU_CALLBACK,
    'file' => 'user.pages.inc',
  );

Yes, this access should have the same behaviour. Sylvain is right when he evoked to document this change for running sites (possible side effect).

The problem is that access user profiles doesn't necessarily imply that usernames aren't accessible. I've had this conversation before and I am a little leery of this.

dereine: Ok, I'm up for this: Make it a checkbox on the advanced settings page that defaults to the more restrictive condition. The checkbox can open it up.

Just to record it.

Here is a new patch for it.

I am not sure to understand what you mean by access user profiles doesn't necessarily imply that usernames aren't accessible.

As access user profiles is the permission used by Drupal core to limit access to the autocompletion on users, I thought views should use the same permission.

I have just been creating a module that makes the password reset form more secure by preventing usernames from easily being found out. See http://drupal.org/sandbox/ToneUK/1150376 for more details. I was then told it is easier than using the password reset form for gathering username because of the Drupal and views callbacks.

Is there any way that admin/views/ajax/autocomplete/user can be restricted to calls made internally and not by someone directly accessing the URL?

Cheers

An autocomplete request is nothing else than another browser request, so it's technical not a big difference between accessing the url with the browser or the js of the browser does the same.

The only thing you can do is to restrict the access to users by a certain permission. This patch allows to set the permission "access user profiles".

What about making calls to the callback require an extra parameter posted using POST and then the callback checks for this parameter. If the parameter does not exist then deny access to the callback. This would stop people accessing the callback via the URL and make it allot harder to run the callback.

Okay sure you could do this, but this is really something which has to be part of a custom module/another contrib module.

 make it allot harder to run the callback.

And this is a problem :) For example bringing this into the autocomplete framework could be hard.

So the patch is the answer then? Will this patch be included in a new release and will it be in Views 3? I will just document the issue in the module I have created and advise on information about views and what version number it can be disabled in.

What's your thoughts on making the callback filter out administration users but only when it is for someone trying to access the callback anonymously? Can you see any reason why the callback would need to display the admin user when accessed anonymously?

Just a thought :)

Sure there is a use case. There might be users which want to filter by the users which wrote nodes.

You can always use hook_menu_alter to change this on your site. That's the most expedient way to deal with this.

The patch in #9 seems to me to be ready to go.

The patch in #9 will work except that it requires a menu rebuild to take effect and updating the settings page will not make that happen. Perhaps a more intelligent callback would be better, since a menu rebuild would be annoying.

Would the code below be better?
I did not test it but if everyone is ok with the principle I will do it and submit an update of the patch given in #9.

/**
 * Custom access callback for user autocomplete 
 */
function views_access_user_autocomplete() {
  $access_permission = 'access user profiles';
  if (!variable_get('views_autocomplete_user_access_user_profiles', TRUE)) {
    $access_permission = 'access content';
  }
  return user_access($access_permission);
}

Subscribing

@sdelbosc yes, I think that works great. Please post a patch.

@sdelbosc
You would have to move the access logic to the actual page callback, another access function needs a menu rebuild as well.

ToneUK promoted his sandbox from #11. http://drupal.org/project/username_enumeration_prevention

I'm using ToneUK's code.

Bump. Please mark this as "Won't fix" if it's not going to see any action. Others will then know their next best choice is to use the module in #24.

Edit: Also, should this be marked "Major" or "Critical"? It seems like a security vulnerability.

In my humble opinion this should be marked as a security vulnerability of which many, many site owners are unaware and probably don't want the default behavior to be like this. Even with the default brute force protection built-in in the D7 version it's easy to create a slow crawler that fetches the user names in a few days I think.

I'm also pretty sure that several privacy watchdogs throughout Europe would identify this as data leakage, and thus a privacy breach.

Re #26 - please see http://drupal.org/node/1004778

At this point, this should be fixed in D7 first and in D7 the argument is much simpler: usernames should not be exposed unless a user has "access user profiles."

Attached patch simply does that.

Looks good to me.

The d6 backport is a little less clear whether that is the right permission as its not used quite so consistently, but I would still be in favor of it personally. I think the checkbox is just exposing too much and that people should use hook_menu_alter to re-enable this callback if they need to. Basically: sane defaults that can be overridden in a manner that's appropriate to the frequency and importance of the task.

There is a d8 issue which integrates the features of views autocomplete in the core one, so need to think about that.

Thank you for pushing this forward.
Committed and pushed.

Here's a patch for D6

Kim

Tested this succesfully on several D6.x installs.
I think it is save to say: RTBC

This is fixed in d7 already ...

This should be applied to 6.x-2.x too.

I am using views 7.x-3.11, the problem still appear.

@eng.anas - I see it's fixed in http://cgit.drupalcode.org/views/tree/views.module#n371 and it was committed in 2012 http://cgit.drupalcode.org/views/commit/views.module?id=1e5d9fa77416a2b7...

So...it sure *should* be in 7.x-3.11. And this wget + grep seems to show that it is fixed:

➜ ~/junk wget http://ftp.drupal.org/files/projects/views-7.x-3.11.tar.gz
--2015-06-25 08:25:53-- http://ftp.drupal.org/files/projects/views-7.x-3.11.tar.gz
Resolving ftp.drupal.org... 23.235.40.249, 23.235.44.249
Connecting to ftp.drupal.org|23.235.40.249|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1649389 (1.6M) [application/octet-stream]
Saving to: 'views-7.x-3.11.tar.gz'

views-7.x-3.11.tar.gz 100%[=======================================================================================================================================================>] 1.57M 1.90MB/s in 0.8s

2015-06-25 08:25:54 (1.90 MB/s) - 'views-7.x-3.11.tar.gz' saved [1649389/1649389]

➜ ~/junk tar zxf views-7.x-3.11.tar.gz
➜ ~/junk cd views/
➜ ~/j/views grep -C 5 admin/views/ajax/autocomplete/user views.module
'type' => MENU_CALLBACK,
'file' => 'includes/ajax.inc',
);
// Path is not admin/structure/views due to menu complications with the wildcards from
// the generic ajax callback.
$items['admin/views/ajax/autocomplete/user'] = array(
'page callback' => 'views_ajax_autocomplete_user',
'theme callback' => 'ajax_base_page_theme',
'access callback' => 'user_access',
'access arguments' => array('access user profiles'),
'type' => MENU_CALLBACK,
➜ ~/j/views

Perhaps your menu cache has not been cleared?

Patch in #32 applies without difficulty to latest views-6.x-2.26 and is already RTBC.

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue