We do constantly update and improve our image delivery and storage service rokka.io and we'd like to talk about some new feature since the last update here. You can always check the changelog for public additions or follow us on Twitter for the latest and greatest on time updates.

Option for JWT based API Tokens for authentication instead of API Keys

To access the rokka API until now, you needed the API Key which you get on sign up and of which you can create new ones in the Dashboard or via the API. This is fine for most of its use cases, like storing it somewhere on the server side. But maybe not so much when many people, you may not even know, need and have access to such a key. Be it even only with limited rights like for uploading some images or read only access. The problem with rokkaā€™s API keys is that they are valid forever (until you revoke them) and can be used from everywhere.

We could have added time-limitable API Keys, but we chose another path: JWT tokens, which you can get via the API (and an API Keyā€¦). They do need an expiry date and can also be IP limited. You can also make them renewable or disallow that. And more limitations could be added in the future.

You most certainly donā€™t need such tokens, if your code runs on the server side anyway and you donā€™t need to give out that key to many people or store it somewhere not trustworthy.

But for browser based access to the rokka API directly, there are at least three good use cases for such tokens.

Of course you could run all your communication needed with the rokka API through your backend and wouldnā€™t need to give out any credentials. But either you do not even have a backend (the rokka Dashboard and the rokka Gallery are just static sites in the end) or you want to avoid unneeded latency and stressed resources on your backend and directly talk to the rokka API from the browser. For example for uploading large images and videos.

The technical details of all this are documented in the authentication chapter of the rokka documentation and our PHP library (in 1.17.0) and the JavaScript library (only in 3.7.0-rc.1 yet, stable release will follow soon) do have already support for all this. And the Dashboard and the Gallery do use these new API tokens already.

But now to three possible use cases:

1. No need to store the API key in the browser, just the limited token

This is what we do in the mentioned dashboard and gallery. People login with their organisation and an API Key, we then fetch an API Token directly from the rokka API and just store that in localStorage, but not the API Key. The token time limited to 3 days, we restrict it by IP (but do remember the last few used ones, so you donā€™t have to login all the time when switching IPs) and try to renew it after a day. The rokka.js library takes care of most of that, except the multiple IP limiting. The rokka.js file in the dashboard is an example of how to do all that.

Even though the end user still needs to know a valid API Key, at least we donā€™t store it in the browser permanently. So that if someone could steal the credentials somehow, it will only be valid for 3 days (but can be renewed within those 3 days in the above setup) and more importantly only from the IPs the user itself logged in. We add some additional layers of security this way.

2. Have more control over who has access to it

This is more or less an extension of the above. Letā€™s say you want to give more granular control to such a site, but not wanting to have to create an API Key for each new user (you could revoke, when the access of a user should be revoked, but that gets cumbersome). You also would lose control of what the users do with such an API Key, like reusing it somewhere else. But you maybe do have a backend already with some single sign on solution and user based access control.

In this scenario, your rokka.js based frontend would then ask your backend for an API token, log in people if theyā€™re not already, the backend generates that token through the rokka API and the (only stored in the backend) API Key, makes it time limited for like a day and marks it as non-renewable. And even can make it IP protected, if thatā€™s what you want.

The end user then only gets this token, when they log in. And should their access get revoked in your backend, they donā€™t get a new token the next day. In an emergency case you could also rotate the used API Key on rokkaā€™s side and all your valid users just would need to get a new token from the backend, but the non valid users get immediately rejected with their otherwise maybe still valid token.

3. Give only very time limited access

Uploading images and videos can be resource intensive and need some bandwidth and intermediate storage. Therefore instead of uploading such assets through your backend to rokka, you could give out very time limited and non-renewable API tokens (eg. for 15 minutes) and let your users directly upload images from their browser. After that, they need a new token from your backend (where you also could build in some rate limiting or such). Just donā€™t forget to report to your backend after the upload, what kind of image (especially the rokka hash) was uploaded and update your database with it. And maybe do some cleaning up of stale images from time to time.

Membership management in the rokka Dashboard

Until recently, you could only generate/delete/edit memberships for your organization through the API. No more hassles now, you can directly do all that within our dashboard.

This makes it much easier to generate new users and their corresponding API Keys with for example less rights than the default admin user. Or to add users from another organization.

It will also list when that user was last used to access the organization and you can even add a comment to each membership. This can help a lot in cleaning up your access rights at a later time.

You can also generate new API keys and delete old ones for the currently logged in user directly in the dashboard.

Those features are all also available directly with our API and are documented.

rokka service status page

Since about two months, we do have a service status page reporting about the current status of our services. You can even subscribe for email alerts, if something is down. Go to status.rokka.io to see it in action.

And one more thing: Custom Sourceimage hashes

This feature is not released yet, but may soon come, so hereā€™s a little sneak peak.

Currently, when you upload an image or video to rokka, youā€™ll get back a hash generated by us. And the same hash if you upload the exact same image again. With this hash you then access the image in the future, you must therefore store it somewhere to get that image again, as there is now way for you to predict this hash. All our plugins and custom implementations do that somewhere in a database or even just the file system.

But for some setups, this may be too complicated or too cumbersome. It would be much easier, if they could calculate that hash from some unique identifier and use that, with no need to store and use our calculated hash. And thatā€™s what we will soon release. You can then provide your own hash while uploading an image and work with that.

There are some caveats with this approach and one can easily make mistakes. But if you take care of the prerequisites, it could be a new way to store those hashes and saving you some trouble somewhere else.

One of the caveats is that the hash really has to be unique for each image. You canā€™t reuse the same hash for another image, our API will complain then. For example, if you have some images per product in your e-commerce store, you canā€™t compute a hash from just for example product_id and image_position. That will work the first time, but when some one exchanges the image at a position and this image would get the same hash as the one before, rokka will reject it. Mostly due to caching reasons in the CDN and the browsers, but also due to the very basic principles of rokka: One image, one unique hash.

The easiest way to avoid this is for example to compute the sha1 hash from the binary file (thatā€™s basically what we do on the server side, with some additions for dynamic metadata). Thatā€™s guaranteed to always produce a different hash, even if the image is just slightly different.

Or if you generate a database entry anyway for each uploaded image, you could take the unique ID of this to generate the hash. No need for additional fields for the rokka hash and keeping track of them.

Thereā€™s some more caveats regarding dynamic metadata, but that shall be enough for this little teaser for now. We will certainly report, when itā€™s ready. And if youā€™re interested already or see some use case for you, weā€™re happy to hear from you. We do have a public Slack organisation, where you can reach out to us, or check our contact page for all the other ways.

Photo by Pop & Zebra on Unsplash