fix(plugin): allow Topbar plugin to read url param on load

[chadknight-wf]

Description

The Topbar plugin manipulates the querystring param, adding urls.primaryName to track the selected spec. If you have queryConfigEnabled set to true, you can use this to link directly to a specific spec (e.g. my-swagger-ui.com/?urls.primaryName=MyChosenSpec), and the plugin will load that named spec from your config.

If you have queryConfigEnabled set to false - which seems like the recommended option to prevent some security issues (GHSA-qrmm-w75w-3wpx) - this functionality no longer works.

In this PR, I update componentDidMount to check the querystring directly, with a fallback to the config. I believe this is safe since the param is the name of a configured URL, not an arbitrary URL. And this allows users who don't enable query config to still benefit from the direct linking feature.

Motivation and Context

Fixes #8039
Fixes #7835

How Has This Been Tested?

I built this change locally, referenced the built files in a local project, and noted that the intended API spec is loaded.

I didn't find any existing unit tests for the Topbar or integration tests for this ?urls.primaryName behavior.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[tim-lai]

@chadknight-wf Thanks for the PR! The change seems innocuous enough to me. Thinking about how to quickly implement a for test this fix, perhaps you could setup a Cypress test (test/e2e-cypress/tests/features/plugins/topbar/<testName>) where in cy.visit(), you intercept the ?urls.primaryName to point to whatever the local path is. Then switch and assert among different url params.

[chadknight-wf]

Thanks @tim-lai! I've added a test setup that mirrors my use case pretty well, with a new index.html to interact with.

[tim-lai]

@chadknight-wf The test setup looks good. One last minor change requested... since the static page can be used generically, and it looks like the only difference is specifying urls instead of url, let's change the path to static/pages/multiple-urls/index.html

[tim-lai]

@chadknight-wf PR merged! Thanks for the contribution and iteration!

[chadknight-wf]

Thanks for the guidance!

[ChristianHudonDTI]

Thank you for this.
This will be helpful to us.