Safari users shouldn't need to always copy/paste the authcode on web-based login flows

Is your feature request related to a problem? Please describe.

There is an intentional behavior in Safari which is not spec-compliant which will always prevent an https (TLS) web site from making fetch calls to an http (non-TLS) localhost site (see the heated debate in https://bugs.webkit.org/show_bug.cgi?id=171934). So Safari always immediately fails our fetch request and our UI catches the failure and shows the authcode. Therefore, all Safari users always have to manually copy/paste the authcode to log in. This is regardless of cors or non-cors mode.

~20% of internet users use Safari, so this might be worth improving.

Describe the solution you'd like

The Concourse fly CLI’s similar web page works around this. When the automatic localhost call fails, then they show a new button in the UI “send token to fly directly”, and that button has an “a” tag with an “href” of the http localhost callback url with the token as a query param. This is allowed because it is following an href and loading a whole new page. We could add a similar feature.

Here is a screenshot of that UI from Concourse:

Describe alternatives you've considered

Not sure if anything else is possible. Maybe Safari someday adds the same CORS support for localhost requests that Chrome added in v98. If that happened then maybe the problem would go away in Safari. They don't seem to have announced any such plan on the bug report linked above, so that may never happen.

Start from the web-based login flow where a failed localhost fetch causes the authcode to be shown, and trace the Safari failure handling. Compare the proposed fallback with the Concourse flow: done means offering a button whose link sends the token to the localhost callback URL, while preserving the existing manual copy/paste path.