NotAuthenticatedUser required for User autoload related tables on logon

Hi Team,

Interesting one, my User table has a child that is set to auto load. On login the backendless user payload returned had this child as null. After playing with the permissions I found that the child table needed the ‘NotAuthenticatedUser’ permission on retrieve set to on for it to load on login.

So it looks like the login process doesn’t class the user as authenticated when returning the payload meaning I need to give the ‘NotAuthenticatedUser’ access to retrieve on my child table. This isn’t ideal, is this expected?

Please note the user that’s doing the login is using a custom api key which has retrieve set on the child table (authenticated user also had retrieve set)

Hi, @Reece_Smith

I need to ask you some questions to get a better understanding of your issue. As far as I understand you have a handler enabled on the Users login (before/after) which adds a record to the child table when a user logs in? Please provide us your appId. And steps to reproduce the issue. Also, it would be helpful if you provide us a simple code request requiring to reproduce it in some other apps. Thanks in advance.

Regards, Marina

Hi Marina,

No handler, when a user logs in, the backendless login method sends back the user object (this is standard backendless functionality). The issue we face is we have a column on the user table called checkIn which is set to autoload. But when the user logs in, the checkIn child is null (in the object returned). The only way the checkIn object isn’t nuill is if we set the ‘NotAuthenticatedUser’ on the ‘CheckIn’ table.
This suggests that when the user logs in, the backendless login function that returns the user object isn’t classed as authenticated, thus we need to set the ‘NotAuthenticatedUser’ on the child table.
App id: removed.

Login without the set ‘NotAuthenticatedUser’ on the ‘CheckIn’ table

Login with ‘NotAuthenticatedUser’ on the ‘CheckIn’ table set to Retrieve:

The only difference is the not authenticated user flag:

Hi Reece,

My understanding is the backend retrieves the user object that’s being authenticated before the authentication is checked. If the user is authenticated, we do not go back to the database to re-retrieve the object (I believe this is done for performance-enhancing reasons). A workaround for this issue can be adding an afterLogin event handler that would enrich the returned user object with the related entity.


Makes sense. Thanks for the explanation. Catch you soon