I have 2 questions regarding the ruby-auth0 toolkit.
Currently I’m testing the Auth0 management API through a machine-to-machine application with limited scope ( update:users, delete:users, read:users_app_metadata, update:users_app_metadata, create:users_app_metadata)
The first action I’m trying out is deleting a user. I’m currently doing this with the following code:
This seems to work perfectly when passing a well formatted user_id . When the user exists, it gets deleted.
Though the return value of the delete_user method is just an empty string.
You are unable to check if the user is indeed deleted.
I tried this by passing a wel formatted user_id, but that user_id is non-existant. In that case, I also get an empty string returned from the delete_user method. When I capture the http response, I see Auth0 returns a 204 status with no content.
Is there a reason why there is no 404 response when a user could not be found, or at least getting a return value from the delete_user method that can be used to check if a user is properly deleted?
Another related question is, if the usage of the Auth0 management API is the correct way to be using the API for user data manipulations ( updating user info, closing user account).
The idea would be that that logged in user, should update its own data or close it. So perhaps this should be done in another way, where API calls are automatically only applicable on the currently logged in user space.
As it has been more than a few months since this topic was opened and there has been no reply or further information provided from the community as to the existence of the issue we would like to check if you are still facing the described challenge?
We are more than happy to assist in any way! If the issue is still out there please let us know so we can create a new thread for better visibility, otherwise we’ll close this one in week’s time.
204 is the code for “this thing is gone” so passing a user ID that does not exist will just confirm that it’s not there. That code will tell you that the user ID is gone, regardless of what you send it. If you want to check for the existence of a user before that, you’ll want to get the user first:
For your second question … the model we generally use is that the user data is under control of the tenant/account that manages the user store. Users can update their own passwords (reset password link) but, aside from that, your app will need to decide what a user can and cannot do and implement that via the Management API. Using the session in your app to confirm that an action can be taken, you can implement a profile edit screen and do a client credentials grant to perform the changes:
As of v4.6.0, that will be performed automatically if you don’t pass in an API token.