The login button should not appear in 'default' mode, where it does exactly nothing. Do you know why your PR disables the hidden logic that was there before?
Also, what should happen in the case where read-only mode is the only one available (no password is set)? In your case, you can enter any password, and login just redirects you to the front page. This suggests that login was successful, but it obviously wasn't, as the login button remains (and login is impossible).
I should think that at the very least, trying to login should always fail, and ideally the login button should be disabled in this case as well.
@minrk The current logic is already broken; it never shows a login button in read-only mode. The problem is that we only make a distinction between read-only vs. non-read-only modes, whereas there is a third case: read-only but with the option to log in. So maybe we can give the read-only property some more states. I'll have a look at how to best accomplish this.
OK, I see we do have three states in there: None, True and False. I'll check for these separately.
I think the existence of a non-empty password is the thing that tells you whether login is possible.
Yes, but we don't want to do that logic inside of the templates, if possible.
@minrk This is the basic idea I had in mind. There are different ways to implement it (e.g., have read_only return a string instead of True, False, None), but this seems to work for now.
There is actually one more case to handle: no password set, and not read-only. This is by far the most common case, and should not draw any login/logout buttons.
@stefanv, this PR needs a rebase as it's now conflicting. Do you think you'll have time to finish it up before we cut the 0.12 RC? That basically means finish it today...
Display login button in read-only mode.
Redirect to front page upon read-only logout.
On the login page, focus on the password field.
Improve three-state read-only logic.
Split read-only logic into three functions: read_only, logged_in, and…
@fperez @minrk This change should make the logic a lot clearer. There are three states that need to be monitored, each now associated with a method:
Awesome, much cleaner than it was before, and I've tried every combination of being logged in / out having password defined / undefined, and readonly, and it seems to always behave how I expect.
The only thing that didn't seem perfect was the fact that login/logout buttons are still drawn on the login page. If that's an easy fix, go for it, otherwise I'm +1 on merging right now.
That's a trivial fix. Give me one second.
Hide top login/logout buttons on login/logout pages.
@minrk That should do it.
…is has a different meaning than in the Python code: not whether the read-only flag was specified upon launch, but whether the notebook is in read-only mode and input should be disabled.