Support Topics Documentation Slack YouTube Blog

Real-Time Database event

i have a need to check if the client has set a Conditional Delivery when he add the listener.
same as with real time messaging.
how can i set that?

What do you mean by conditional delivery here?
Does this doc somehow related with your question?

So I want to reject the client if there is no condition specified.

Hello @mohammad_altoiher,

Could you please clarify your question?
The example in the documentation provided by @KamiMart_KamiMart should be suitable.


I don’t think/know if Backendless server provides such capability.
While I don’t understand clearly what you’re trying to achieve here, if the client specifies/defines a condition on its own, then why bother rejecting a query a client supposed to try to execute/send to the server?
You can just opt out query execution if there is no condition specified, using a simple conditional statement such as if-else or switch/when.
Maybe you want to achieve some kinds of filtering capability within your app, perhaps? If so, then it makes sense. But one should not reject a client if there is no filter/condition used, that would be bad I think.

@olhadanylova @KamiMart_KamiMart
That is what i want and i’m doing it fine.
but i’m a afraid that someone “hacker” could add a listener with no conditions and see what he shouldn’t see
i don’t want the client to have the final word of the where clause.

You are worrying about hacker adding unauthorized listeners to your data within your app? Well, I had never thought this scenario, but you should tagged this question into security as this mainly represents security concern, particularly mobile app security. You are developing a mobile app right? I saw your concern regarding real-time listeners within a mobile app in other post in this forum.

I think it’s weird. Your client should make a request on what data to be queried, hence determining the condition. The server is as just as its name: its serves the client, no more and no less. It’s job is to send query results, perform some computations, etc.

Well, you can secure your database using ACL for example, as well as strengthening it further by using some roles based on users specification of yours (for example: free users can only access data A and B, while premium users can access all data, etc.). If you are using Backendless Cloud, the team should handle all the heavy lifting on security, particularly on the server side, unless you are using Backendless Pro in your own Cloud/VPS which you have to secure it by your own (from DDoS for example, implementing SSL/TLS, traffic scrubbing, IP whitelisting/blacklisting, etc.)

Your security concern is happening in the client side, then it’s your full responsibility to take care of it.
You should obfuscate your code, and makes your app hard to be decompiled in order to prevent this scenario from happening. That’s what I am doing to every mobile apps I developed, whether it’s personal or for clients.

There’s no way the server have the final word of the where clause; it’s determined and defined solely by the client, and then the server processes the query as it is and then delivers the query results.

If you’re worried so much about this, then don’t let anyone know your API_KEY and APP_ID, as well as don’t let others know about any tables that exist in your database. It’s people problem though; not the system. We are living in the world where security stands by obscurity, nothing is safe. Our job is to make it as secure and hard to attack as possible.

1 Like

But you know that the client is never to be trusted no matter how you obfuscate your code. if you want to be save.
and if in my event handler (which is available to the real-time messaging) the server will have the ability to deny the listener request passed on the where clause content.
ACL is there but you cant relay on one wall (not ACL fault but human error might happen with big project) when you can handle all the listener requests with one event handler like a gate. i like it.

i have made a couple of browser apps and mobile apps. and you will be amazed of what people can do to hack :sweat_smile:

Well, maybe its up to the team to answer this further.
But from what I see and think, there is no denial about what requests coming from the client.
Yes, we should not rely on only one security mechanism, but any of those thoughts will be denied by the platform limits and capabilities.
Generally speaking, the server may never know the where clause. No matter what you are trying to do, it will be still in the client side. Never trusting a client/app is correct by the principle of obscurity, but you should know that most attacks that going to the server are performed on the client. If your client can be protected well, you can avoid this scenario from happening.

Maybe what you are trying to say is if a hacker somehow can attach a listener to your database and then listen to any events in that db as well. since hacker needs to know API_KEY, APP_ID, the name of the table to do this, which all exist in the client, then the client should be protected properly.
Hacker usually decompiles your app to fetch those data in need.

I think it does not change anything, you must keep sensitive credentials that point to yout server as secure as possible, and secure the client properly.

i really wish i can :joy:
Thanks a lot Kami for your help on this matter!

You surely can.
As I point out before, hackers need some data such as api key, app id, and table name particularly to attach a listener, then as long as you can secure those information/credentials and keep them away from anyone you should be okay. Those information resides in the client that accesses Backendless server, so in this case I stay firm with my suggestion to secure your client/app properly.

Glad to help on this one :slight_smile:

Maybe someone from the Backendless team can clarify/give further information on this matter.
But if you think that this issue is solved, and for the good of this forum, consider adding anyone’s answer you think as the fittest solution so it can help others people that have similar problem/issue as yours.

i still need the response from the team :slight_smile:

But if you have some time, care to share guidelines to secure the code and keep the credentials away from access?

@olhadanylova @mark-piller
do you have any idea how to use this with real time database?

@mohammad_altoiher the only way to protect your data is to set up correct permissions.
For example, you subscribe as described in the guide
And if a user that subscribes for the data has no permissions to get the data he will not receive the data with RT.