Allow unprivileged users to start an interactive session

[ableuler]

The UI should allow a user to start an interactive session, even if that user does not have write access to the repo or is not logged in at all. The UI should warn the user that she or he might loose some data.

---

Update (2020-04-01):

After some work on the backend and some discussion below we have a clearer picture about the necessary changes on the UI side to enable this feature:

• Display dialogue for starting notebook servers also to unprivileged users
• Query the registry API rather than jobs API to determine image availability. In case of an unavailable image and only for privileged users the jobs API should still be queried to distinguish failed image build from ongoing ones.
• When receiving a 401 response from /api/notebooks/..., do not trigger the normal login cycle. Instead send the browser to /api/auth/jupyterhub/login-tmp?redirect-url=<current-path-or-full-url (url-encoded)>. This will trigger a login cycle with the Jupyterhub instance which manages the temporary user sessions and then redirect to the desired UI page.
• updated: The above point only applies when .Values.global.anonymousSessions.enable: true. Otherwise that login attempt will fail. .Values.global.anonymousSessions.enable should be translated into an env variable and written into config.json which then UI can then use to determine if anonymous sessions are activated or not.

[ableuler]

@lorenzo-cavazzi lorenzo-cavazzi set the estimate to 1 16 hours ago

Thanks @lorenzo-cavazzi. Any chance that this issue could be tackled and opened a "do not yet merge" PR for this today? This would make the testing of the backend part for this easier because one could simply use the UI to generate the relevant API calls.

[lorenzo-cavazzi]

sure, I can work on that later (after lunch), it shouldn't take long

[lorenzo-cavazzi]

@ableuler I made a quick draft PR, with a preview available here: https://lorenzotest.dev.renku.ch (the UI images is lorenzocavazzitech/renku-ui:0.8.1-9486b5a).

Keep in mind that currently, if you don't log in, any call to /servers will return a 401 response redirecting you to the log in page.

[ableuler]

Keep in mind that currently, if you don't log in, any call to /servers will return a 401 response redirecting you to the log in page.

That's exactly what I needed! Thanks!

[ableuler]

@lorenzo-cavazzi I'm modifying the notebook service to prevent the 401 responses and I think I'm getting there. However, the call to the gitlab jobs API to check if the image build is still ongoing still causes a redirect to the login page. Can you deactivate this call for an unauthenticated user? I know that this is just a bandaid and that we'll have to find a better solution for this later on, otherwise we're going to have too many failed notebook launches because of an unavailable image.

Generally it's really annoying, that registry API and the jobs API are both restricted to logged-in users, while the same information is available to an anonymous user through the GitLab UI.

[lorenzo-cavazzi]

It makes sense that unauthorized users can't access pipelines/jobs. Maybe here we can use another strategy similar to what @rokroskar implemented on renku-notebooks to check if an image is ready but trying to query the registry.
I guess the registry information is public and therefore available to all users. I'll quickly verify it

[lorenzo-cavazzi]

I confirm this approach works for anonymous users too 🎉

GET https://renkulab.io/api/projects/2669/registry/repositories/ --> you get the ID 2484
GET https://renkulab.io/api/projects/2669/registry/repositories/2484/tags/ed511c2 --> 404 if image is not ready, 200 otherwise

This approach is simpler but I would still keep the pipeline/job info for DEV+ users since it helps in debugging what went wrong when the image is not building by pointing you to the relevant job.

If it's enough for you, I will just disable the pipeline/jobs calls since it's super quick, but we now know how to properly fix this later 🙂

[ableuler]

If it's enough for you, I will just disable the pipeline/jobs calls since it's super quick, but we now know how to properly fix this later 🙂

yes, that's perfect!

[ableuler]

GET https://renkulab.io/api/projects/2669/registry/repositories/ --> you get the ID 2484
GET https://renkulab.io/api/projects/2669/registry/repositories/2484/tags/ed511c2 --> 404 if image is not ready, 200 otherwise

That's really great news. In the API docs they explicitly say otherwise, but that will save us quite some work. Thanks for checking @lorenzo-cavazzi! 🎉

[ableuler]

@lorenzo-cavazzi Do you want to implement the discussed changes (query registry API instead of jobs API to determine image availability) within the scope of this Issue/PR or should I create a new separate issue for it and mark it as a dependency for this issue?

[lorenzo-cavazzi]

No it's fine, I would address all in this issue/PR.

I was postponing working on this until I can deploy a beta version of the backend in my environment, otherwise it's a bit annoying (and error-prone) faking the API responses

[ableuler]

I was postponing working on this until I can deploy a beta version of the backend in my environment, otherwise it's a bit annoying (and error-prone) faking the API responses

Yes, I understand. Would it be ok for you to develop this against the running deployment at https://andreas.dev.renku.ch ? I have everything running now but deploying it is still not as streamlined as it should be. Feel free to swap out the UI of my running deployment or telepresence into it.

[rokroskar]

For a future iteration on this: would it be possible to have "binder-like" experience of sending someone a link that drops them directly into a running session? Maybe they would still have to click a button to actually trigger the launch, but it would be nice if they didn't have to navigate anywhere. @lorenzo-cavazzi started discussing something along these lines already - maybe we should have a design meeting where we can hash out how to streamline the launch experience?

[ableuler]

would it be possible to have "binder-like" experience of sending someone a link that drops them directly into a running session?

I think it can even be done without any button click. IMO there's nothing wrong with a browser page which translates some request parameters into the body of a POST request. Also the immediate redirection to the launched instance should be ok now that Jupyterhub has improved their handling of starting sessions.