Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I would like to know why the access argument is not the same as the one defined in the core for autocomplete user (access user profiles)
Comment | File | Size | Author |
---|---|---|---|
#32 | username-autocomplete-permissions-d6-1069326-32.patch | 489 bytes | kim.pepper |
#28 | 1069326_username_autocomplete_permissions-D7.patch | 481 bytes | greggles |
#9 | 1069326-autocomplete-access.patch | 1.45 KB | dawehner |
#4 | views.module-autocomplete_user_permission-1069326.patch | 514 bytes | atouchard |
Comments
Comment #1
dawehnerThis seems to be a bug for me.
Perhaps this was just fast written code, and 'access content' is used on hook_menu per default.
Comment #2
sdelbosc CreditAttribution: sdelbosc commentedChanging '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.
Comment #3
qdelance CreditAttribution: qdelance commentedsubscribe
Comment #4
atouchard CreditAttribution: atouchard commentedHere is the patch.
Comment #5
dawehnerMakes totally sense from my perspective.
See
Comment #6
atouchard CreditAttribution: atouchard commentedYes, this access should have the same behaviour. Sylvain is right when he evoked to document this change for running sites (possible side effect).
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedThe 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.
Comment #8
dawehnerJust to record it.
Comment #9
dawehnerHere is a new patch for it.
Comment #10
sdelbosc CreditAttribution: sdelbosc commentedI 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.
Comment #11
ToneUK CreditAttribution: ToneUK commentedI 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
Comment #12
dawehnerAn 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".
Comment #13
ToneUK CreditAttribution: ToneUK commentedWhat 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.
Comment #14
dawehnerOkay sure you could do this, but this is really something which has to be part of a custom module/another contrib module.
And this is a problem :) For example bringing this into the autocomplete framework could be hard.
Comment #15
ToneUK CreditAttribution: ToneUK commentedSo 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 :)
Comment #16
dawehnerSure there is a use case. There might be users which want to filter by the users which wrote nodes.
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedYou can always use hook_menu_alter to change this on your site. That's the most expedient way to deal with this.
Comment #18
gregglesThe patch in #9 seems to me to be ready to go.
Comment #19
merlinofchaos CreditAttribution: merlinofchaos commentedThe 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.
Comment #20
sdelbosc CreditAttribution: sdelbosc commentedWould 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.
Comment #21
crea CreditAttribution: crea commentedSubscribing
Comment #22
greggles@sdelbosc yes, I think that works great. Please post a patch.
Comment #23
dawehner@sdelbosc
You would have to move the access logic to the actual page callback, another access function needs a menu rebuild as well.
Comment #24
deekayen CreditAttribution: deekayen commentedToneUK promoted his sandbox from #11. http://drupal.org/project/username_enumeration_prevention
I'm using ToneUK's code.
Comment #25
kbk CreditAttribution: kbk commentedBump. 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.
Comment #26
nielsvm CreditAttribution: nielsvm commentedIn 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.
Comment #27
gregglesRe #26 - please see http://drupal.org/node/1004778
Comment #28
gregglesAt 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.
Comment #29
tim.plunkettLooks good to me.
Comment #30
gregglesThe 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.
Comment #31
dawehnerThere 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.
Comment #32
kim.pepperHere's a patch for D6
Kim
Comment #33
rbosscher CreditAttribution: rbosscher commentedTested this succesfully on several D6.x installs.
I think it is save to say: RTBC
Comment #34
dawehnerThis is fixed in d7 already ...
Comment #35
DamienMcKennaComment #36
DamienMcKennaThis should be applied to 6.x-2.x too.
Comment #37
eng.anas CreditAttribution: eng.anas commentedI am using views 7.x-3.11, the problem still appear.
Comment #38
greggles@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:
Perhaps your menu cache has not been cleared?
Comment #39
izmeez CreditAttribution: izmeez commentedPatch in #32 applies without difficulty to latest views-6.x-2.26 and is already RTBC.
Comment #40
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedThe 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