fusionauth-netcore-client

fusionauth-netcore-client copied to clipboard

Here's the relevant section of the example code https://github.com/FusionAuth/fusionauth-netcore-client/blob/master/fusionauth-netcore-client-test/fusionauth-netcore-client-test/test/io/fusionauth/Example.cs

  public User GetUserByEmail(string email) {
      var response = client.RetrieveUserByEmail("[email protected]");

      if (response.WasSuccessful()) {
        var user = response.successResponse.user;
        return user;
      }
      if (response.errorResponse != null) {
        // Error Handling
        var errors = response.errorResponse;
        return null;
      }
      if (response.exception != null) {
        // Exception Handling
        var exception = response.exception;
        return null;
      }
      return null;
    }

However, if you serialize the response object, you see that the status code is returned, not the exception or errorResponse objects.

using Newtonsoft.Json;
//...
string json = JsonConvert.SerializeObject(response);

If I pass the wrong API key, I get this response when I print the JSON:

{"statusCode":401}

And if I pass an email address which does not exist in my fusion auth databse, I get this message:

{"statusCode":404}

So, I'd suggest either wrapping these error codes in the error objects provided, or changing the example app code to be:

   else if (response.statusCode != 200)
            {
                // Exception Handling
                var statusCode = response.statusCode;
                return null;
            }

Here's my software versions:

FA: 1.15.5 FusionAuth.Client (from .csproj): 1.15.7 Target .NET framework: netcoreapp3.1

The API error paths usually respond with status codes and exception messages. The only two statuses that don't have interesting messages are the 401 and 404. (and 500 but those shouldn't happen)

As per the documentation, an invalid Authorization header results in an empty response body. errorResponse is extracted from the response body; exception is set when an Exception is caught inside the SDK. So it works as intended.

@synedra This can be closed.