I’ve got a suspicions there could be a bug with the user list response from api/v2/users.
Specifically with the contents of the multifactor and multifactor_last_modified properties.
The scenario is that a user has an MFA enrolment e.g. OTP and recovery code. We delete the enrolments using the DELETE api/v2/guardian/enrollments/{id} endpoint (calling for each enrolment), so the user is left with no enrolments at all.
But the api/v2/users list endpoint still responds that they have “guardian” in the multifactor property and the last modified isn’t updated.
However, you can hit the api/v2/users/{id} endpoint for the user in question and the multifactor property is empty.
Further, if I update some other bit of information on the user profile e.g. make a change to the app_metadata and then hit the api/v2/users list endpoint I see that both properties are updated as expected.
It seems that this user list response may be cached in some way and that a call to DELETE api/v2/guardian/enrollments/{id} doesn’t invalidate this cache - or at least that seems to be the behaviour that is presented.
For me I’d expect that to be kept up to date, it would certainly be useful and avoid having to use app_metadata to store the mfa enrolment status for users which seems to be the only alternative that doesn’t require iterating an entire user list by id.
Welcome to the Community, and thanks for the feedback.
This is a result of the search function being eventually consistent. It is documented here.
We recommend:
To get the latest search results, use an immediately consistent endpoint during authentication processes such as Get Users by ID and Get Users by Email. Searches using these endpoints reflect the results of all successful write operations including those that occurred shortly prior to your request.
Thanks for the response and the link. I did not realise there were endpoints that had different consistencies, I was only looking at the API docs not these ones.
In any case, I think there is still a problem. Or at least how long should I expect before an eventually consistent endpoint catches up?
For reference I triggered the behaviour I was seeing around 4 hours ago and the user list endpoint is still showing old data for the multifactor and multifactor_last_modified properties.
Surely its not expected to be hours?
For this use case, getting a list of users what is the recommended approach to have consistent data, even allowing a few minutes of lag say?
That does sound longer than usual, it could depend on the volume of updates you are pushing.
The recommended approach is to use the get users by Id and get users by email endpoints for immediately consistent results. As an example, the Auth0 dashboard lists users by email, then when you click into a user it makes another call to retrieve the users specific data via an immediately consistent endpoint.
Would this strategy work for you? If not, can you please explain what you are trying to achieve specifically?
In principle it would work calling those endpoints again and again but I don’t think it is the correct thing to do and I’d worry about rate limits etc.
Context: Our product is a B2B product. Each business customer has the ability to manage their own users in our custom UI. Part of that management is showing a list of users, not dissimilar to the Auth0 dashboard. That table listing the users shows certain attributes, one of which is whether the user has enabled MFA or not. From a UX point of view it is useful to have this information in the table an not have to click on each user to check the MFA enrolment status.
So back to the problem, we want a response that includes the current multifactor enrolments per user. Which the list users endpoint provides aside from this issue that use of the DELETE api/v2/guardian/enrollments/{id} endpoint doesn’t seem to trigger the response to update as I’ve noted for many hours (I’m not convinced it would ever update without some other change happening to the user profile such as a login etc).
I’d appreciate it if you’d be able to verify that the DELETE api/v2/guardian/enrollments/{id} endpoint should trigger the data to update within a reasonable timeframe.
I was able to test it. Took a few minutes for the search endpoint to be consistent after deleting a factor. As I said, a few hours is surprising. I sent you a DM for more info.