Build 0.52: Apps can now expose APIs (and other things)

133 views
Skip to first unread message

Kenton Varda

unread,
Sep 29, 2014, 11:12:53 PM9/29/14
to sandst...@googlegroups.com
Hi sandstorm-dev,

I just pushed build 0.52 (and then 0.53 and 0.54 to fix problems that only appeared in production; ugh).

The major new feature is that apps can now export APIs at a stable address. These APIs can be accessed by mobile clients, third-party web pages, etc.

To use an API, you must first generate an API key. There are two ways to do this:
- The user can click the key icon in the topbar when they have an app open.
- The app itself can make a call to HackSessionContext.generateApiToken().

The token looks something like:

The part before the # is the API endpoint for the server (in this case, for alpha.sandstorm.io). After the # is the API token. You can't just open this URL directly (at present). Instead, you need to make a request to the API endpoint with an Authorization header containing the token. Specifically, the header should be "Authorization: Bearer <token>". In other words:

  curl -H "Authorization: Bearer 49Np9sqkYV4g_FpOQk1p0j1yJlvoHrZm9SVhQt7H2-9" \

The HTTP request will then be forwarded to the app. Note that cookies will NOT be forwarded, and any cookies returned by the app will be dropped. Moreover, the response will have a Content-Security-Policy header designed to prevent it from being interpreted in any dangerous way by the browser -- although the Authorization header requirement should already prevent the page from being loaded in a regular browser window anyway.

The API endpoint is set up to allow cross-origin requests from any origin, which means you can access an API from XMLHttpRequest on any domain.

We plan to update some of our apps to take advantage of this. In particular, I'm excited to get the mobile client for TinyTinyRSS working.

There will be a blog post soon, probably after we have some sort of demo.

Other changes in this build:
- The "about" page has been updated to include all our Indiegogo contributors (or, at least, the ones that responded to the questionnaire and indicated they wanted their name shown).
- Updated to Meteor 0.9.3.
- Streaming HTTP requests are now supported in both directions. This means you can now upload files larger than 32MB to an app. We'll be updating GrooveBasin for large uploads soon.
- Fixed a bunch of bugs, including some embarrassing issues that occurred when running Sandstorm with a non-English locale set.

-Kenton

bsles...@gmail.com

unread,
Oct 9, 2014, 4:41:11 PM10/9/14
to sandst...@googlegroups.com
Interesting. Can you revoke the token? How about getting a list of live tokens, either programmatically or in an admin UI?

It seems like annotating each token with a display name (as a reminder of what it's for) and the date created would be useful.

- Brian

Kenton Varda

unread,
Oct 9, 2014, 5:02:08 PM10/9/14
to Brian Slesinsky, sandst...@googlegroups.com
On Thu, Oct 9, 2014 at 1:41 PM, <bsles...@gmail.com> wrote:
Interesting. Can you revoke the token? How about getting a list of live tokens, either programmatically or in an admin UI? 

It seems like annotating each token with a display name (as a reminder of what it's for) and the date created would be useful.

Yes to all.

When a user creates a token through the UI (clicking on the key button), they give it a petname. Meanwhile, just under the new-token form is a list of previously-created tokens, showing names an dates, with the ability to revoke them. You can try this out with the demo -- open any app and click the key icon in the top bar. Create some tokens, then delete them.

For tokens created by the app itself through the Sandstorm API, other API calls exist to enumerate tokens and delete them. Also, the app can set an expiration time. It's up to the app to decide whether it makes sense to present a management and revocation UI to the user.

-Kenton

PS. Token values are not stored in the database. Only their hashes are. :)
Reply all
Reply to author
Forward
0 new messages