Cloud Storage

Cloud storage is used to store media on the Relevance platform. It can handle all types of media (images, pdf's...) to be used accross the platform, for instance in articles, newsletters or plugins. It is not a streaming platform and therefore is not the ideal solution for storing streaming media (e.g. videos or audio).

Media is organized into buckets, which can be accessed by users. Buckets have PUBLIC and PROTECTED sections. Media in a PUBLIC section can be accessed by anyone with the URL. Media in a PROTECTED section can only be accessed by users with READ access to the bucket. Users will need WRITE access to the bucket to upload or remove media from either PUBLIC or PROTECTED sections. Listing the contents of a bucket always requires READ access (even for PUBLIC media).

If you are using nodejs, ORTEC can provide a Cloud Storage client library.

Authorization

In order to perform a Cloud Storage request that requires authorization, you will need a Cloud Storage user (provided by your ORTEC service contact). The user will have an ID and a secret key which are used to sign a JWT token to be provided with each request as a Bearer token in an Authorization header.

The JWT token must contain the following payload:

{
  "sub": "my-cloud-storage-user", // The ID of your cloud storage user
  "exp": 1516239022, // The time at which the token expires
}

You must then sign the JWT using the secret key using the symmetric key algorithm (HMAC SHA256), to create a JWT token that looks like:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJteS1jbG91ZC1zdG9yYWdlLXVzZXIiLCJpYXQiOjE1MTYyMzkwMjIsImV4cCI6MTUxNjIzOTAyMn0._Ym34er5qdR4rgpcmmwHupjUHMUKG3CUVmy4jX0hQNw

Finally you include this token as Bearer token in an Authorization header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJteS1jbG91ZC1zdG9yYWdlLXVzZXIiLCJpYXQiOjE1MTYyMzkwMjIsImV4cCI6MTUxNjIzOTAyMn0._Ym34er5qdR4rgpcmmwHupjUHMUKG3CUVmy4jX0hQNw

Handling Media

All media in Cloud Storage is identified by a path with the following structure <visibility>/<bucket>/<media_path>, for instance public/277/images/my_image.jpeg. This means the image is in the PUBLIC section of bucket 277. The <media_path> may represent a nested structure using backslashes (similarly to a file system path), in this case images/my_image.jpeg.

The URL of the media in cloud storage is then simply <cloud_storage_host>/<path>, for instance on DEV this would be https://storage-dev.imgzine.com/public/277/images/my_image.jpeg.

Uploading Media

To upload media to Cloud Storage, make a POST request to the path of your media. For instance to upload the /images/my_image.jpeg media to the PUBLIC section of the 277 bucket, make the following request:

POST https://storage-dev.imgzine.com/public/277/images/my_image.jpeg

and include the media raw data (utf8 encoded) as the request body. You can update media by making a new POST request to the media path with the updated content.

Fetching Media

You fetch media by making a GET request to the media path:

GET https://storage-dev.imgzine.com/public/277/images/my_image.jpeg

Renaming Media

You can rename media by making a PUT request to the media path with the following payload:

PUT https://storage-dev.imgzine.com/public/277/images/my_image.jpeg

{ 
  "action": "move", 
  "dest": "/images/my_renamed_image.jpeg" // should not include visibility or bucket.
}

Deleting Media

You delete media by making a DELETE request to the media path:

DELETE https://storage-dev.imgzine.com/public/277/images/my_image.jpeg

Checking Media Exists

You can check if media exists without actually fetching the media by making a HEAD request to the media path:

HEAD https://storage-dev.imgzine.com/public/277/images/my_image.jpeg

HTTP response 200 if the media exists, and 404 if it doesn't.

Listing bucket contents

You can view the contents of a bucket (as a list of media paths) by making a GET request to the bucket path:

GET https://storage-dev.imgzine.com/public/277