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)

CommentFileSizeAuthor
#26 user_17.patch1.11 KBAnonymous (not verified)
#25 user_16.patch706 bytesAnonymous (not verified)
#21 user-db_0.patch2.45 KBkilles@www.drop.org
#20 user-db.patch2.56 KBkilles@www.drop.org
#18 user_access_bug_3.patch11.35 KBkilles@www.drop.org
#17 user_access_bug_2.patch11.26 KBkilles@www.drop.org
#16 user_access_bug_1.patch11.45 KBkilles@www.drop.org
#14 user_access_0.patch9.74 KBBèr Kessels
#12 user-access.patch5.96 KBkilles@www.drop.org
#7 access_users_perm.patch6.46 KBBèr Kessels
#6 user-module-add-view-permission_2.patch1.33 KBdaBrado
#5 user-module-add-view-permission_1.patch1.86 KBAnonymous (not verified)
#4 user-module-add-view-permission_0.patch1.88 KBdaBrado
#1 user-module-add-view-permission.patch1.54 KBdaBrado
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

daBrado’s picture

daBrado CreditAttribution: daBrado commented
FileSize
user-module-add-view-permission.patch1.54 KB

I made a patch that fixed this by adding a new permission, "access users".

This is everything this patch does:

  • Add new permission, "access users"
  • If a user does not have the "access users" permission, s/he cannot read another user's profile at all, and instead gets an "access denied" page.

I hope I did this in the proper way.

Dries’s picture

Dries CreditAttribution: Dries commented
Priority: Critical » Normal

I 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.

Dries’s picture

Dries CreditAttribution: Dries commented
daBrado’s picture

daBrado CreditAttribution: daBrado commented
FileSize
user-module-add-view-permission_0.patch1.88 KB

Another 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.

Anonymous’s picture

(not verified) CreditAttribution: commented
FileSize
user-module-add-view-permission_1.patch1.86 KB

Here 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.

daBrado’s picture

daBrado CreditAttribution: daBrado commented
FileSize
user-module-add-view-permission_2.patch1.33 KB

The 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.

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented
FileSize
access_users_perm.patch6.46 KB

A new and revised patch.
It adds an "access users" permission

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented

I'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.

rkendall’s picture

rkendall CreditAttribution: rkendall commented

I would like this too

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

Can the name be changed to 'view user profiles'?

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented

It 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

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
FileSize
user-access.patch5.96 KB

Updated for CVS. I assumed that "admin users" implies "access users" in user_admin.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented

Does not apply anymore, Ber can you have a look at it?

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented
Component: user.module » user system
FileSize
user_access_0.patch9.74 KB

New patch. Should apply to HEAD.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented

It's a patch (which still applies and wants into core).

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
FileSize
user_access_bug_1.patch11.45 KB

Ok, 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.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
FileSize
user_access_bug_2.patch11.26 KB

Further testing revealed a bug in the older parts of the patch...

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
FileSize
user_access_bug_3.patch11.35 KB

Another iteration: Users should alwys be allowed to see their own user page.

Steven’s picture

Steven CreditAttribution: Steven commented

Committed to 4.6/HEAD.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
Assigned: Unassigned » killes@www.drop.org
FileSize
user-db.patch2.56 KB

We 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.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
FileSize
user-db_0.patch2.45 KB
Anonymous’s picture

(not verified) CreditAttribution: commented

Won'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?

Dries’s picture

Dries CreditAttribution: Dries commented

Where the access checks for the blocks required?

Dries’s picture

Dries CreditAttribution: Dries commented
Priority: Normal » Critical

Also, people can't update their own profile information with this patch. Marking this critical.

Anonymous’s picture

(not verified) CreditAttribution: commented
FileSize
user_16.patch706 bytes

Sorry, here's a patch.

Anonymous’s picture

(not verified) CreditAttribution: commented
FileSize
user_17.patch1.11 KB

The 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.

Dries’s picture

Dries CreditAttribution: Dries commented

Committed to HEAD.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
Priority: Critical » Normal

the database updates weren't applied yet.

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented

Database 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.

Anonymous’s picture

(not verified) CreditAttribution: commented