You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposes adding the ability to clone from files beneath a privileged directory on your filesystem to your local directory.
Current Limitation
The Jupyter ContentManager API is not normally allowed to access anything outside of its base directory. This prevents users from accessing files above the base directory.
Use Case
The use case arises in cases where you want to provide access to content that is not normally available to the Jupyter Contents API.
For example, suppose that you were running JupyterHub for a number of users and had a filesystem of content that all users should have access to in a readonly way.
Workflow option - Rejected
You could display the contents with commuter, but users would then need to download and upload the content to their local server to be able to get an executable copy of the content. You could mount the file system beneath their Jupyter directory which would let you copy the contents. But that could lead to confusion and clutter in the user's filesystem.
Proposed Workflow
File system cloning would allow you to mount the volume at a in a standard location not beneath the users' base dir, and provide a way for users to directly clone that content as a copy into their local directory. Commuter could then show a clone button that would trigger this API, massively simplifying the workflow needed to go from a readonly to an executable copy of a notebook.
Key Benefit: This allows a similar workflow to be shared by both content hosted on s3 (what bookstore currently supports) as well as content on a filesystem.
^ Edited: The above description was added based on a super helpful suggestion from @willingc
A proposed model for filesystem cloning:
Design
filesystem cloning is disabled by default (any default would potentially pose a security issue)
filesystem cloning will only work for files that are children of a specific base directory (fs_cloning_basedir)
cloning source will be defined using a relative path from the fs_cloning_basedir
we will use the notebook contents manager to handle security policies around the cloning target path
separate validation checks for s3 cloning and fs cloning
create new /api/fs-clone and fs-clone endpoints with relpath query parameter and model key
modify clone.html template to be used by both sets of handlers
Proposal - Local Filesystem Cloning
This proposes adding the ability to clone from files beneath a privileged directory on your filesystem to your local directory.
Current Limitation
The Jupyter ContentManager API is not normally allowed to access anything outside of its base directory. This prevents users from accessing files above the base directory.
Use Case
The use case arises in cases where you want to provide access to content that is not normally available to the Jupyter Contents API.
For example, suppose that you were running JupyterHub for a number of users and had a filesystem of content that all users should have access to in a readonly way.
Workflow option - Rejected
You could display the contents with commuter, but users would then need to download and upload the content to their local server to be able to get an executable copy of the content. You could mount the file system beneath their Jupyter directory which would let you copy the contents. But that could lead to confusion and clutter in the user's filesystem.
Proposed Workflow
File system cloning would allow you to mount the volume at a in a standard location not beneath the users' base dir, and provide a way for users to directly clone that content as a copy into their local directory. Commuter could then show a clone button that would trigger this API, massively simplifying the workflow needed to go from a readonly to an executable copy of a notebook.
Key Benefit: This allows a similar workflow to be shared by both content hosted on s3 (what bookstore currently supports) as well as content on a filesystem.
^ Edited: The above description was added based on a super helpful suggestion from @willingc
A proposed model for filesystem cloning:
Design
fs_cloning_basedir
)fs_cloning_basedir
/api/fs-clone
andfs-clone
endpoints withrelpath
query parameter and model keyclone.html
template to be used by both sets of handlersPlan
relpath
query params Fs cloning handler #158/bookstore/fs-clone
endpoint End to End testing Cloning Landing page #159relpath
andtarget_path
model params Fs cloning api handler #163/api/bookstore/fs-clone
route & update handler tests Fs cloning api route #164fs_cloning_basedir
Fs cloning api handler #163EmptyNotebook.ipynb
Fs cloning api handler #163EmptyNotebook
Fs cloning api handler #163/bookstore/tests/test_files
directory Add fsclone integration test & format improvements #165/bookstore/tests
directory Add fsclone integration test & format improvements #165@chyzzqo2, does this sound like a good plan?
Replaces #110.
The text was updated successfully, but these errors were encountered: