read-only notebook mode #931

Merged
merged 5 commits into from Oct 28, 2011

Projects

None yet

2 participants

@minrk
Member
minrk commented Oct 26, 2011

As requested by @fperez

When using a password, read-only mode allows unauthenticated users read-only access to notebooks. Editing, execution, etc. are not allowed in read-only mode (the buttons, shortcuts, etc. are removed, but the requests will raise authentication errors if they manage to send the events anyway), but save/print functions are available.

No kernels are started until an authenticated user opens a notebook.

minrk added some commits Oct 25, 2011
@minrk minrk Allow notebook server to run in read-only mode
Kernels are never started, and all save/delete/execution handlers raise
403: Forbidden.

/cc @fperez
da96638
@minrk minrk add read-only view for notebooks
When using a password, read-only mode allows unauthenticated users
read-only access to notebooks.  Editing, execution, etc. are not
allowed in read-only mode, but save/print functions are available.

No kernels are started until an authenticated user opens a notebook.
4e4c27a
@fperez
Member
fperez commented Oct 28, 2011

I think there's some JS missing, I get:

WARNING:root:404 GET /static/js/loginwidget.js (127.0.0.1) 0.47ms
@minrk
Member
minrk commented Oct 28, 2011

indeed, forgot to add the new file. Should be there now.

@fperez
Member
fperez commented Oct 28, 2011

Did you mean --read-only to be usable in the unauthenticated case at all? I just tested it, and even if I open the nb with --read-only, I still get full read-write access on the designated port. I was imagining that in the read-only flag would be useful in two different modes:

  1. No authentication: in this case, simply run a second nb on the same directory with --read-only and expose that to users.
  2. With authentication: adding --read-only allows unauthenticated users to connect as well.

I see the value in 2 when running a full-blown server, but option 1 is very lightweight and I think would be worth having.

Do you think it's difficult to get it in?

If it's hard and for now we go only with 2, then --read-only should raise an error when used without authentication, since it doesn't actually provide read-only access.

@minrk
Member
minrk commented Oct 28, 2011

I did 1. first, then I did 2. I'll have a peek tomorrow at if I can get 1. back in reasonably easily, otherwise I will raise an error if read-only is set without a password, as it has no effect.

@fperez
Member
fperez commented Oct 28, 2011

That would be awesome, thanks!

@minrk
Member
minrk commented Oct 28, 2011

Nevermind, it's only half a line of code to make that work. Give it a try.

@fperez
Member
fperez commented Oct 28, 2011

Awesome! This looks fantastic, and will be super useful. Only one thing: is it possible to have the left sidebar start closed rather than open and then quickly close? The reason I ask is that when reloading, the flashing of open/close of the sidebar is kind of annoying, and we probably expect that read-only notebooks will be reloaded very frequently in a teaching scenario. It would be nice not to have that flashing of the UI happen.

If it's not easy, we can defer it to a future point in time and merge this for now, as it's already excellent and immediately useful.

Thanks for the awesome!

@minrk
Member
minrk commented Oct 28, 2011

I'll see what I can do. Currently, the page load is not aware that it is read-only until the notebook request arrives, so the choice is between starting closed, and opening when logged in, and starting open, and closing when read-only. If I can move up the signal that it is read-only, then I should be able to determine the behavior before it gets drawn the first time.

In teaching scenarios, it might even make sense for it not to be hidden by default, since these would presumably be novice users, who don't know about the hidden sidebar, which holds useful links like help and save/print.

@fperez
Member
fperez commented Oct 28, 2011

On Thu, Oct 27, 2011 at 11:41 PM, Min RK
reply@reply.github.com
wrote:

I'll see what I can do.  Currently, the page load is not aware that it is read-only until the notebook request arrives, so the choice is between starting closed, and opening when logged in, and starting open, and closing when read-only.  If I can move up the signal that it is read-only, then I should be able to determine the behavior before it gets drawn the first time.

Great, thanks.

In teaching scenarios, it might even make sense for it not to be hidden by default, since these would presumably be novice users, who don't know about the hidden sidebar, which holds useful links like help and save/print.

Well, but normally they'll have their own working notebooks open with
those links. This would be for them to easily monitor the teacher's
session in case they fall behind while working on their own stuff.

@minrk
Member
minrk commented Oct 28, 2011

I'll move the read-only check to page-level, instead of on the notebook / notebooklist requests. That will allow the drawing to
make decisions immediately, rather than waiting for the delayed call.

will take a small amount of reorganization, but should be easy enough.

It's also just better, because I was not too fond of using the Allow headers to indicate read-only-ness.

@fperez
Member
fperez commented Oct 28, 2011

On Fri, Oct 28, 2011 at 11:53 AM, Min RK
reply@reply.github.com
wrote:

I'll move the read-only check to page-level, instead of on the notebook / notebooklist requests.  That will allow the drawing to
make decisions immediately, rather than waiting for the delayed call.

Awesome, thanks!

@minrk
Member
minrk commented Oct 28, 2011

I've got read-only attached to the pages, but I don't seem to be able to get the side panel to startup collapsed. I did prevent the contents of the panel from drawing until after it is hidden, but I couldn't get the panel itself to startup collapsed, and still work properly.

@minrk minrk move read_only flag to page-level
contents of LPanel are not drawn until after collapse

read_only is in a <meta> tag
81edd9f
@fperez
Member
fperez commented Oct 28, 2011

On Fri, Oct 28, 2011 at 2:44 PM, Min RK
reply@reply.github.com
wrote:

I've got read-only attached to the pages, but I don't seem to be able to get the side panel to startup collapsed.  I did prevent the contents of the panel from drawing until after it is hidden, but I couldn't get the panel itself to startup collapsed, and still work properly.

This is actually much better already! I'm OK merging it as-is for
now, the flashing without button boxes is much less obtrusive.

Unless you want to keep going at this, I'm happy to merge now...

Cheers,

f

@minrk
Member
minrk commented Oct 28, 2011

The only thing I'm not fond of is that the login widget still exists in full read-only mode, where logging in won't do anything, but I think it's good enough to go in.

@fperez
Member
fperez commented Oct 28, 2011

On Fri, Oct 28, 2011 at 3:48 PM, Min RK
reply@reply.github.com
wrote:

The only thing I'm not fond of is that the login widget still exists in full read-only mode, where logging in won't do anything, but I think it's good enough to go in.

I can live with that: this is mostly for use in-class, in front of
people, so tiny UI rough edges like that are acceptable for now (given
the enormous utility of the feature). In due time, the UI will get
smoother.

Thanks again for the great work, merging now!

@fperez fperez merged commit 80e60eb into ipython:master Oct 28, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment