User not logged in error when testing (Need to login user - appgyver)

[Eoin_Doyle]

Hey all,

Rookie question here: I’m looking to pass details about a user from the frontend (appgyver), details such as Date of Birth, gender, which club they play for and which team they play for. These will save into the user’s table.

I’ve setup the API (screenshots below) but I’m getting a 3057 error that ‘could not find user by id or identity’.

I’ve followed the guide here to retrieve user object from user token and I’ve also tried Symmetric Dynamite’s trick on saving the user token and id from the login test to test this but still getting this error.

Screenshots of the API setup and test data below.

My app-id is C209BEBE-88E7-1122-FF98-41304F96CA00

Does anyone know what details I’m missing in my setup.
Many thanks,
Eoin

[mark-piller]

Hi Eoin,

The URL shown in the screenshots is for user registration. Do you need to register a new user?

Regards,
Mark

[Eoin_Doyle]

Hi Mark,

Thanks for the reply. No, I’ve already created the user on another page and this page is to add more details to their record.

When I try this without the /register I’m getting a parse error. 8002. Hence why I thought I needed the /register.

Apologies but coding is all new to me and trying to get through the missions at the same time.

EDIT; I should have said - I’m not sure what a parse error means.

Thanks,
Eoin

[mark-piller]

Hi Eoin,

When you use /register it is an API endpoint to register/create new user accounts. If you need to update an existing user, here’s the API for that:

Update User Object - Backendless REST API Documentation

Regards,
Mark

[Eoin_Doyle]

Thanks for this guide Mark. I’d gone through it before, but my challenge was the user-id in the URL. How do i dynamically create this for the API call?

I’ve run the test successfully now but I used the ownerid of my test user.

So my understanding is that this API call will work for this 1 user, but how do I make it work for all the users that will sign up for the app. i.e. is there a way to dynamically complete it in the URL?

Thanks,
Eoin

[mark-piller]

Hi Eoin,

It sounds like a great question for the AppGyver team. I believe the dynamic value for the user id needs to be configured somewhere in their interface, right?

Regards,
Mark

[Eoin_Doyle]

Yes I appreciate that is outside of your scope, but thank you for your help and confirming that it does need to be dynamically generated.

Thanks,
Eoin

[Paul_McCullen (Paul Mc)]

Hi Eoin

Did you ever get this working? I think you need to set the id as a URL Placeholder which in turn you can ‘populate’ using a page or app variable in appgyver…that will make it dynamic. I used this method to pull through (with a GET RECORD) the contents of my Users table.

But I am stuck getting my PUT to work, which will send updated values back to the ‘Users’ table after being edited by the user…was hoping you could show me your working setup!
Thanks
Paul

[olhadanylova]

Hello @Paul_McCullen ,

Maybe this could be helpful:

1. After user is loggged in, you can save user’s objectId as a Page Variable, e.g. userObjectId using the Set Page Variable block.
2. Create the userName Page Variable (I will update only this property) and bind it to the corresponding input field:

3. Create the UpdateUser API, define HTTP Header and URL placeHolder:

4. Define the request and response schema with necessary properties:

5. Select the Test tab, insert objectId, record properties (name) and run test. Test runs successfully:

6. Add the Update User button and call the UpdateUser API using the Data Get Record block. Configure it with necessary values. Bind objectId with userObjectId Page Variable and record properties with the userName Page Variable:

As far as we already binded it to the corresponding input field, we’ll get the newest userName value as soon as input value is changed.

7. Press the Update User button. User should be updated in the Backendless database.

Regards,
Olha

[Paul_McCullen (Paul Mc)]

Thanks Olha

I think I had two problems;
I had not populated request schema, I was populating all the fields in the ‘Custom Object’ under ‘Record Properties’ to test which were coming through as a default, presumably from the schema for my GET…Perhaps this was actually OK, but actually doing it your way enables me to cherry-pick the fields I want to update…

BUT my big problem was that I had the user-token in my header…and removing that seems to make it work. This is perplexing because the Backendless documentation states that you need the user-token in the header to update ‘Users’. But clearly not!

One little question just for my understanding - what is the difference between ownerId and objectId? I can see in my table the fields are populated with the same value, just wondering if that is ever not the case?

Thanks so much for your help. Sometimes I just need a hint after I think I have tried everything…I have been relying on Appgyvers nifty ‘get schema from response’ functionality so I haven’t had to think to much about that SCHEMA section in the API but I now know I need to populate the request section when POST or PUT…and presumably DELETE…thats the crucial bit I was missing right?

Thanks

[stanislaw.grin]

Hi @Paul_McCullen,

here is information about the ownerId:

https://backendless.com/docs/rest/data_security.html

[LAYER 5] Owner Policy.
When a new object is created in Backendless, the system automatically links it with the account of the user that made the call to save the object. You can see that information in the 'ownerId' column in any of your tables in the data browser. With the association between objects and users (owners), Backendless provides a way to control whether users can get access to the data they created. This is done through a concept we call ‘Owner Policy’. To navigate to Owner Policy, select a table in the data browser and click the PERMISSIONS menu. Click the OWNER POLICY menu item.
Granting a permission for an operation in Owner Policy, guarantees that the objects owned by the current user will be allowed access for the specified operations. Denying a permission, takes out the ‘owned’ objects from the collection of candidate objects to return.

The objectId column is just a unique record identifier.

Regards,
Stanislaw