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

[Matthias BUSSONNIER]

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.


> 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. 

> 
>> 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. 

> 
>> 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

> 
>>>      • 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