[IPython-dev] IPEP 3: Multiuser support in the notebook
benjaminrk at gmail.com
Sun Sep 9 14:53:05 EDT 2012
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:
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
> >> 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
> succes... callback:lock_granted()
> error... callback:lock_refused()
> IPython-dev mailing list
> IPython-dev at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev