ory / network

Ory runs a global end-to-end security infrastructure for humans, robots, and servers. We build and use open source software.
Apache License 2.0
81 stars 6 forks source link

.NET Client Api call ListIdentitySchemasAsync not working #80

Closed roboptics closed 2 years ago

roboptics commented 2 years ago

Preflight checklist

Describe the bug

Unable to call the .NET Client Api function ListIdentitySchemasAsync(). The error below is returned.

Required property 'blob_name' not found in JSON. Path '[0]', line 1, position 867.

Seems to be a problem in the ClientIdentitySchema model definition, that requires several properties that are missing. Below is a sample of the received json:

[
  {
    "id": ...
    "schema": ...
  },
  ..
]

Reproducing the bug

Use the .NET Client Api to call ListIdentitySchemasAsync().

Relevant log output

No response

Relevant configuration

No response

Version

0.0.1-alpha.169

On which operating system are you observing this issue?

Windows

In which environment are you deploying?

Docker Compose

Additional Context

No response

Benehiko commented 2 years ago

Hi @roboptics

Thank you for the report, we'll look into this. Might be a problem with the OpenAPI code generator :sweat_smile:

aeneasr commented 2 years ago

@Benehiko I quickly checked our OpenAPI specification (backoffice/backoffice/spec/api.json) and this method does not exist in there. It does however exist in Ory Kratos' API specification. There, it is expected to return identitySchema and this clashes with a definition in the OpenAPI backoffice specification of the same name.

To resolve this, the backoffice should use a distinct name from the Ory Kratos specification for this model. For example managedIdentitySchema or something like that.

roboptics commented 2 years ago

Hi,

We migrated this week to version 0.2.0-alpha.4 and checked that some issues with the ClientIdentitySchema model remain, namely:

  1. This is the data that we now get from the API call ListIdentitySchemasAsync():
{
  "id": "GUID",
  "schema": "RAW-JSON" 
}

But this model enforces the following fields as mandatory (from source):

    [DataContract(Name = "identitySchema")]
    public class ClientIdentitySchema : IEquatable<ClientIdentitySchema>, IValidatableObject
    {
        [DataMember(Name = "blob_name", IsRequired = true, EmitDefaultValue = false)]
        public string BlobName { get; set; }

        [DataMember(Name = "blob_url", IsRequired = true, EmitDefaultValue = false)]
        public string BlobUrl { get; set; }

        [DataMember(Name = "created_at", IsRequired = true, EmitDefaultValue = false)]
        public DateTime CreatedAt { get; private set; }

        [DataMember(Name = "id", IsRequired = true, EmitDefaultValue = false)]
        public string Id { get; set; }

        [DataMember(Name = "name", IsRequired = true, EmitDefaultValue = false)]
        public string Name { get; set; }

        [DataMember(Name = "updated_at", IsRequired = true, EmitDefaultValue = false)]
        public DateTime UpdatedAt { get; private set; }
}

Which causes Json deserialization to fail for this model.

  1. Previously we were parsing the ClientIdentitySchema schema field contents to get the traits required for each schema. This field is now passed as raw base64 encoded string. Is this to discorage parsing it's contents? If so, where can we get the traits required by the identity schema selected to create a new identity via admin API?

  2. Finally, the ClientGenericError is also now misbehaving. The details fiels is passed as below:

{
        ...
        details: { "KEY", "VALUE" }
        ...
}

But the corresponding model is actually expecting a list of these:

    [DataContract(Name = "genericError")]
    public class ClientGenericError : IEquatable<ClientGenericError>, IValidatableObject
    {
        ...
        [DataMember(Name = "details", EmitDefaultValue = false)]
        public List<Dictionary<string, object>> Details { get; set; }
        ...
    }

Which again causes Json deserialization to fail for this model.