Remove scheme + authority from login redirect URIs

[iliana]

Hey, wanna see something weird?

$ curl -i https://oxide.internal/device/verify?user_code=skdjf
HTTP/2 302 
location: /spoof_login?state=https%3A%2F%2Foxide.internal%2Fdevice%2Fverify%3Fuser_code%3Dskdjf
x-request-id: 7c4c6e68-0df0-47dc-8da0-c368dbb23ec6
date: Fri, 19 Aug 2022 17:35:58 GMT

$ curl --no-alpn -i https://oxide.internal/device/verify?user_code=skdjf
HTTP/1.1 302 Found
location: /spoof_login?state=%2Fdevice%2Fverify%3Fuser_code%3Dskdjf
x-request-id: ff2e190c-aeac-4c95-ae1b-6ae46c257431
content-length: 0
date: Fri, 19 Aug 2022 17:37:02 GMT

Earlier a bunch of us on a call determined that making a request that gets redirected to the login page via HTTP/2 (negotiated as part of TLS) results in the state= parameter having the full URL. For reasons we understand less, this causes the console to redirect back to https://oxide.internal/spoof_login/https://oxide.internal/device/verify?user_code=sdkjf, which doesn't work. This made using oxide auth login via spoof login with the CLI not work unless you realized what was going on and just fixed the URL yourself.

@david-crespo found what's going on in our HTTP stack: hyperium/hyper#1612 (comment)

Ensuring the URL we set in the state= parameter is only the path + query fixes this issue...

$ curl --no-alpn -i https://oxide.internal/device/verify?user_code=skdjf
HTTP/1.1 302 Found
location: /spoof_login?state=%2Fdevice%2Fverify%3Fuser_code%3Dskdjf
x-request-id: c3d313ef-06fc-4367-8995-284c7ff6e1fa
content-length: 0
date: Fri, 19 Aug 2022 19:05:11 GMT

$ curl -i https://oxide.internal/device/verify?user_code=skdjf
HTTP/2 302 
location: /spoof_login?state=%2Fdevice%2Fverify%3Fuser_code%3Dskdjf
x-request-id: a6d285c0-bb1c-46e3-a4a7-ab3c288f0eb5
date: Fri, 19 Aug 2022 19:05:13 GMT

... and makes the oxide auth login flow work properly over HTTPS.