Clearing the secure cookie makes sense when it is invalid or expired,
but clearing it when it's not sent with a request can unexpectedly log
the user out.
I ran into this with misconstructed URLs which didn't incorporate
base_url. That was itself a bug, but the result of suddenly being
unauthenticated makes it harder to track down.
Closes gh-3365 (hopefully)
Possibly also relevant to gh-2396
I'm not sure why this seems to affect Firefox more than Chrome.
When token is enabled, the login page will present a form to the user
asking them if they want to set a password at the same time. This is
almost equivalent to running `jupyter notebook password` on the command
line.
The experience can likely be better, but just submitting that as a POC
for feedback
avoids clobbering cookies when multiple notebook servers are run on one host.
Users can override `cookie_options.path = ‘/‘` if they *want* cookies to be shared across notebooks on one host.
- add NotebookApp.login_token, used when NotebookApp.password is not set
- store login_token, bool(password) in notebook server-info file
- `jupyter notebook list` shows pasteable URLs with token
General changes:
- notebook servers are now authenticated by default
- first connect with token sets a cookie
- once a user has logged into one server with a token, their browser is logged in to
all subsequent servers on the same system+port until cookie_secret changes
There was a conflict for the .login_available property on LoginHandler itself
causing the login form to render incorrectly when login_available should be False
Thomas Kluyver
maartenbreddels
Matthias Bussonnier
Min RK
Kyle Kelley
jean-roch
Srinivas Reddy Thatiparthy
Chris Seymour