Fix: handle 302 redirects to redirect_uri in WebView2 authorization flow

[yfridelance]

Summary

When the redirect_uri is reached through an HTTP 302 redirect, the WebView2
SourceChanged event does not fire. As a result, the authorization window
never closes and the authorization code (or error) cannot be captured,
leaving the flow hanging.

Changes

• Invoke-WebView2.ps1: Add a NavigationStarting event handler that
  matches the close-condition regex. When the redirect_uri is hit, it cancels
  the navigation, stores the URL in Form.Tag and closes the form. The captured
  URL is then used as the response when present (falling back to $web.Source
  otherwise).
• Invoke-OAuth2AuthorizationEndpoint.ps1: Escape and anchor the
  redirect_uri in UrlCloseConditionRegex using [regex]::Escape(), so that
  regex metacharacters in the URI (e.g. ?, .) no longer break the match.
• Apply consistent code formatting (whitespace only) across both files.

Testing

Tested authorization code flow against private IdP with a redirect_uri
that returns a 302; window now closes and the code is captured correctly.

[alflokken]

Thanks for this, @yfridelance. Nice catch.

I reworked it a bit before landing it on fix/auth-window-hang

• Kept your NavigationStarting fallback, but limited it to responses with code= or error= in the query string. Implicit and hybrid #fragment responses don't include those parameters, so they still close through SourceChanged without losing the token.
• Kept wrapping of redirect_uri in [regex]::Escape(), however I left the match unanchored instead of requiring the URL to start with redirect_uri. Some providers return code= or error= on URLs that are not strict prefixes of the redirect URI. That behaviour is an intentional trade-off, although it wasn't previously documented. Issues Possible Bug with webview closing on idp redirecting to different SSO #5 and Invoke-OAuth2AuthorizationEndpoint - URL close condition regex bugged #8 touch on related behaviour but not this specific case.
• While I was in there, I moved the pattern into a helper function (Get-UrlCloseConditionRegex) and used claude to add some tests for each close condition

One heads-up, the dev branch this targets had gone stale, and I'm still finding my feet with branching, so I did my best to keep the fix clean and credit you as co-author, so apologies if anything came across differently than intended.

Before I merge and cut 1.4.1, could you confirm that fix/auth-window-hang resolves the hang on your setup? I've attached a build of the module from that branch if that is more convenient for you.

I'll leave this open until you've had a chance to test it. No rush.