[SOLVED] Should users be able to see other users through YAGA badges?

rbrahmson

Using closed forum. Vanilla 2.1.11 VBS3 theme and categories based permissions. Basically different categories set to different users. We don't want users to see the list of users in another category they have no access to. In testing we realized that users can go to their own profile, look at their earned badges, click on the badge and see all the users that earned the badge (users not permitted to the categories the signed on user has access to) and from there click and see details of these other users.

This is despite setting the YAGA permission for the role of the signed on user as "none" (no permission is checked on).

Initially we had the permission of VIEW checked on thinking that users should be able to see their own badges.

I presume I could try to overcome this by CSS changes (display:none) but I do want users to see their own badges and I think this should be addressed via the permission model.

Am I doing something wrong?

peregrine

We don't want users to see the list of users in another category they have no access to

when you go to conversations and choose add message, do you think that other users cannot see other user names?

sounds like you are going to need add more restrictions than you think via coding or block more access than you assume than just a specific app.

rbrahmson

1. @peregrine - I'm not sure what you exactly mean by "chose add message". How to you get there?
2. The YAGA application has two specific permissions - "View Badges" and "View Reactions", both of which are turned off. It seemed logical to me that when they are turned off the user won't be able to click on his badges to see who else have these badges.
3. In conversations the users can only see the categories they have access to. If they click on the users who participated in these conversations they only see the profiles of others who are authorized to their categories, which is fine. We don't want them to see users in categories they are not authorized to.

peregrine

re: 1

http://vanillaforums.org/messages/add

if you have conversations enabled you can find any user and go to any profile.

re: 2
seems possibly logical and I don't know the intent. I don't use the app, so don't know.

just wanted to point out profiles may not be as obscure and protected as you think they might be and it may not be related to YAGA.

re 3

I'm talking conversations app that comes with core install, not discussion thread

rbrahmson

Thanks @Peregrine, I see this now. This also needs to be closed. Either by disallowing the drop-down or disabling conversations.

Any ideas?

And I'd also appreciate insights into other such "exposures".

peregrine

even if you disable conversations in 2.1.11 (haven't tested 2.2)

you can cycle through profiles via url. just increment the number, name is immaterial.

/vanilla/profile/5/peregrine
/vanilla/profile/6/peregrine
/vanilla/profile/7/peregrine
/vanilla/profile/8/peregrine

you would need to disable viewing profiles. and or only allow a user to view only their own profile (and everything that comes off of profile controller).

on vanilla forums.org - they seem to have gotten away from the userid number for various items in profile and go via name only. it may be evolving.

maybe it is important to you. but after all it is a screen name. so for many people this is a mountain out of a mole-hill.

rbrahmson

Qs: 1. How do I disable the users drop down on conversations?
2. How to capture the profile numbered urls without preventing the user to see his own profile?
3. Probably to @hgtonight - where am I going wrong by disabling permission to view badges and reactions that they won't show up in the profile and furthermore not point to other users?

peregrine

1) override js in conversations perhaps without looking at code get rid of autocomplete. see conversations app to get ideas.

2) probably with a plugin check (if userid is equal to session id) or exit or show "you don't have permission" message before rendering.

3) parially solved if you fix 2.

professional tip: start a new discussion topic with non-yaga related questions for more potential coders for you.

rbrahmson

First and foremost, thank you for staying with me on this issue. I appreciate it!

As a first very quick and very dirty block I added the following route:
^profile(.*) redirects to "discussion/517" Internal

Where that specific discussion simply says "Restricted Access". Alas, as I feared, it also blocked the user from accessing his own profile. Clearly the next step is the suggestion for a plugin.

How does a plugin can check the request to view one's profile? I went to the wiki that lists all the events and found several that refers to the profile. I don't know which one to chose...

As for #3, and your note that it partially solves the issue - I guess you meant that while the list of users will still be visible, the ability to look at their profiles will be blocked.

I even tried another quick-and-dirty block - I used the Chrome inspector and discovered that the list of users who have the badge are all under a css style called "RecentRecipients",so I simply added a "display:none" to that style to hide the list. It worked but unfortunately the line above the list that says "Most recent recipients" still shows and it doesn't seem to have a unique named style to it. Perhaps @hgtonight may voice an opinion about it after the weekend (which I hope he enjoys) - maybe his code adds these lines to the profile.

rbrahmson

To add to the above, I added another redirection rule:
^badges/detail(.*) to point to the "restricted access" discussion. But clearly the plugin solution will be the best.

peregrine

without testing and experimenting can't tell you.

try something with profile and render before.

without looking - Most recent recipients is probably a module. you can remove modules instead. you need to search for removal of modules via site:vanilla.org in google since the search here is fubar for the time being.

if you don't experiment yourself with the different events and you don't start new discussions when pursuing different topics so it helps other people as well,
some people may give up trying to help.

perhaps this with profile views turned off for guests. You need to test all instances.

public function ProfileController_Render_Before($Sender) {

$UserID = $Sender->User->UserID;
$IsAdmin = Gdn::Session()->CheckPermission('Garden.Users.Edit');
  if (!$IsAdmin && ($UserID != Gdn::Session()->UserID))  {
         throw new Exception(T('You do not have permission to view other profiles.'), 401);
      }


}

Bleistivt

I wouldn't recommend using the event list on the wiki. It is out of date and events in vanilla are quite dynamic.

The way to find the right event is either
1. Using the Eventi plugin
2. Reading the code

The latter of course requires to have a basic understanding of vanillas folder structure and how requests are dispatched so you can find the right file.

vanillaforums.org/profile/rbrahmson

if the first thing you see after your forum root is not the name of an application (vanilla, dashboard, conversations), it is a controller name.

So we already have the first part of the event name, ProfileController.

Two useful events that every controller fires are Initialize and the magic Render events.
So without searching for specific events in the code, there are 3 possible events:

1. profileController_initialize_handler - Before the controller logic takes place.
2. profileController_render_before - Before the render process.
3. profileController_render_after - After the render process

3 is obviously too late as the page has already been rendered. 1 looks good, but at this point, the controller doesn't know, which user it displays, so we are left with option 2.

Now it is time to find out where the controller saves which user it currently displays:

profileController_render_before($sender) {
    decho($sender);
}

You should be able to proceed from here. Gdn::session()->User is the session user (you, who is viewing the page). Check out what throw permissionException(); does.

peregrine

lol. Before I saw Bleistivt's post I was just going to tell you Belistivt gives great tutorials as does R_J and a few others on events, controllers, etc.

unfortunately the info is inside a yaga post so if someone is looking at discussion titles they will miss this.

the importance of moderator splitting discussions and users creating titles when pursuing digressions. @underdog we miss you.

The Userid from sender above is the userid of the profile you are viewing.

As far as autocomplete in conversations you might be able to use the technique mtschirs used overriding js with off.

peregrine

if you use var_dump on a live database, you can get into a little trouble I believe, since some if not many fields are not sanitized before entering the database, certain things like alert() in js (xss) etc can get executed because things are not sanitized on output with dump and possibly decho. I haven't looked closely at decho.

e.g. if someone entered some js exploit in the user table via the reason for joining and you var_dump the js will execute iirc.

peregrine

you also have to remove view permissions for activity since user names assuming you don;t want them to see user names, it will be visible there and there goes any wall comments.

rbrahmson

I'm on the road right now and don't want to be rude and ignore the responses- I'll look at all of them carefully tomorrow. Thank you for your support and sharing your knowledge!

R_J

I guess you will not get happy with all of that. There are numerous ways where usernames can be accessed - it is not just profile it is also the UserController: http://vanillaforums.org/dashboard/user/autocomplete?q=rb

I would assume that nearly every controller in Vanilla currently exposes user names or might expose them in future times. So you would not only have to work through each and every controller/model but also keep an eye on them in the future.

If you really want to have such a harsh separation, wouldn't building up more than one community makes sense? I mean what kind of community is it anyway, when your users are not allowed to even now the names of other users?

rbrahmson

@R_J - Perhaps I wasn't clear -- we're using category based permissions so different users have access to different categories. This allows us to maintain and administer a single instant of Vanilla.
We don't mind that users permitted to category X see the names/profiles of users permitted to the same category. In fact we installed the Discuttants plugin which shows the discussions users in the same category - so in fact each category has its own community.

So there are two basic issues here:
(1) YAGA allows access to the list of users earning a badge even though the permission to view them is unchecked. I hope @hgtonight will clarify what's the intended use of this permission setting and whether my expectation that when the View settings unchecked the badges won't show up in the profile.
(2) How to block the profile view of other users (which @peregrine suggested I will do with a plugin).

I may have to pay the price of not allowing users to see any profile other than their own even though I'd rather limit it to users who have different roles (which effectively means that they "belong" to different categories)

peregrine

r_j said: I mean what kind of community is it anyway,

Top Secret. Spies cannot know other spy names.

@rbrahmson said alot of things...

you could find out the role of sessions user and compare it to role of sender (profile) and if roles match allow viewing. There are all kinds things you could do.
if all you want to do is block users from one role from viewing another users from a different role profile
you still have the correct event - just use a different conditional.

if you have mutually exclusive roles it should be easy.

you just have to think about things. looking through core code and other user plugins is a great way to learn, once you have the basics as suggested above comments.

rbrahmson

No spies, just company and subsidiaries departmental separation. If it were spies then one would need a bigger separation than a different Vanilla instant...

R_J

@peregrine said:
Top Secret. Spies cannot know other spy names.

Now I know why I knew that head!