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

rbrahmson

Actually the history of that picture is different - some executive who was the top tat at the time was heard referring to us as low hats, so I picked a low hat picture... But I like that cartoon!

hgtonight

@rbrahmson said:

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.

The Yaga.Badges.View permission isn't actually implemented anywhere... yet.

I planned to prevent viewing the frontend display of badges with that permission.

EDIT: https://github.com/hgtonight/Application-Yaga/issues/107

peregrine

@R_J said:
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

Yes, good find. I would think this should be locked up via a permission. You may not want people fishing for names in a private community.

http://vanillaforums.org/dashboard/user/autocomplete?q=r_

I removed all guest permissions, logged out and could search userbase with your technique.

Although, it may a one-off two-off plugin.

I think it would be advatageous to have it built into core to turn off viewing profile pages except by user to view their own page.

rbrahmson

@R_J uncovered another thing I have to block. I see how the masters of the code keep unraveling more holes... I definitely intend to learn and think more about the plugin, but in the meanwhile I implemented these routes:

^dashboard/user/autocomplete([/\?]{1}.)?$ -> non-allowed page
^badges/detail(.) -> non-allowed page
^profile(.*) -> non-allowed page

@peregrine made the point that "it would be advatageous to have it built into core to turn off viewing profile pages except by user to view their own page.". How does such a comment in an obscure discussion about a specific application is going to get the attention of the powers who develop the core? Would my mention of @linc here is enough of a ping (or did I just broke some etiquette rule - if so I apologize in advance).

peregrine

@rbrahmson said: How does such a comment in an obscure discussion about a specific application is going to get the attention of the powers who develop the core?

it won't github pull request is best. if they like it they will do it.

It is certainly be advantageous to you (which I meant) rbrahmson, but not necessarily to other users, so it will probably need to be a plugin. which it is pretty much laid out for you see code and explanations above for plugin.

It won't. order of wing and a prayer vs doubtful vs possilbe

• mention I suggested it in obscure discussion (least likely)
• mention linc or todd or tim
• file a feedback issue on github for enhancement suggestion
• file a pull request with changes and if they like it they will commit it.
• fork vanilla and develop what you want. (most likely)

anecdote: rbrahmson, I suggested once on github "for config or admin ability to stop logging to log file (change log) because it can cause a huge log table if you allow unlimited editing. it was deemed something they didn't care to do. I think I provided code as will in issue. Point being you can try, it doesn't mean it will happen. Worst case they ignore or just close it, but they will see it that way. Best case they implement what you want. Even pull requests might not happen and some do happen. someone has to be the arbiter. and the obvious arbiters of what to do and not to do are the core developers of the product.

rbrahmson

I'm confused -- I indicated that I do plan to try to write the plugin (and I really appreciate the insights in this discussion about writing it). I was referring to the "http://vanillaforums.org/dashboard/user/autocomplete?q=r_" example to which you commented that this should be addressed in the core.
Beyond that, I accept that I have to write a plugin.

peregrine

we are both confused but yes you could file an enhancement request via github, at least it will be put in the flow until pursued or closed.

rbrahmson

Yea, I guess you didn't believe that you and @hgtonight and @Bleistivt (and I hope I didn't forget anyone else) managed to get me to try to code. I can't believe it myself;-)

peregrine

too bad the whole discussion of hiding user information is caught inside a yaga discussion which is only tangentially involved, otherwise you might get more insights from more people who couldn't give a rip about yaga and therefore might not read discussion, but might have the same concerns as you regarding user info.

rbrahmson

So should I "split" the discussion?

R_J

I guess you can name your discussion "John Doe" and it will be read from all developers here. To me the main reason for being completely* ignorant about solutions to your problem is that what you are trying to achieve is very, very bad for a community. Why should a user be isolated to only see his own profile? A user that has a profile will most probably be allowed to read (and write) actions. So he can see other user names in discussions and comments.

The user names of a forum are no secret at all, so there is no reason to restrict autocomplete. Doing a permission check on every call is a waste of time in 99.9% of all installations.

So all the restrictions you might need for your community will be without any use for others. That's why you would have to write your plugin.

@peregrine: Sentences like "the importance of moderator splitting discussions and users creating titles when pursuing digressions. @underdog we miss you." are not constructive. If you know that underdog will not split the discussion, why didn't you simply ask a currently active moderator for splitting/renaming the discussion?
I'm glad I'm not a moderator because I wouldn't know where to split that discussion. But you can certainly choose another name like "Isolating users/restrict access to other users information", although I really doubt that there will be much helpful hints afterwards

---

* = Yes, I do not completely ignore this discussion, I know.

rbrahmson

@R_J : No, the goal is not to prevent all users to see other user's profile - that would indeed be against the idea of a community that communicates (same word root, not coincidentally). What we have is several distinct communities - each assigned few categories and separated by the roles and category permissions. So what we want to allow (and encourage) is communication within each community, but not outside it. The blocking of the profile viewing was a temporary stopgap until I finish writing the plugin that would allow users see the profile of users only in their community (defined by their roles).

Because we expect many distinct communities (but not many members in each) we don't want to have multiple instances of Vanilla. That led to our choice of using category permissions, and the rest follows.

peregrine

totally agree with all of you.

rbrahmson

I actually think that there may be others who may find it advantageous to manage different forums within one Vanilla setup (server). Less administration. Categories permission defined by roles as well as some other plugins (e.g. Rolebased Theme) help make this a reality.

rbrahmson

I am writing the plugin and made some progress. Was able to restrict profile viewing to the user itself and the moderator. Otherwise using "throw PermissionException('admin')" which redirects to a message page with properly formatted message.

The question I have is how to cycle through the user's own roles and the roles of the profile to be displayed to see that there is a match (at least one role in each matches the other). I didn't find a plugin that does something similar so that I could use some of the logic as basis to add to my plugin.

Any ideas?

Below is the plugin code (so far)

<?php if (!defined('APPLICATION')) exit();

$PluginInfo['ProfilePrivacy'] = array(
   'Name' => 'Profile Privacy',
   'Description' => 'Limit profile views to users with the same roles.',
   'Version' => '1.0',
   'RequiredApplications' => array('Vanilla' => '2.1'),
   'MobileFriendly' => TRUE,
   'Author' => "Roger Brahmson"
);
/* Plugin to limit profile views to users with the same roles.
 * Useful for forums that use category permission to create multiple distinct communities
 * within one instant of Vanilla server (that makes administration much easier).
 * In such a setup access to categories is controlled by permission roles.
 * 
 * So the plugin will only allow access to the profile of a user if:
 * 1. The user looks at his own profile
 * 2. The user is anAdministrator
 * 3. The profile user has a role that the user himself has.
 *
 * The plugin also set few routes that disables various ways to get to the list of users
 */
class ProfilePrivacyPlugin extends Gdn_Plugin {
   /* limit profile viewing to own user's profile, admin,and profiles that have a role the user also have*/
   public function ProfileController_Render_Before($Sender) {
      $UserID = $Sender->User->UserID;
      $IsAdmin = Gdn::Session()->CheckPermission('Garden.Users.Edit');
      $AllowView = true;
      if (!$IsAdmin && ($UserID != Gdn::Session()->UserID))  {
         $AllowView = false;
      }
      /*
      **** Code to be written - Cycle through user's own roles and intended profile user's roles 
      *    and look for a match.  If a match is found allow profile viewing (set $AllowView = true)
      */
      if (!$AllowView)  {
         throw PermissionException('admin');
      }
   }
    /* Activate Routes -- THIS DOES NOT WORK - need to investigate -- dashboard/home/permission throws a "Page not found" */
    public function setup() {
        Gdn::router()->setRoute('^dashboard/user/autocomplete([/\?]{1}.)?$', 'dashboard/home/permission', 'Internal');
        Gdn::router()->setRoute('^badges/detail(.*)', 'dashboard/home/permission',  'Internal');
    }
    /* Deactivate Routes */
    public function onDisable() {
        Gdn::router()->deleteRoute('^dashboard/user/autocomplete([/\?]{1}.)?$');
        Gdn::router()->deleteRoute('^badges/detail(.*)');
    }
}

peregrine

@rbrahmson said: I didn't find a plugin that does something similar

if you don't get any more tips. perhaps these meager tips will push you to try harder.

re: role determination

various members related plugins must cycle through roles somehow otherwise they wouldn't be able to display each users role.

most of the role title plugins must deternine roles somehow as well.

you could also use grep or other search tool to search the core software for the word role to see how they determine roles.

then you could have an array of roles for the session user and see if it intersects the array of sender users - that would be either a vanilla functions that deal with arrays, but if a vanilla function didn't exist for array intersection - you could always check out the php site that has examples of array functions.

rbrahmson

@peregrine - good advice. I will look into it.

While coding I uncovered a problem with routing. Ther dashboard routing page has a definition called "DefaultPermission" with a target of "dashboard/home/permission" which is supposed to throw a "not authorized" page (and the documentation confirms that).
Alas, my experience is that instead it throws a "Page not found". Is there something wrong in my 2.1.11 environment or did I uncover a bug?

--> based on @peregrine's good advise below I opened a new discussion to address the routing issue.

peregrine

edited out.

rbrahmson

I took the challenge @peregrine gave me to learn and write a plugin (thank you for the journey!).
The plugin is supposed to only allow users to see their own profiles as well as those who share one of their roles (Admin can see everything).

The plugin figures out who is the user itself and who is the user whose profile the user wants to see using these two statements:

$UserID = $Sender->User->UserID;        /*User of target profile to be viewed  */
$MyUser = Gdn::Session()->UserID;        /*Current user                                    */

It works with one exception - turns out that when the user points to the globe icon (for Notifications) and clicks on it $UserID is not set to any number. So of course the rest of the code that compares $UserID and $MyUser doesn't work.

Any ideas?
P.S. If needed I can post the entire plugin.

peregrine

two possible solutions

you need to check if $UserID is null, but you will notice the url in the notifications has the id in it, so if you need to figure out how to get it if you need it.

or

conversely you could skip permission exception if UserID is null provided guests can't view profiles anway.