Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
118 lines (93 sloc) 5.44 KB

API overview and implementation details

regenwolken currently supports (see http://developer.getcloudapp.com/):

Account

Items

not implemented

regenwolken extensions

  • Empty Trash – remove items marked as deleted. No official API call yet. Derieved from Ajax POST in webinterface. Usage with curl:

    curl -u user:pw --digest -H "Accept: application/json" -X POST http://my.cl.ly/items/trash

Overview

# -H "Accept: application/json"

/*                 - POST files
/items*            - POST (multiple) bookmarks
/register          - POST register (instantly) new account
/items/trash       - POST empty trash
/<short_id>        - GET item details
/account*          - GET account info
/account/stats*    - GET overall file count and views
/domains/domain*   - GET domain info (always returning *hostname*)
/items*            - GET list of uploaded items
/items/new*        - GET key for new upload
/items/new?item['private]=true|false* - GET key for new upload
/items/<short_id>* - PUT rename/recover/change privacy of item
/account*          - PUT change password, username and default privacy
/items/<short_id>* - DELETE item

URLs marked with an asterix (*) require authentication.

Details

While regenwolken tries to simulate the CloudApp API as good as possible using their sparse documentation details, there is one major point, regenwolken handles different: private and public items. CloudApp thinks, items are private, when they have a longer hash. That's no joke, that's their current implementation. When you upload a file without privacy hint, it tries to get the hash as short as possible, e.g. cl.ly/5hd. When you make this item private, the hash will change in something like this cl.ly/29xgnqa49ny84jg83l. This is security by obscurity. In regenwolken, your private items requires authentication. Only when you know the credentials, you have access to your private data.

upload-file (with given privacy)

CloudApp uses Heroku and S3 as their database and storage backend. regenwolken only features one webservice. The upload progress divided into two parts: GET /items/new (optional with privacy specs) to receive the upload URL as well as some CloudApp specific stuff we don't need (AWSAccessKeyId, signature, policy and redirect). Every client behaves the same and POSTs the server's response json to the url, which is my.cl.ly and regenwolken is listening to. You see, GET and POST are completely different requests and URLs, therefore you will receive a key=1234 on /items/new you will include when POSTing your files. If the server accepts your “upload key” (=~ session, timeout after 60 minutes per default), your upload is valid.

HTTP status codes

200 Ok           - everything fine
201 Ok           - register was successfully
301 Redirect     - redirect instantly to new URL
400 Bad Request  - wrong json
401 Unauthorized - requires authentication
403 Unauthorized - authentication failure
404 Not Found    - short_id/_id is not found
406 User already exists - when /register-ing an alreay existing user
409 Conflict     - account not activated
413 Request Entity Too Large - our size limit is 64 MiB
422 Unprocessable Entity - username or password not allowed

HTTP Digest Authentication

CloudApp Network uses digest authentication to prevent sending passwords as plain text over the air. This requires either storing passwords as plaintext or as A1 hash (see https://tools.ietf.org/html/rfc2069). regenwolken uses the last option, salting passwords with username+realm.