Track Level Permissions

[enuggetry]

Adding track-level permissions to JBrowse tracks in Apollo and JBrowse directly.

Item 8 in GMOD Hackathon http://gmod.org/wiki/2018_PAG_Hackathon

Ref: GMOD/Apollo#17

This feature that is generally already capable to some extent by JBServer which:

1. has a policy engine that can restrict access to assets per users (passportjs-based)
2. restricts track access to admins. The demo shows REST access to tracks that can be restricted by policy. However, the demo and the GUI do not demonstrate this to the it's full potential.

However, what is there is a cursory implementation (a proof of concept) that lacks robustness.

What is needed is a discussion of the extent of the implementation and how it should be perceived from the client perspective.

I imagine there might need to describe the following:
a) policies for user groups with access to track groups.
b) client-side handling of inaccessible assets; plus an asset manager interface
c) client-side response.
d) JBServer uses passportjs, which can be adapted to various auth frameworks.

I invite you to describe your use cases.

[enuggetry]

I propose that such policies can be implemented and applied by way of jbh- hook model (which can be npm-installed), as defined by JBServer's extensible hook framework. This enables a flexible policy model that can be interchangeable with other models or extensible by additional hooks (plugins).

[FredericBGA]

It would be so great to retrieve the GGB behavior

[5_prime_RACE]
glyph = generic
feature = RACE:5_prime
restrict = require user fred joseph andrea marta

and of course restrict = require group also

[rdhayes]

The "restrict = require user/group" syntax can be replicated in JBrowse today with an .htaccess file in your dataset root directory, or equivalent non-apache user management. Richard D. Hayes, Ph.D. Joint Genome Institute / Lawrence Berkeley National Lab http://phytozome.jgi.doe.gov

…

On Tue, Jun 5, 2018 at 12:18 AM, Fred ***@***.***> wrote: It would be so great to retrieve the GGB behavior <http://gmod.org/wiki/GBrowse_Configuration/Authentication#Restricting_Access_to_Datasources_with_GBrowse_Account_Database> [5_prime_RACE] glyph = generic feature = RACE:5_prime restrict = require user fred joseph andrea marta and of course restrict = require group also — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#948 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAc92Cluw4_yoJm9Q4CRMuGQKbGIFjdqks5t5jDhgaJpZM4RJEFW> .

[FredericBGA]

@rdhayes thank you for your help.
But it does not fit all I need. I think that with an .htaccess file, the track will be still displayed, I would like to hide it (user1 should not see that user2_private_track exists !)
And with the current index (generate_names.pl) even if track data can not be displayed, I'm afraid that user 1 will be able to guess user2_private_track content

[cmdcolin]

@FredericBGA You can potentially use the system of "includes" and include private tracks in a different privateTracks.json and then add "include": ["privateTracks.json"]

http://gmod.org/wiki/JBrowse_Configuration_Guide#General_configuration_options

Then only the authorized user would have successful inclusion of those private track configs.