Add Access-Control-Allow-Origin to API

[Rudloff]

Hello,

The API responses does not have a Access-Control-Allow-Origin so it is not possible to access it from JavaScript.

Regards,

[malgorithms]

It'll be a bit before we allow these. There is an exception; we set the appropriate headers for raw key loading in JS:

https://keybase.io/chris/key.asc

You can get a keybase user's public key.

Is there something specific in the browser you were/are looking to build? cc

[Rudloff]

I am just messing around with the API for now, I don't have a specific project. But it might be useful to create an app for Firefox OS or Phonegap.

[malgorithms]

just for frame of reference, I wrote this on #625 (a closed dupe):

hi @KeybaseApp , this is a dupe of #620 . We plan on making this possible, but it's something websites have to be very careful about, to prevent cross-site scripting attacks. So we'd been keeping it closed during the alpha until we got further along on the API.

Maybe we could close this issue and talk on 620 about which API calls we should be unlocking for now. Autocomplete seems like a logical one, of course. So does something which requests user info. If there's a particularly safe seeming call, we might activate it now. We did that with raw key lookups.

If you can tell us a bit about what you're hoping to build that's be most helpful.

It's very pleasing to hear that people want to build web apps that connect to Keybase.

[KeybaseApp]

@malgorithms per your request. I'm trying to build a messaging service that is completely secure and relies on the client directly interacting with the API (without using my server as an intermediary) except for the transmition of messages. I want to make the web client so that the source can be downloaded to prevent targeted js attacks.

Oh, and can you tell me if this sounds like a secure method to handle login?

1. User makes a call to my server to request a session id, their Keybase username is included in this request.
2. User interacts directly with the Keybase API to login and get their private key. They then sign a json payload that looks like{"sid":"The-sid-requested-by-my-server"} And POST that to authenticate their session.
3. My server verifies that the message has been signed correctly if it has, the session is given access to messages and can see conversations.

Matt, you can view the API documentation I have been working on at this link https://ghostbin.com/paste/7n98g (it's under development so not public).

[malgorithms]

hey @KeybaseApp -- I need to talk to Max about this (he's back Monday). Your step 2 above is a bit scary from a user perspective, because it's hard to verify that an app is going to ask for your passphrase and then send it to Keybase's API, as opposed to sending it elsewhere. Further, it's dangerous because every app is a possible bug point. Users likely won't want to access their private key through lots of different web apps.

Further, it would be cool if people who don't host their private keys on keybase could still use your service. (It's possible!)

I think The "right" solution to this problem likely involves your app generating a fresh key pair for the user (something it can hold onto or throw away, depending on its intentions), distinct from their typical master key pair. It then sends the public key in an API call to keybase, requesting the user signs it. They can do this on the keybase website (if they have their private key hosted), or from the command line -- and the site will instruct them on the steps either way.

They'd just need to do this once with your app, and your app could pop up a window for them to do it it at keybase.

Does this make sense? Don't take it as the precise plan yet, because Max and I need to talk.

While it might sound more complicated than a regular session, it could end up simpler and safer from your perspective. A user comes along and says "I'm foobar on Keybase" and your app gets them going without worrying about Keybase session validation.

If we go down this route, we'll likely release JS library examples for generating new key pairs, what API calls to hit, etc.

[malgorithms]

hey all - we added cross-origin support for 2 of our API calls today: userinfo (arguably the most important) and autocomplete. There's also still the raw key lookup support, so that makes three.

Here's an example requirebin snippet that hits our autocompleter and then hits userinfo for each result. Userinfo gets a lot of stuff about a user: the details of their identity proofs, they profile info, and their public key.

http://requirebin.com/?gist=11384155

We'll do more soon.

[IsaiahJTurner]

Any idea on how authentication could work?

[malgorithms]

Authentication won't come for a little while. We don't just need sessions, we need a way for users to generate a key pair unique to a 3rd party service and sign them with their master keys.

In other words, you need to be able to sign things and receive encrypted things in 3rd party apps without exposing your private key or Keybase passphrase to those 3rd party apps. This is something we have to get right.

A likely scenario is an OAuth-like experience, but involving the Keybase client (or, if you keep a TripleSec-encrypted private key on Keybase, the website). Let's say you want to sign something somewhere. You'll generate a key pair, you'll sign your new public key, and then you can use this new private key in the new client.

It'll be a little while before we get to this.

[malgorithms]

we've been adding CORS support - more added today!