[IPython-dev] IPEP 3: Multiuser support in the notebook

[MinRK]

On Sun, Sep 9, 2012 at 9:39 AM, Matthias BUSSONNIER <
bussonniermatthias at gmail.com> wrote:

>
> Le 9 sept. 2012 à 18:10, Brian Granger a écrit :
>
> > Matthias,
> >
> >
> > On Sat, Sep 8, 2012 at 2:02 AM, Matthias BUSSONNIER
> > <bussonniermatthias at gmail.com> wrote:
> >>
> >>
> >> Comment on current IPEP version :
> >>
> >>>      • Users will have the ability to "live share" notebooks and their
> kernels. When a user clicks "live share" they will get a private and secure
> URL they can share with other users. These other users can then edit the
> notebook and run code on the kernel in a Google Docs like manner.
> >>
> >> This is one feature, but I would expect the ability to invite/remove
> user independently.
> >> Either by being able to tick checkboxes, or else. But nothing annoy me
> more than having to look into my email to find the link.
> >>
> >> Ability to have "soft" more grained privileges. Invite a user than can
> only edit and not run.
> >
> > One thing we need to think through is the different "modes" a user can
> > view a page in.  Minimally we have three boolean flags that determine
> > the mode: read, write, execute.  Are there others?
>
> I see 5 different level of authorization
>
>         • Ability to see a static version of the current saved, or
> specific version of the notebook (cf nbviewer).
>         • Ability to see a live edited version of the notebook, without
> being able to interact.
>         • Ability to edit part of the notebook and push the changes
>         • Ability to save the current changes on disk
>         • Ability to execute code on the kernel.
>

I don't think there's any reason to allow editing without saving.  That's
just confusing, so there's at most 4 here, and I'm not convinced that there
are even that many.  I only see:

1. read-only
2. write
3. execute

Now, we can decide whether read-only access gets live-updates or not, but I
cannot imagine a sensible scenario where an owner gives some users the
ability to watch changes, and others the ability to see the same thing only
if they keep hitting refresh.



>
>
> > One big thing we will have to work out is how to tune the
> > content/display of each page in a way that reflects these flags, but
> > that is secure.  Our current approach of setting a variable in JS to
> > control things is horribly insecure.  Ideas on this?
>

> We have to have more fine grained decorators in the handler side.
> Js side is just to make things pretty.
>

The JS code currently has nothing at all to do with security, it is only
there to help the UI be consistent with the permissions enforced on the
server.  If a read-only viewer executed JS to save or execute, they would
fail because they do not have permission.


>
> >
> >> Obviously we are really vulnerable to JS injection. We should
> definitely try to do something about that, even if we sell the notebook as
> beeing not totally secured. One thing we can use is html5 sandboxed feature
> of iframe. This could also solve the "problem" of css in ".rendered_html".
> >
> > I agree we need to think more about security, but that is really off
> > topic for this IPEP (i.e., the same technical problems exist for the
> > single user notebook).
>
> If you don't allow collaboration, then yes this is off topic.
> As soon as you add collaboration with username and password, you have a
> risk of user stealing each other account.
> We should think of it while building multi user account.
>

Collaboration is hugely complex, and I think it warrants an entirely
separate discussion.


>
> >
> >> Implementation wide for live collaborating, we should redirect the
> message using cell ID, otherwise this is a huge problem to redirect IOPub
> to all clients.
> >
> > I am not quite following you here.  Don't all clients need to get all
> > iopub messages?
>
> Yes they do.
> But they don't now how to handle it.
>
> if I run Safari and Chrome on "notebook_a"
> When I execute "1+1" on Safari, for cell 54, when iopub arrives on Chrome,
> it has no idea of what to do with it.
> I think we should proxy :
>
> Browser(s) ===>===> [execute+cell_id(+uuid ?)] ===>==> server strip
> cell_id (, add uuid) ? ==>==> kernel
>
> Browser(s) <===<==<===<===<===<==<===<===<=== server match uuid, append
> cell_id <==<=== kernel
>

I don't think we want to do this.


>
> >
> >>>      • Version control of notebooks will be done using the command
> line interface to git and other VCSs. These VCS command will be issued
> through the shell widget.
> >>
> >>
> >> I think some high level command would be great, like changing 'save'
> button, to 'commit' with a custom message that can be generated by user.
> >
> > We have talked about this before and we want to avoid creating a git
> > UI in the notebook.  The other issue is that repo level actions are
> > not per notebook, but per directory, so if we did add a commit button,
> > it would need to be on the directory dashboard, not the notebook page.
> >
> >> One of the things I came across while prototyping live collaboration is
> the real need to have the current state of the notebook on the kernel side.
> >> I think we should define a format of notebook 'patches' that represent
> common operation on a ipynb file, at least:
> >>        - appending/moving/deletting worksheet/cells
> >> preferably with reference to the worksheet/cell by UUID.
> >
> > I am not sure what you mean by having the notebook state on the
> > kernel.  We have to be very careful to keep the notebook and kernel
> > state completely separate.  Can you elaborate on why this was needed?
> > But actually, can you open a separate IPEP for live collaboration - it
> > is really a big topic in itself.
>
> I'm loading notebook state_a, starting kernel.... I type, change on cell,
> continue... don't save.... I am on state_b
> I invite you, you open your browser, server give you state_a.
>
>
> >> I also think that for live collaboration we need both a 'cell is being
> edited' lock, and also maybe a 'cell is being executed' lock.
> >
> > Yep, I think at the cell level that having locks like this makes sense
> > for us.  The problem is doing so in an asynchronous setting (what if
> > both of us lock the same cell before the server is notified?)
>
> No problem, just don't set code_mirror.allow_edit until true once the
> response : "you were able to put the lock" arrives.
> I did it in my prototype with
>
> request_lock(){
>
> succes... callback:lock_granted()
> error... callback:lock_refused()
> }
>
> --
> Matthias
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120909/e608d4fe/attachment.html>