Handlers are not working on some tables

Backendless Version (3.x / 5.x, Online / Managed / Pro )


Client SDK (REST / Android / Objective-C / Swift / JS )


Application ID


Expected Behavior

I’m using many handlers to enforce multi-tenancy and modify where requests to return results of the user organization.

Actual Behavior

I’m registered to beforeFind of all tables
CleanShot 2021-02-05 at 11.40.57@2x

Some tables trigger those handlers like OrganizationSettings
CleanShot 2021-02-05 at 11.46.25@2x

But atleast two tables dosn’t trigger them which cause data leaks as users are getting records they shouldn’t get. table classes and table pickuptimes for example

Reproducible Test Case

  1. enter my application in the backendless console
  2. connect with a user I sent in the email
  3. execute get request for table OrganizationSettings and observe logs - beforeFind works
  4. execute get request for table Classes and observe logs - beforeFind is not being executed and although it is in Hebrew you can see that if sorting by name you get records of two different organizations instead of one of the organization if the handler was working. Observe the logs you will not see any handler logs

Just FYI this site goes to production on Sunday but only if the data is secured and doesn’t leak between organizations, otherwise I will need to postpone it :frowning:

We are trying to reproduce your problem to find the cause.
But it requires a time.

1 Like

I see in real-time logs next:

13:39:26 | SERVER_CODE | INFO | [11054] register unsupported handler for event beforeTransaction
13:39:26 | SERVER_CODE | INFO | [11054] [99f76c45-7400-45d1-ae0e-79efa03bf465] [INVOKE HANDLER] persistence.beforeFind (*)
13:39:26 | SERVER_CODE | INFO | [11054] http error 403 UnknownUser(5) - unknown user or user organization (userId)
13:39:26 | SERVER_CODE | ERROR | [11054] Error: unknown user or user organization (userId) at httpNotAuthorizedError (/opt/backendless/repo/8c7488e9-5871-4a47-ae5e-2e43e03b85fc/files/servercode/JS/default/PRODUCTION/lib/utils/errors-utils.js:17:10) at getUserInformation (/opt/backendless/repo/8c7488e9-5871-4a47-ae5e-2e43e03b85fc/files/servercode/JS/default/PRODUCTION/lib/adapters/utils.js:44:51) at IsufService._initialize (/opt/backendless/repo/8c7488e9-5871-4a47-ae5e-2e43e03b85fc/files/servercode/JS/default/PRODUCTION/lib/isuf-service/isuf-service.js:75:65) at IsufService.isSuperUser (/opt/backendless/repo/8c7488e9-5871-4a47-ae5e-2e43e03b85fc/files/servercode/JS/default/PRODUCTION/lib/isuf-service/isuf-service.js:52:16) at Object.handleRequest (/opt/backendless/repo/8c7488e9-5871-4a47-ae5e-2e43e03b85fc/files/servercode/JS/default/PRODUCTION/lib/handlers/persistance-all.js:20:25) at Domain. (/usr/local/lib/node_modules/backendless-coderunner/lib/server-code/runners/tasks/invoke-handler.js:118:38) at Domain.run (domain.js:370:14) at /usr/local/lib/node_modules/backendless-coderunner/lib/server-code/runners/tasks/invoke-handler.js:117:7 at new Promise () at execute (/usr/local/lib/node_modules/backendless-coderunner/lib/server-code/runners/tasks/invoke-handler.js:52:10)

Could it be that this error is the cause of the problem?

By the way, for me the beforeFind work for both tables.

Now it works, you can see that querying the classes table trigger the handler

What did you do to fix it? does it require something different in my deployment code so it will not happen again?

also to answer your question. the problem was that user didn’t get that error message. The reason you get the error i because the handler now did it’s part and prevented access while before it didn’t work and user was able to query whatever he wants.

So seeing the error actually mean that now the server behave as expected. But as I mentioned in the previous message I would love to hear what fixed it, because if it can happen randomly it is problematic for multi-tenant solution that is basing the permissions checks on the handlers

Honestly, nothing.
Just went through the steps you’ve described.

There is one thought, that it can be related to the new release which was yesterday. Maybe some old information about tables state were cached. Anyway, now i can not say much about that.

Hmm… actually I hoped that you find a bug.

I’m thinking out load how can I know that it wouldn’t happen again… maybe I need to move all my logic to services and deny direct access from outside… Do you have other suggestion?

I just want to explain my concerns. Since I implemented multi-tenant architecture I’m counting on the handlers to limit the queries to items relevant to that user. For example running the beforeFind handler will add the following to the where clause automatically:

The issue I had was that got access to information of other organizations as the beforeFind ‘*’ didn’t kick-in

Please advice

Hello @Eran_Sakal

Have you encountered the same problem after first reporting it to us?

I can also suggest that you implement this logic completely through a service in Business Logic.


Hello Inna,
Thank you for contacting me again. It didn’t happen again but because it has huge impact on my application vulnerability (because I’m using it to enforce multi-tenancy roles) I must to something.

Unfortunately I must allow access by javascript to the application for back office so the option to use only BL is not possible.

I was thinking maybe instead creating a timer that will query some tables every 1 minutes to verify the content it receives (obviously it will use the rest api key).

But i’m wondering if I should check all the APIs exposed or only find…

It’s hard for me to say exactly how you need to redo the logic. You need to try and make your logic to the expected result. We will try to make sure that the situation that you have encountered does not repeat itself.


The issue happens again. If you will access my application you will be able to reproduce it now with a table named loginsAudit. Last time it resolved it self after some time so if you can check it now it would be great!

As mentioned I’m counting on those handlers to enforce multi-tenancy, without it everyone can access other tenant information.

Because it happens randomly I cannot run an API monitor to capture it, if I will do that I need to run it against all types (find, create, update) for all the tables which doesn’t make sense.

I sent an email with a screenshot of the problem.

Please advice it creates a security issue.


Hello @Eran_Sakal

Thank you for the video.
I believe it doesn’t run Bl because of Roles Permissions.
I can see that you are logged-in in the REST Console, so make sure this user has access to the data.

Regards, Vlad

That is awesome if this is the case but I just want to verify
according to the permission guide Security - Backendless REST API Documentation

Layer 8 it the last layer that affect the decision and in my application is is explicitly set to false

so in such a case you return 200 with empty array and not an error?

yes, it will return an empty array

Thank you!

@vladimir-upirov I unchecked the “solution” mark because the original issue is not related to the followup one. In the original one I saw all the records the table had because the filter I add in the beforeFind handler wasn’t added as the handler was not invoked.

I understand you correctly don’t have a way to reproduce it. For now it didn’t happen again but I keep this thread as-is if you will find a reason of if it will happen again.

If you prefer to close the thread do so


@vladimir-upirov @mark-piller it happens again now. I sent a video to the support email.

I really need your advice here. If I’m doing something incorrectly let me know, if this is a bug I need to know that you found it and when it is going to be handled.

If you don’t think it is that important let me know so I will be able to decide how to proceed.

I LOVE Backendless and already spent so much time learning the platform, interacting with the features and building an application that should help institutes in Israel during the Corvid. Backendless provides such an amazing platform with custom code generation, powerful console, great documentation, server services, roles… what’s not. I’m amazed with its capabilities. But if it fails in the security / stability areas I’m lost.

I really hope you will find a problem on my side and I will then apologies for writing the above. Otherwise, I need you to give a hand and figure it out.


Although in Herbrew, you can see how it affect the application as user can select and set relations of cross organizations

It is my understanding that previously the handlers were not invoked because the currently logged in user didn’t have permission to the tables. So when you say it happens again, is it for the same reason?

I had an issue with the size of the video I sent to the support, I resent it with a link to google photos.

Regarding your question, see the original problem (the first thread). I’m experiencing the same thing as the original issue which is not related to permissions. Oleg Vyalyh tried to reproduce it but when he tried to do it, the handlers already started working.

So it is not related to permission