Updated JS library URLs
We’ve switched to using a CDN to serve Kloudless JS libraries. While the old URLs work, you’re encouraged to switch to the new URLs for the File Explorer and Authenticator JS libraries.
Since a CDN optimizes for serving static files closer to your user, switching to the new URLs for either or both JS libraries will result in less latency to load the JS file. Reducing the bottleneck will give your users a better experience with the File Explorer and Authenticator.
New Regions Added
Kloudless has also added the us-east-1 AWS region in addition to us-west-2, for faster API requests as well as quicker downloads and uploads for your end users who are closer to the east coast. Sign up for your free Kloudless developer account to experience the speed yourself!
We’d love to hear your thoughts on Kloudless — reach out on Twitter @KloudlessAPI, StackOverflow, IRC, or in the comments below.
Downloading files via File Explorer links
The File Explorer now accepts an option named ‘direct_link’. When true, the links created via the File Explorer will download the file for the user, rather than present a view for the file in the appropriate cloud storage service.
This functionality enables your app’s users to download and create local copies of the file — perfect for collaboration and file transfer use-cases.
Embedding links in web pages
Speaking of direct links, they can now be accessed with an “inline=true” query parameter that sets the Content-Disposition of the downloaded file to “inline” rather than “attachment”.
This is useful when embedding links in web pages, since you can display the content for your users directly, instead of through the cloud storage service.
Give Kloudless a try — we’re available to help on Twitter @KloudlessAPI, StackOverflow, IRC, or in the comments below.
Question: We are using Kloudless to enable efficient file uploading from the client side. The Kloudless API Key and account ID will be public from the client side.
Other than setting the trusted domains, is there any way to protect it right now?— Kloudless Developer, Palo Alto CA
Answer: I would definitely not include the Kloudless API Key on the client-side because this creates a security risk. Use the users’ Account Keys instead. Account Keys function the same way as API Keys, but only provide access to the connected account.
Here’s how you can use Account Keys with the File Explorer:
Account Keys can be returned from the File Explorer by setting the “account_key” option to true. They are only returned to Trusted Domains (you can add your domain as a Trusted Domain via the App Details page in the Developer Portal). Once you have the Account Keys set on the client-side, you can use them to make requests. Additionally, Account Keys can also be retrieved via the backend as well.
Account Keys are also useful when you want to show returning users which accounts they have already connected previously. Storing Account Keys for the user gives you the ability to render user accounts on the client-side and pass them in via the “keys” option. All of this happens while instantiating the File Explorer, which will display the corresponding accounts to the user automatically.
This approach protects your Kloudless API Key. If you want to dig deeper into how the Kloudless API handles Account Keys, check out the docs. You can also use the Interactive Docs to list account keys for your account, request Account Keys or get information about Account Keys. If you have any other questions, just let me know. I’m reachable at firstname.lastname@example.org. — Vinod Chandru, VP of Engineering / Co-Founder @ Kloudless
Have any questions about Kloudless or file storage in the cloud? Ping us and ask!