•  
      request #6509 GET /projects/:id/user_groups returns 403 Forbidden on public project
    Infos
    #6509
    Laurent Delaigue (ldelaigue)
    2014-04-03 17:21
    2014-03-20 08:43
    6580
    Details
    GET /projects/:id/user_groups returns 403 Forbidden on public project
    When I call GET /projects/:id/user_groups, I get a 403, even though I can access
    GET /projects/:id

    GET /projects/:id/user_groups should return an empty list if there is no group i'm allowed to see, but it should never return 403 Forbidden if GET /projects/:id does not return 403 Forbidden. (Any resource listed by GET /projects/:id should be accessible with the same credentials as /rpojects/:id)
    API
    6.11
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    New
    Empty
    Attachments
    Empty
    References
    References list is empty

    Follow-ups

    User avatar
    I was not aware of all this.

    I'm wondering if it's useful to get the ID of a submitter for comments, attachments, or artifacts.
    Maybe it'd be better to get a JSON object with id and label (where label is the name of the user or its login or whatever it is that Tuleap can use to indicate a user to a human being in a friendly manner, because the ID of a user is an integer, which is not usable).
    The only reason why we used user groups and users was to be able to display a human-readable label when we got a user ID.

    I think that the API must not leak user groups and users if they are parameterized as private, but it needs to provide a usable label for submitters (of attachments, comments, artifact).

    An additional route that we could call when we meet a user ID has the same aythorization issues as users and user_groups I think: it opens a backdoor to get all the users of a server.
    User avatar

    Well, there are 2 contexts:
    - First, we got users and user groups via SOAP when retrieving the server configuration, so we reproduced the exact same retrievals via REST
    - Second, when we retrieve comments, it looks like we get the ID of a user, and we attempt to display the user name. Maybe this is a mistake, but that's what was done when we used the SOAP API

    In both cases, you don't need the user group info but rather a dedicated user route or did I miss something ?

    The user route would still have an issue as you can loop on all ids to gather the platform user list.

    I'm beginning to feel that we could get rid of this if it's related to security issues.
    Nevertheless, be aware that the API leaks lists of users when providing the tracker configuration since sb and msb bound to users or user groups provide the lists of users (for each provided artifact, which may also increase a bit the required bandwidth)

    Yes but in this context, the tracker admin populated the field with a list of value. If one decide that the list of "tracker assignee" can be visible on the web site (hence field values) there is no reasons we don't add this info at REST level.

    But if one want to keep user and groups information confidential, we should not leak it;

    User avatar
    Well, there are 2 contexts:
    - First, we got users and user groups via SOAP when retrieving the server configuration, so we reproduced the exact same retrievals via REST
    - Second, when we retrieve comments, it looks like we get the ID of a user, and we attempt to display the user name. Maybe this is a mistake, but that's what was done when we used the SOAP API

    I'm beginning to feel that we could get rid of this if it's related to security issues.
    Nevertheless, be aware that the API leaks lists of users when providing the tracker configuration since sb and msb bound to users or user groups provide the lists of users (for each provided artifact, which may also increase a bit the required bandwidth)

    For info, Mylyn uses mechanisms to display the gravatar of a person when the relevant info is provided but we don't use this feature for the moment.
    User avatar
    It's worst than that.
    As of today, there is no mean to get the list of users and list of groups if you are not project admin.

    Actually, through the web interface, the only mean to get this information is to
    - (for list of ugroups) setup a field in a tracker that is binded to user_groups
    - (for list of users) setup a field in a tracker that is beinded to user

    and in both cases, you should be granted read permissions on this field/tracker !
    User avatar
    I'm not sure I fully understand your answer.
    I'm ok to not receive the lists of users and/or user_groups that I'm not supposed to be allowed to see.
    But I hope it doesn't mean that I won't see the users and user groups of projects I'm a member of!

    Is it true that the issue is only with public projects that I'm not a member of?
    User avatar
    We can make the modification but it will not solve the initial issue "list of groups and users are supposed to be a confidential data".
    Hence it would mean that, as long as you are not a project admin, you will not have access to the list of groups and the users.

    Is that ok for you?