Closed (fixed)
Project:
Drupal core
Component:
user system
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
17 Nov 2003 at 05:23 UTC
Updated:
5 May 2005 at 14:15 UTC
Jump to comment: Most recent file
When anonymous visitors do not have "Access userlist" permission, they can still view all the public info in user profiles.
Drupal sites that are created for a group of friends or for an organization want to protect their e-mail addresses, telephone numbers and so on, while making these accessible to fellow members.
This could be a critical feature request, but since I think it's an error, I'm sending you this as bug.
(I don't have CVS, so I'm hoping someone else will make the simple correction needed to the user module)
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | user_17.patch | 1.11 KB | Anonymous (not verified) |
| #25 | user_16.patch | 706 bytes | Anonymous (not verified) |
| #21 | user-db_0.patch | 2.45 KB | killes@www.drop.org |
| #20 | user-db.patch | 2.56 KB | killes@www.drop.org |
| #18 | user_access_bug_3.patch | 11.35 KB | killes@www.drop.org |
Comments
Comment #1
daBrado commentedI made a patch that fixed this by adding a new permission, "access users".
This is everything this patch does:
I hope I did this in the proper way.
Comment #2
dries commentedI think we should not introduce a new permission but merge with the existing 'access user list' permission (or rename it to 'access users'). Marking this "won't fix" until the patch has been udpated.
Comment #3
dries commentedComment #4
daBrado commentedAnother patch, this time renaming the permission "access user list" to "access users", and adding a check in the user viewing function to only allow users with this permission to view the user information.
Comment #5
(not verified) commentedHere is a patch again, now for CVS. Does the same thing as above.
It is a very simple patch. If it seems proper, I hope that can be included before it goes stale.
Comment #6
daBrado commentedThe previous patch was accepted, but then for some reason reversed as part of another CVS commit.
So, here is a new patch that brings back the "access users" permission. It controls whether or not a user may view other users info.
Comment #7
Bèr Kessels commentedA new and revised patch.
It adds an "access users" permission
Comment #8
killes@www.drop.org commentedI'd like to see this patch applied to cvs before the 4.5 release. Now that we can protect our nodes from unauthorized access it just makes sense to protect our user data as well. In the future I'd like to see scheme where the user (as in end-user) is able to selet which of his data gets published.
Comment #9
rkendall commentedI would like this too
Comment #10
drummCan the name be changed to 'view user profiles'?
Comment #11
Bèr Kessels commentedIt can, but I used "access" for consistancy. we have "access newsfeeds", "access comments", "access etc".
This patch is critical for corporate sites btw. A corporate site that has its customers information lying on the streets (so to say) is not-done.
Ber
Comment #12
killes@www.drop.org commentedUpdated for CVS. I assumed that "admin users" implies "access users" in user_admin.
Comment #13
killes@www.drop.org commentedDoes not apply anymore, Ber can you have a look at it?
Comment #14
Bèr Kessels commentedNew patch. Should apply to HEAD.
Comment #15
killes@www.drop.org commentedIt's a patch (which still applies and wants into core).
Comment #16
killes@www.drop.org commentedOk, updated patch. Includes changes to format_name to only display unlinked username for non-privileddged users. 'acccess users' is now 'access user profiles'. The search users tab won't get displayed either if you are not allowed to seee user profiles. The patch got even tested.
Comment #17
killes@www.drop.org commentedFurther testing revealed a bug in the older parts of the patch...
Comment #18
killes@www.drop.org commentedAnother iteration: Users should alwys be allowed to see their own user page.
Comment #19
Steven commentedCommitted to 4.6/HEAD.
Comment #20
killes@www.drop.org commentedWe found that users should not wonder why they cannot see other users' pages anymore. DB update required.
Patch for HEAD attached, 4.6 to follow.
Comment #21
killes@www.drop.org commentedComment #22
(not verified) commentedWon't the way the upgrade numbers don't match up between 4.6 and HEAD eventually cause problems for 4.6 users that upgrade to 4.7?
Comment #23
dries commentedWhere the access checks for the blocks required?
Comment #24
dries commentedAlso, people can't update their own profile information with this patch. Marking this critical.
Comment #25
(not verified) commentedSorry, here's a patch.
Comment #26
(not verified) commentedThe previous patch was for the "can't edit profile pages" problem. This patch here removes the access checks for the blocks. I'd leave them in, but have no strong feelings about either way.
Comment #27
dries commentedCommitted to HEAD.
Comment #28
killes@www.drop.org commentedthe database updates weren't applied yet.
Comment #29
killes@www.drop.org commentedDatabase updates were deemed unnessesary. I am not too happy about that, as I recall the many issues that people had when nobody could see any content on their site due to a not set permission. Oh well.
Comment #30
(not verified) commented