Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

    •  
      story #7813 grant restricted users access to git repositories
    Actions
    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
    Empty
    Done
    Development
    • [ ] Does it involves User Interface? 
    • [ ] Are there any mockups?
    • [ ] Are permissions checked?
    • [ ] Does it need Javascript development?
    • [ ] Does it need a forge upgrade bucket?
    • [ ] Does it need to execute things in system events?
    • [ ] Does it impact project creation (templates)?
    • [ ] Is it exploratory?
    Empty
    Details
    #7813
    Manuel Vacelet (vaceletm)
    2015-04-28 08:54
    2015-01-29 16:57
    7815

    References
    Artifact links
    Empty
    Referencing story #7813

    Artifact Tracker v5

    rel #7968 8.1

    Git commit

    tuleap/tuleap/stable

    Refactoring: Introduce ConfigValueFileProvider 415b923206
    User avatar Nicolas Terray (nterray) , 2015-03-27 08:38
    Move sys_allow_anon in the database c48b15585f
    User avatar Nicolas Terray (nterray) , 2015-04-03 17:15
    Merge commit 'refs/changes/02/3802/17' of ssh://gerrit.tuleap.net:29418/tuleap into tuleap-stable-master d82e13e391
    User avatar Manuel Vacelet (vaceletm) , 2015-04-14 11:47
    story #7813: allow the project administrator to give restricted users access to their project 7fd21df287
    User avatar dylan bowden (dylan) , 2015-04-14 10:36
    Merge commit 'refs/changes/21/3821/16' of ssh://gerrit.tuleap.net:29418/tuleap into tuleap-stable-master 18617c2198
    User avatar Manuel Vacelet (vaceletm) , 2015-04-20 17:25
    story #7813: configure a git repo to allow access for restricted users b55829f824
    User avatar dylan bowden (dylan) , 2015-04-20 15:12
    Merge commit 'refs/changes/88/3888/2' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD c2a2bafa51
    User avatar Benjamin Dauton (bdauton_enalean) , 2015-04-22 13:41
    story #7813: Properly inject GitPermissionsManager e96cfbd4b2
    User avatar Manuel Vacelet (vaceletm) , 2015-04-21 15:03
    Merge commit 'refs/changes/89/3889/3' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD 2a080329fe
    User avatar Martin GOYOT (goyotm) , 2015-04-23 10:49
    story #7813: detect access platform switch and update git repositories accordingly 4ec17f8030
    User avatar Manuel Vacelet (vaceletm) , 2015-04-22 17:38
    Merge commit 'refs/changes/90/3890/2' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD 994da9d667
    User avatar Martin GOYOT (goyotm) , 2015-04-23 10:52
    story #7813: update git repositories when switching project access 47bf85b690
    User avatar Manuel Vacelet (vaceletm) , 2015-04-22 17:39
    Merge commit 'refs/changes/91/3891/2' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD b1c373b502
    User avatar Benjamin Dauton (bdauton_enalean) , 2015-04-23 11:07
    story #7813: restricted users can view unrestricted public projects in trove cats 2fb43638ed
    User avatar Manuel Vacelet (vaceletm) , 2015-04-22 17:39
    Merge commit 'refs/changes/92/3892/3' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD 764411c763
    User avatar Benjamin Dauton (bdauton_enalean) , 2015-04-24 09:11
    story #7813: site admin can rename registered and authentified groups ba835c3e62
    User avatar Manuel Vacelet (vaceletm) , 2015-04-23 15:36
    Referenced by story #7813

    Other

    gerrit #3801
    gerrit #3804
    gerrit #3802
    Display settings

    Follow-ups

    User avatar
    Nicolas Terray (nterray)2015-04-08 09:55
    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
    Manuel Vacelet (vaceletm)2015-02-26 16:41

    * 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
    Denis PILAT (denis_pilat)2015-02-26 16:21
    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
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    Manuel Vacelet (vaceletm)2015-02-26 14:57

    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
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    Manuel Vacelet (vaceletm)2015-02-26 11:33
    Update of the spec after discussion with end users
    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    Manuel Vacelet (vaceletm)2015-01-30 17:19

    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
    Denis PILAT (denis_pilat)2015-01-30 17:08
    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
    Denis PILAT (denis_pilat)2015-01-30 16:10
    Could you re-estimate taking into account my previous comment.
    Many thanks, you are doing a great job ...
    Denis
    User avatar
    Denis PILAT (denis_pilat)2015-01-30 16:09
    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)