I would expect to see an error if there was something wrong with the request. An empty array makes me think that no user exists with that email. Can you confirm that the user exists and the email is properly formed when you make the request?
Yes the user exists. It’s the only user in the tenant as I’m just starting to build my app.
I used a plus-addressed email address which delivers to my inbox.
I’m using a message queue to handle the creation of the user account in my app based on a webhook received from my payment processor. To that end I’m trying to make the handling of the webhook idempotent.
To do that I need to check if a user already exists… which os where I’m getting this issue.
Did you have a chance to try the explorer? I’m just wondering if it’s an issue of case sensitive or mismatched character. That should give you a definitive answer on whether or not the string should return a result.
@dan.woda I’ve tried the API Explorer and that returns the result correctly by the looks of it.
The problem is with the Stripe.Net SDK then… It must be, because if I use the Stripe.NetManagementApiClient to create a user (e.g. myname+dev-20072023-1@mydomain.com) and then try to query that user by email from the ManagementApiClient it returns no results.
Some questions…
Does it take some time after creation before the user is available on the GetUsersByEmailAsync method?
Does the Stripe.Net SDK have a problem with plus-addressed emails?
With AMQP based programming and message queues, if the message is not acknowledged as successfully processed the message queue will retain it and retry the delivery multiple times. That’s why I need this to be idempotent. The retry mechanism uses an exponential backoff between 1sec and 30 secs before declaring the message failed and moving it to the dead-letter queue.
Is there some other way to make this idempotent? An “Upsert” option perhaps? Or some way to pass an idempotency key to the Auth0 API so I can just call create with an idempotency key?
If I can’t get this working with Auth0 I’ll have to reconsider using Azure AD B2C instead, which I don’t want to do as it means more work on my end to setup & use, but ultimately it’s just got to work.
This code works fine for me. I’m wondering if you are running into a race condition or something that is causing your empty response.
using Auth0.ManagementApi;
using Auth0.ManagementApi.Models;
var client = new ManagementApiClient("xxx", new Uri("https://xxx/api/v2/"));
var newUserRequest = new UserCreateRequest
{
Connection = "Username-Password-Authentication",
Email = "myname+dev-20072023-1@mydomain.com",
Password = "xxx",
};
var createdUser = await client.Users.CreateAsync(newUserRequest);
var auth0User = (await client.Users.GetUsersByEmailAsync(createdUser.Email)).SingleOrDefault();
Console.WriteLine($"Auth0 User {auth0User?.Email}");
I’m not sure what impact the Stripe.Net SDK has on it.
using Auth0.ManagementApi;
using Auth0.ManagementApi.Models;
var client = new ManagementApiClient("xxx", new Uri("https://xxx/api/v2/"));
var submittedEmail = "myname+DEV-20072023-1@mydomain.com";
var newUserRequest = new UserCreateRequest
{
Connection = "Username-Password-Authentication",
Email = submittedEmail,
Password = "xxx",
};
var createdUser = await client.Users.CreateAsync(newUserRequest);
var auth0User = (await client.Users.GetUsersByEmailAsync(submittedEmail)).SingleOrDefault();
Console.WriteLine($"Auth0 User {auth0User?.Email}");
I’m sorry to hear that. What ended up being the root cause? Everything worked how I would expect/as documented from the Auth0 API and the Auth0 SDK. Was it a race condition?
Thanks for following up, I see what you’re saying.
Boiling it down; Auth0 supports cased email, due to the possibility that a provider returns a user object with a cased email address. As a result, the search by email endpoint supports case sensitivity.
Auth0 database connections convert to lowercase, and when using that endpoint you receive no response because you are searching for an email that doesn’t exits (due to the case).
This isn’t a result of behavior of the SDK, so I don’t think the dotnet code analysis rule applies here.
Feel free to create a topic in our Feedback category describing your desired behavior.