Check for access to autocomplete paths during form building

Running into the same issue. I did not upgrade, creating a site from scratch.

In my case the field is public, so there should not be a permission issues.

As far as I can tell form auto-completion is completely broken.

You need to give your users (both anonymous and authenticated) the "access user profiles" permission for this to work.

It is absolutely necessary that my users cannot access other users profiles. Giving access to anonymous users to my users' profiles is an absolute NO. So auto-complete (which worked in drupal 5 and my users could not access other users profiles, and anonymous users could not access profiles at all) is now broken 'by design' in drupal 6?

The change was made (apparently without much discussion) in #115315: Fix autocompletion (new menu system), reopening because I can't understand the rationale behind it.

Also bumping version because the same problem is present in D7.

Thanks!

To fix:

@@ -92,7 +92,7 @@ function profile_menu() {
$items['profile/autocomplete'] = array(
'title' => t('Profile autocomplete'),
'page callback' => 'profile_autocomplete',
+ 'access callback' => TRUE,
- 'access arguments' => array('access user profiles'),
'type' => MENU_CALLBACK,

Effectively removing half of the patch referenced in comment 4.

I will try to get around to rolling an official patch.

Magnity patch.

No objection to the patch.

subscribing

Patch seems reasonable to me too, and the 403 error is bad. Not tested though.

Test (from the testing party) here: #293490: User autocomplete gives 403 errors with certain combinations of permissions

According to #8 and #10.

Credit to Magnity

The problem with this patch is that it now becomes possible for anonymous users to retrieve a list of all user names in the system. Imagine you have a porn site, and people use their real name as their user name ... Imagine the same for a client side, an e-commerce website, etc. This is an information leak that seems highly unwanted ...

@Dries : the solution is add special permission like access_profile_autocomplete ?

If we show the author field, the auto-complete should work regardless of any permissions. It might be the case that we need to move user_autocomplete to the node module and perform node.module specific access checks on it. Then repeat that for all other modules that have forms that use auto-completion on the username list.

Just make a node module specific callback function that checks the right permission, and call a private helper function in user.module.

What if we just disable the auto-complete if the current user doesn't have access to user profiles? Tested and seems to work.

But if you add profile fields to the registration form, and anonymous users try to autocomplete (without the permission), then you still get a 403 no? Not tested, but this seems like the original steps to reproduce.

With the patch in #17, if anonymous user doesn't have permission to access user profiles, then the registration fields don't have an autocomplete, hence no 403. The registration fields will have auto-complete enabled if anonymous users have the permission enabled.

@Dave that sounds like a decent way to handle it. I think we should include a test for it though. #293490: User autocomplete gives 403 errors with certain combinations of permissions found a similar issue with user autocomplete

Revised patch with a profile autocomplete test. 48 passes 0 fails!

Minor additions and changes to autocomplete test. 50 passes, 0 fails!

I'm going to change this to the forms system because after doing a little research, it would be easier and more elegant to cut this problem off during form generation. The function theme_textfield in form.inc just checks if there is an autocomplete path specified but nothing more:

In the latest patch here, I added a check to menu_valid_path to make sure that the current user has access to the autocompletion path:

If the autocompletion path is an external url, it will still pass, and if a user does not have access to the autocompletion path, the autocompletion forms stuff is never added. A developer can simply specify $form['element']['#autocomplete_path'] = 'my/valid/path'; and the FAPI system will automatically do the checking and seems like a much more elegant and forward-looking solution. I have added a test for user autocompletion and profile autocompletion that pass along with all other tests on my install.

This should get backported to D6 once finished. Marked #186001: Textfields shouldn't use autocomplete for users without permission as a duplicate of this issue.

This is duplicate with #186001: Textfields shouldn't use autocomplete for users without permission. However, this one actually has a patch and more discussion, so I'm going to leave this one open and mark my older issue duplicate...

This is the right solution to the problem. We should just prevent the bug in FAPI for all autocomplete text fields, not just specifically for profile.module. #186001 started life as a bug report against project_issue, but we decided we should really fix it in core, not just project_issue.

Anyway, I rerolled the patch to remove an unnecessary hunk against profile.module, and to remove fuzz. I also tested and it does exactly what it's supposed to. This is hereby RTBC.

Once this lands in HEAD, we'll definitely need to reroll it for D6 and D5. At least D6 still has menu_valid_path() -- as I wrote at #186001 I'm not sure how to do the same thing with the D5 menu API... Let's talk about that more once this one lands in D7 and D6.

In D5, my crazy theory from #186001 was this:

"_menu_item_is_accessible() is supposedly private to menu.inc, and operates on menu ids (mids). Do I have to call menu_get_item() and then use this private function directly?"

chx informs me this can't work because of #88707: Make menu_set_active_item a complete inner redirection. :( This might just be permanently broken in D5, and we're going to have to un-duplicate #186001 and fix this bug in project_issue after all. ;)

Oh, I just noticed the attachment didn't work from #25. Lemme try again...

Here is the D6 backport patch as well. Not including the tests since D6 core does not have tests.

Updated D7 patch with 500% of your daily recommended dose of test documentation!

Nice. I like this patch because the field is still functional (you can continue to enter values in it) but it does not reveal any personal information. It's also a generic solution that'll work across any type of autocomplete.

Committed to 7.x. Moving back for consideration in 6.x.

Er. :)

And sorry, not sure how I unassigned Dave.

I'm insulted! :) For 6.x, see #28 for patch.

Looks good, committed to 6.x right away.

I did a brand new install of 6.6 this weekend. Even as user #1 I cannot use autocomplete without getting an error after every few letters that I type. For example, when you try to add a new field in the user profile, the category is a autocomplete field and I get errors (unless I type at blazing speed and quickly hit the tab key to get out of the field).

Automatically closed -- issue fixed for two weeks with no activity.

This patch prevents using custom built scripts for autocomplete functionality. I wrote my own /autocomplete.php script with heavy caching, and now I can't use it without core hack.

In response to the missing comment, if you make your autocomplete path a full, exteral URL, it will work. instead of 'autocomplete.php', use 'http://mysite.com/autocomplete.php'. Or you can also use url('autocomplete.php', array('absolute' => TRUE));