Today we’re going to take another look at security configurations in Backendless. In this article, we will talk about how to restrict direct access to your data via API and only expose your custom API endpoints. This does not mean you should use some other set of “admin” APIs for data management. Instead, it is accomplished by setting up proper security settings.
Backendless provides ways to set up really granular permissions for your resources, including even row-level security in your data tables. But for this task, we’re only going to need system roles and global permissions. Thus, it won’t require you to do a lot of configurations or create additional assets, such as custom roles.
Have you ever wondered why is it often so tedious so make your simple Java app a web server, with the methods becoming the endpoints? You need to add libraries, write additional “web” wrappers, set up a server and a hosting, configure load balancing and much, much more. Do you really have to go through all these things when you just want this piece of code be available via the Web so that others can invoke it and get some fancy results?
The good news is that nowadays this is much less of a problem: with services like Backendless, it is easy to transform your custom code into a real REST service available via both REST and JS/iOS/Android/Java APIs. If needed, authentication also comes available out-of-the-box. It is worth noting that this is all for no charge except for the number of API services you may have and the number of API calls you’ll make to the service in a month.
In this article, we’ll show you how to make your HelloWorld app really say Hello to the whole World.
As you may have noticed in our release history, the EXTENDED STRING data type was removed almost a year ago. To be precise, it was more a merge of the STRING and EXTENDED STRING data than the removal of the latter. This means now you can safely use STRING data type for any kind of characters (including emoji! ????) without worrying if the column would support it. In addition, the sorting order for multiple non-Latin languages has been fixed automatically.
Relieving developers from the hassle of two string types has always been one of our main goals, and this is another small step in that direction.
In this post, I’ll explain our reasoning for introducing the somewhat confusing EXTENDED STRING data type earlier and how we managed to finally solve the initial problem with no additional complication for the developers using our platform.
From time to time, we see some developers struggle with understanding the principles of asynchronous work with Backendless. In this post we’ll try to shed more light on this aspect: describe what async calls are, why you need them and how to properly perform such calls and process the results. This post will be specific to Java and Android, but most of the principles apply to any language and environment.
This post will show you how to implement a kind of “expiration” for your data objects. The strategy is sufficiently abstract, so it’s applicable to any resource you need to expire, including files, logs, and so on.
Since the database does not have any built-in expiration mechanism, we’ll have to implement it on our own. Fortunately, the task is pretty easy because we have access to Backendless Business Logic. The idea is to create a Timer, which is going to run with some fixed time period and delete the resources based on your criteria.
One of the final steps before you release an app is to setup proper security. Specifically, the security of your File Storage is perhaps the most important since it may contain your business logic code, your public website data, your logs, and any other assets which you probably do not want anyone from the outside to be able to see. This post will provide a few guidelines on how to structure your File Storage with security in mind and instructions on how to set up the permissions properly. The sample use-case will be a bit over-concerned with security, so you most likely won’t need all of this for your specific case, but you’ll be aware of what to do in the worst case.
If you’ve worked with Backendless API for a while, you may occasionally run into a situation where the functionality you’d like to have isn’t readily available. One such function is the programmatic management of your application’s data tables. For instance, you may need to clear up all the data and recreate the table structure with specific columns on demand while developing your app. This article will show you how to do that and more.