•  
      story #7813 grant restricted users access to git repositories
    Summary
    project admin
    grant restricted users access to git repositories
    I can have open source projects where everyone can access my repositories on my "restricted" platform

    Enable the feature (as project admin)

    • A project admin must enable this possibility at project level. For public projects only
      • When the feature is enabled, there is a log in history to keep track of this
      • A warning is displayed to ensure admin understands what is doing. The warning includes:
        • Info about project being listed in Project tree
        • Info about services being listed (but not accessible)
        • Info about the summary page being public (with all widgets without specific permissions checking)
      • There is a forge upgrade to explicitlely change all "all_users/anonymous" to "registered users" when the platform is configured to forbid anonymous access
    • When the project admin revoke the option, the permissions granted to "authenticated users" already set are revoked.
      • It means that when you untick "use restricted users" option as a project admin, you will have to set permissions on "restricted users" again if you reactivate this option in the future
      • The other permissions are not affected
    • When the option is activated, the project is listed in "project tree" and trove cat
    • When a restricted user access this project, nothing but Git service is actually browsable. Only 'git' and 'summary page' services are displayed.
    • As long as no repository is granted to restricted users, the repository list is empty

    Usage (as git admin)

    • In permissions section, the permission select box displays:
      • Anonymous users (correspond to all_users) only displayed is the platform allows it
      • Authenticated users (corresponds to previous registered_users + restricted)
      • Registered users (to be renamed to something smarter)
      • Project members
      • ...

    API impact:

    • When permissions are used in API (REST routes on /git), the permissions are listed as:
      • Anonymous => all_users
      • Authenticated => authenticated_users
      • Registered/New name => registered_users
      • ...
    • In other terms, the technical names in the API doesn't change but we introduce "authenticated_users" as a new possibility.

    Site admin:

    • "$sys_allow_anon" and "$sys_allow_restricted_users" parameters needs to be imported as DB configuration elements (now they are in /etc/tuleap/conf/local.inc). With a forge upgrade
    • We need to manage it in DB (and with site admin configuration panel because we need to detect the change of those settings to properly update repository permissions.
    • Changes to be propagated:
      • When the site admin disable usage of anonymous:
        • All git repositories granted to "Anonymous" are updated to be granted to "Registered"
      • When the site admin disable usage of Restricted users:
        • All git repositories granted to "Authenticated" are updated to be granted to "Registered"
        • Project admin use of "Authenticated users" group is revoked
      • Those changes are recorded in project history

    Technical background:

    • This need to be placed in a new code (permissions.php is rotten) with a clean and tested implementation
    • The objective is to validate the new code with git and to progressively deploy it for all services once it's validated
    • When completed for all services, the custom "restricted_user_permissions.txt" (site-content/en_US/include will be removed)
    Empty
    Nouha Terzi (terzino), Denis PILAT (denis_pilat), francois jean-marie (francoisjean-marie)
    Status
    Done
    Development
    Empty
    Empty
    Details
    #7813
    Manuel Vacelet (vaceletm)
    2015-04-28 08:54
    2015-01-29 16:57
    7144

    References

    List of items referenced by or referencing this item.

    Git commit

    Artifact Tracker v5

    Follow-ups

    • User avatar
      • Status changed from On going to Done
    • User avatar
      Not at all, we will inform you when you can fully test it.

      What you can test as of today is the fact that some local.inc parameters (sys_allow_anon and sys_allow_restricted_users) have been moved to the database and are managed via a dedicated interface.
    • User avatar
      Is this feature fully working? Can we test it on tuleap 8.0.99.8.?
    • User avatar
      gerrit #3801 integrated into Tuleap 8.0.99.2
      gerrit #3804 integrated into Tuleap 8.0.99.7
    • User avatar
      List of changesets (thus far):

      gerrit #3801
      gerrit #3804
      gerrit #3802
    • User avatar
      • Status changed from To be done to On going
    • User avatar

      * About propagation in gitolite permission: do you take care of this propagation that must not take hours or days to compute ? Today some changes in git pemissions can take 15 min to execute for a single projet.

      It's not covered by this story.

      * About "naming", it still not very explicit.
      ** How will you call the project option at user level to activate/unactivate this feature

      ATM, it would be something like "Allow access to Restricted users" but we are open to better proposal

      ** Why trying to find generic names ? ("Anonymous users", "Authenticated users" and "Registered users").
      I suggest you insert section in site_contents (or wherever) so that we can remane them explicitely to something meaningfull for user, ie 
      "Authenticated users" will become "ST Emlpoyees & Contractors"
      "Registered users" will become "ST employees"

      Customisation a site level comes for free you will be able pick your own naming.

       

    • User avatar
      2 points:
      * About propagation in gitolite permission: do you take care of this propagation that must not take hours or days to compute ? Today some changes in git pemissions can take 15 min to execute for a single projet.
      * About "naming", it still not very explicit.
      ** How will you call the project option at user level to activate/unactivate this feature
      ** Why trying to find generic names ? ("Anonymous users", "Authenticated users" and "Registered users").
      I suggest you insert section in site_contents (or wherever) so that we can remane them explicitely to something meaningfull for user, ie
      "Authenticated users" will become "ST Emlpoyees & Contractors"
      "Registered users" will become "ST employees"

      Thanks
      Denis

      • Acceptance criteria
    • User avatar

      Changes after estimation by the team:

      • Don't list all services (only git and summary will be displayed): it adds extra modification of all services to manage properly access of "Authenticated Users" with permissions denied.
      • Need to take into account the change of platform configuration (From "access granted to everybody" to "no anonymous + restricted"): when the site admin will change those settings, the default permissions of git respositories must be updated. For instance if a git repo was accessible to anonyous and the platform became restricted, the repo permissions must be set to "Registered users" only.

      • Acceptance criteria
    • User avatar
      Update of the spec after discussion with end users

      • Acceptance criteria
    • User avatar

      1/ "When a restricted user access this project, nothing but Git service is actually browsable": Do you mean the main page or any other page won't be accessible to restricted users ?

      Yes it's the initial proposal but we could also propose to see:

      • The summary page
      • All services

      In this situation, all services but would trigger a "permissions denied"

      I would be better for users (just git service without even description of the project would be a bit harsh) but would disclose a bit of information (like the list of used services). What do you think ?

      2/ How will they know the Git project URL ? (knowing that restricted users don't have access to project tree in our configuration)

      The proposal is to make those specific project listed in the project tree, even for restricted (the restricted users would see a tree with just their projects and those special/open projects).

      About usage: it isn't worth having a dedicated group named "restricted user". Registered user is enough to say thaht even "restricted" one's are granted.
      It's easier for the project admin who doesn't need to do anything apart from the enabling at project level, and easier for you, so cheaper !

      Ok, I didn't understand it could be done this way, I'll check with the team.

      I would suggest that, in this case, the label "registered_users" should be "Registered and restricted users" so the information is crystal clear at everytime. What do you think ?

      Would the project "enable flag" be available only at site admin level ? (A kind of plugin like activation)
      Even if the "warning message" must be visible to all project users.

      The proposal is to make it available to all administrator of public projects, without any intervention of site admin. Is that too risky ?

       

    • User avatar
      Would the project "enable flag" be available only at site admin level ? (A kind of plugin like activation)
      Even if the "warning message" must be visible to all project users.
    • User avatar
      • CC list francois jean-marie (francoisjean-marie) added
    • User avatar
      For sure, I'll make it with a tremendous pleasure.
    • User avatar
      Could you re-estimate taking into account my previous comment.
      Many thanks, you are doing a great job ...
      Denis
    • User avatar
      1/ "When a restricted user access this project, nothing but Git service is actually browsable": Do you mean the main page or any other page won't be accessible to restricted users ?

      2/ How will they know the Git project URL ? (knowing that restricted users don't have access to project tree in our configuration)

      About usage: it isn't worth having a dedicated group named "restricted user". Registered user is enough to say thaht even "restricted" one's are granted.
      It's easier for the project admin who doesn't need to do anything apart from the enabling at project level, and easier for you, so cheaper !

      I suggest the activation must be at Git service level for the moment, since only git access will be granted.


      The code must be generic enough to allow another usage: granting access to a project that is not opensource, to a set of known users (restricted or not), without adding them as members, whatever the project type (public/private). This to avoid adding people as member whereas they should have access only to part of the project and ar enot considered as members. (the famous guest groups)