Containerized Kratos accessing public URL

[jertel]

The issue I'm seeing involves Kratos, running in a container, attempting to access schemas via the public URL. Persister.injectTraitsSchemaURL() concatenates the schema ID (Ex: default) to the configured public self-service URL (specified in the configuration file). Then in error scenarios, such as attempting to change your password to an invalid value, the settings flow's error.go handler attempts to sort the traits for an improved UI experience. But that sorting also requires loading the schema, and it does so via LoadURL(), from within GetKeysInOrder() (in schema.go). Since the Kratos process now attempts to access this public self service URL with the concatenated schema ID, it can run into problems if the container does not have the right CAs or DNS or network routes defined to access the public URL (for example when it's running behind a reverse proxy).

Instead of the Kratos process itself trying to lookup schemas via the concatenated public URL, would it be better to have it load the URLs listed in the configuration, under the identity block?

identity:
  default_schema_url: file:///kratos-conf/schema.json

[aeneasr]

@zepatrik could you take a look into this? Apparently it’s an issue because it’s already the third question around this :)

[zepatrik]

I think it would make sense to download all schemas on build and include them using embed. This will also make sure that the code and the schemas actually match up. If we ever update the online schemas but not the code, we will have a broken state. There seems to be at least one JSON Schema bundling tool: https://apitools.dev/json-schema-ref-parser/docs/ref-parser.html#bundlepath-options-callback

Bundles all referenced files/URLs into a single schema that only has internal $ref pointers. This lets you split-up your schema however you want while you’re building it, but easily combine all those files together when it’s time to package or distribute the schema to other people. The resulting schema size will be small, since it will still contain internal JSON references rather than being fully dereferenced.

[aeneasr]

The issue is about the Identity Schema, not the config schema. We can’t include those during build time! The problem appears to be one where the generated identity schema URL is not working but required by internals. Since you worked on this feature I thought it would make sense for you to fix it :)

[zepatrik]

Oh I see, don't know how I could misunderstand it that badly 😂
It does definitely make sense to load the schemas from the config URLs instead of the network outward facing ones.