feat(oauth2-redirect): externalize inline script for CSP compliance

[davidanrod]

feat(oauth2-redirect): externalize inline script for CSP compliance

Description

Moves the inline JavaScript code from oauth2-redirect.html into a new external file oauth2-redirect.js. The HTML now loads the script via a <script src="…"> tag instead of embedding it directly avoiding CSP problems...

Motivation and Context

Some environments enforce strict Content Security Policies (CSP) that block inline scripts (most of them by security purposes). This change ensures that the OAuth2 redirect page works in such environments by complying with CSP restrictions.

1. Created dev-helpers/oauth2-redirect.js with the previous inline logic.
2. Updated dev-helpers/oauth2-redirect.html to reference the external JS file.

Impact???

1. No change in runtime behavior.
2. Improves compatibility in environments with CSP restrictions.
3. Keeps backward compatibility with existing OAuth2 redirect flow.

Note: From what I understand, the /dist folder "part of it only" is updated by the maintainers during the release process, and the contents of dev-helpers/* are copied there at that time. I’ve therefore only updated the source files under dev-helpers and not touched /dist. I believe this is the correct approach, but please correct me if I’ve misunderstood the release workflow :/.

How Has This Been Tested?

locally using webpack dev server "npm run dev"

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.