API overview and implementation details
regenwolken currently supports (see http://developer.getcloudapp.com/):
- Change Default Security
- Change Email
- Change Password
- View Account Details
- View Account Stats
- View Domain Details
- Bookmark Link
- Bookmark Multiple Links
- Change Security of Item
- Delete Item
- List Items
- List Items by Source
- Recover Deleted Item
- Rename Item
- Upload File
- Upload File With Specific Privacy
- View Item
curl -u user:pw --digest -H "Accept: application/json" -X POST http://my.cl.ly/items/trash
# -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.
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
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,
POST are completely different requests and
URLs, therefore you will receive a
/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.