Provide a way to obtain an API key associated to any account that requires the user to explicitly sign in via whatever method they use.

[williamstein]

Motivation: Using CoCalc as a backend for an iPad application.

We create a page that looked exactly like our current cocalc sign in page, but after the sign in completes, the browser just displays the api_key for that user rather than loading the normal cocalc application. The client ipad app would then have the api key. In particular, imagine that visiting

https://cocalc.com/app?get_api_key=true

would ALWAYS show the sign in screen, require the user to manually do something, and once sign is completed successfully, simply show the api_key. Your app could send the user to the above URL whenever their api key is rejected (e.g., they reset/change/invalidate it) or isn't known. Then we could support generating api keys for users that don't have a username or password.

Requesting an api key for a user with no email/password would also show a link to the above URL.

[williamstein]

Different approach: A final idea. What if we had a page that looked exactly like our current cocalc sign in page, but after the sign in completes, the browser just displays the api_key for that user? Juno would then have the api key.

Feedback:

Yeah, it’s not too bad. Although this wouldn’t allow us to build native sign in/sign up pages (see examples of what I was trying to achieve attached), it sounds reasonable. An alternative would be to display full CoCalc UI in a WebKit view up until the point of selecting a project, which would be worse from usability point. With your suggestion we could at least build a list of projects natively, and to be fair users would spend there more time than on login and sign up screens. Do I understand correctly that on this page users would be able to sign in with or without password and sign up as well?

I would suggest though that instead of displaying this API key at the end of authentication you just try to load a URL (setting window.location should suffice) of a specific format that would contain this API key: say, something like cocalc://authenticated?api_key=sk_7hw4JXGfsdTyrEICE23hJh6g — this would be easy for us to intercept and store securely until it’s rejected and we need to display sign-in screen again. We would handle sign out by simply displaying this sign-in page again.

[williamstein]

This will be live soon. To use it:

1. Send the client that is NOT signed in already to https://cocalc.com/app?get_api_key=juno
2. The client can create a new account (either with login/password or google/facebook/etc.) or sign in (again with either method). Once they authenticate...
3. They are redirected to https://authenticated?api_key=sk_7hw4JXGfsdTyrEICE23hJh6g (with maybe a hash at the end). Their browser will just a DNS error, but in the URL bar you'll see https://authenticated?api_key=sk_7hw4JXGfsdTyrEICE23hJh6g. Doing cocalc:// did not work at all.

NOTE -- in step 1, it is important that the remember_me cookie is NOT set, since otherwise, the client will just be signed in.

[williamstein]

In general, use https://cocalc.com/app?get_api_key=myappname.

[alexstaravoitau]

Thanks @williamstein, I managed to get hold of the api_key, etc. However, looks like .../app?get_api_key=myappname endpoint doesn't set the remember_me cookie upon successful authentication — is this intentional? If so, is there a way to convert api_key to a user session, e.g. to a valid remember_me cookie? From what I can tell we need this cookie to get access to Jupyter, correct me if I'm wrong here.

[haraldschilly]

Hmm, I don't remember/know the details. IIRC, the spot in the code setting it is here.

Maybe it should rather be possible to use the authentication token as a query parameter to access the notebook?

Well, in any case, I'm reopening this issue.

[alexstaravoitau]

Maybe it should rather be possible to use the authentication token as a query parameter to access the notebook?

@haraldschilly Yeah that could work — is there a way we can convert api_key to an auth token that we will then provide as a query parameter to Jupyter?

[DrXyzzy]

How about using the api key in a user_auth call?

https://cocalc.com/doc/api.html#user_auth

[williamstein]

That should work fine and was my intention. We may want to optionally (?) make the 12 hours last longer though, or just use user_auth once whenever the login fails. I'm fine with extending the 12 hours (or making at an option).

…

On Sun, Nov 26, 2017 at 3:12 PM, Hal Snyder ***@***.***> wrote: How about using the api key in a user_auth call? https://cocalc.com/doc/api.html#user_auth — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2468 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABN5dpOXKdGsgPRVgUAQt-SM3dMSKsz-ks5s6fBDgaJpZM4QQdf4> .

-- William (http://wstein.org)

[alexstaravoitau]

How about using the api key in a user_auth call?

Yeah, I thought of using .../api/v1/user_auth, but it requires user's password — and some users don't have passwords (also if we were to ask for one this would result in them logging in twice). Is there a way we can use this endpoint with just the api_key and account_id?