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 upgraded my Drupal 5 site to Drupal 6, and now whenever a user types a character in an autocomplete profile field on registration they get a popup dialogue saying: "An HTTP error 403 occurred. http://www.example.com/profile/autocomplete/1".
MySQL database 5.0.51a
PHP 5.2.4-2ubuntu5.2
Web server Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.2 with Suhosin-Patch
Searching around it would appear this could be a permissions problem - anonymous users cannot access user profiles in my setup, it would be an issue for me to change this permission, but I did not get this error in Drupal 5.
Comment | File | Size | Author |
---|---|---|---|
#29 | autocomplete-access-284887-29-D7.patch | 7.13 KB | Dave Reid |
#28 | autocomplete-access-284887-28-D6.patch | 1.67 KB | Dave Reid |
#27 | 284887_autocomplete_perm_check.d7.27.patch | 6.1 KB | dww |
#23 | profile_autocomplete.patch | 6.56 KB | Dave Reid |
#22 | 115315.profile_autocomplete.patch | 4.38 KB | Dave Reid |
Comments
Comment #1
mariuss CreditAttribution: mariuss commentedRunning 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.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedYou need to give your users (both anonymous and authenticated) the "access user profiles" permission for this to work.
Comment #3
Matt BIt 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?
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe 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.
Comment #5
Matt BThanks!
Comment #6
Magnity CreditAttribution: Magnity commentedTo 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.
Comment #7
lilou CreditAttribution: lilou commentedMagnity patch.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commentedNo objection to the patch.
Comment #9
arhak CreditAttribution: arhak commentedsubscribing
Comment #10
catchPatch seems reasonable to me too, and the 403 error is bad. Not tested though.
Comment #11
catchTest (from the testing party) here: #293490: User autocomplete gives 403 errors with certain combinations of permissions
Comment #12
lilou CreditAttribution: lilou commentedAccording to #8 and #10.
Credit to Magnity
Comment #13
Dries CreditAttribution: Dries commentedThe 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 ...
Comment #14
lilou CreditAttribution: lilou commented@Dries : the solution is add special permission like
access_profile_autocomplete
?Comment #15
Dries CreditAttribution: Dries commentedIf 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.
Comment #16
lilou CreditAttribution: lilou commentedComment #17
Dave ReidWhat if we just disable the auto-complete if the current user doesn't have access to user profiles? Tested and seems to work.
Comment #18
catchBut 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.
Comment #19
Dave ReidWith 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.
Comment #20
catch@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
Comment #21
Dave ReidRevised patch with a profile autocomplete test. 48 passes 0 fails!
Comment #22
Dave ReidMinor additions and changes to autocomplete test. 50 passes, 0 fails!
Comment #23
Dave ReidI'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.
Comment #24
Dave ReidThis should get backported to D6 once finished. Marked #186001: Textfields shouldn't use autocomplete for users without permission as a duplicate of this issue.
Comment #25
dwwThis 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.
Comment #26
dwwIn 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. ;)
Comment #27
dwwOh, I just noticed the attachment didn't work from #25. Lemme try again...
Comment #28
Dave ReidHere is the D6 backport patch as well. Not including the tests since D6 core does not have tests.
Comment #29
Dave ReidUpdated D7 patch with 500% of your daily recommended dose of test documentation!
Comment #30
webchickNice. 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.
Comment #31
webchickEr. :)
And sorry, not sure how I unassigned Dave.
Comment #32
Dave ReidI'm insulted! :) For 6.x, see #28 for patch.
Comment #33
Gábor HojtsyLooks good, committed to 6.x right away.
Comment #34
teacherguy CreditAttribution: teacherguy commentedI 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).
Comment #35
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #36
EdgarPE CreditAttribution: EdgarPE commentedThis 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.
Comment #37
Dave ReidIn 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));