urls.primaryName is not correctly switching the selected definition in the Swagger UI in Swashbuckle.AspNetCore 6.4.0, but was working correctly in Swashbuckle.AspNetCore 6.2.3

[brainmeyers]

I have included a sample solution and detailed instructions on this github repository.

• https://github.com/brainmeyers/swashbucklemultimodulesample

You can see from the image in that sample, the urls.primaryName does not match the definition being shown:

If this is a Swagger UI specific issue then do let me know and I will log this in the Swagger UI repository. But it does seem to be related these specific versions of Swashbucke.AspNetCore versions.

[brainmeyers]

I have confirmed that this behavior works correctly in Swashbuckle.AspNetCore version:

• 6.2.3

But does not work correctly in these versions:

• 6.3.0
• 6.3.1
• 6.4.0

[Benexx]

I also do have the same issue. Also EnableDeepLinking() did not solve the issue.

app.UseSwaggerUI(c =>
{
    ...
    c.EnableDeepLinking();
});

For now downgraded to version 6.2.3.

[DavidZidar]

This issue seems to be because the configObject that Swagger UI reads is missing the property urls.primaryName. If I set a breakpoint after the config is JSON parsed and execute the following code configObject["urls.primaryName"] = "v2"; then I correctly end up in my document named "v2". Maybe Swagger UI used to read this property from the query string?

This can either be solved by introducing a new property in ConfigObject on server the side with a [JsonPropertyName("urls.primaryName"] or maybe with a bit of JavaScript to read the query string and insert the right value like into configObject at runtime.

Here are the docs:
https://github.com/swagger-api/swagger-ui/blob/118ea1329c0948f4f7d5aa6a7776a11c84df5b13/docs/usage/configuration.md#core

[domaindrivendev]

Technically, this is an upstream issue with swagger-ui because it used to honor that value in the query string but now does not. See swagger-api/swagger-ui#7835

You can apply the solution suggested there with the following line in your Swashbuckle configuration:

app.UseSwaggerUI(c =>
{
    ...
    c.ConfigObject.AdditionalItems["queryConfigEnabled"] = true
}

[DavidZidar]

@domaindrivendev Thanks for the workaround, I'll try it, but should that be on by default? Otherwise you are going to get more issues from people wondering why this isn't working.

[arturomonge]

@domaindrivendev This workaround opens an attack vector. See GHSA-qrmm-w75w-3wpx. The issue seems to have been fixed in v4.14.1 of Swagger-UI through 8168. The latest version of Swashbuckle is using v4.14.0, so upgrading the Swagger-UI version in Swashbuckle would fix this issue.