Disable the validation badge for those who do not want it

[waterkip]

When running swaggerui on Docker with a hostname, which is not
localhost, one gets a badge that says that the validation URI cannot be
accessed. Which is correct, because the URI is most likely to be on the
localhost. The check is done when the instance itself runs on 127.0.0.1
or localhost, but it ignores the VALIDATION_URI settings. The
documentation tells us when the VALIDATION_URI is set to null the
validation isn't done. This isn't true, the code in
src/core/components/online-validator-badge.jsx sets a default
validatorUrl when this is undefined.

This changeset changes this, to not display the validation badge if the
validation URI is 127.0.0.1, localhost, none or empty.

There could also be another option, which would be to introduce a new
configuration parameter: validationEnabled, which would tell is that
we need validation. This would eliminate the need to check if the host
is on localhost and would allow even more fine-grained control over when
and where the validation can be done. I've chosen not to go that route
because I'm unfamiliar with the code base and this seemed to be the
smallest change to accomplish my needs for a developing OpenAPI specs
with Docker without seeing a validation error badge.

Signed-off-by: Wesley Schwengle [email protected]

How Has This Been Tested?

I've tested this with Docker-compose and setting the environment var VALIDATOR_URL=none.

Before my changes it looked like this (I have a crappy internet connection atm, so the badge isn't shown correctly, but you get the gist:

After my changes:

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]

@waterkip Merged! Thanks for the contribution!