Validate full hostname in `/data-plane-auth-req` page

[psFried]

The /data-plane-auth-req page will request and authorization token and then redirect the user to a location that was provided in the orig_url. Because that data-plane auth token will be sent to whatever hostname is in orig_url, we need to ensure that it's the proper hostname for the task that the user is trying to access. Consider the scenario where some naughty person crafts a malicious link like https://dashboard.estuary.dev/data-plane-auth-req?prefix=your/task&orig_url={https://naughty-domain/steal/your/token}. Without any sort of validation in the UI, we could end up requesting a token that gives access to your/task and sending that to naughty-domain.

Currently, the UI does validate that the hostname provided in orig_url is a subdomain of the gateway_url that's configured for the given task. This is an effective mitigation of the scenario described above. But this only works because we don't yet allow running untrusted images in our data planes. Once we do allow running untrusted images in our data-plane, it would become possible for said naughty person to simply use naughty-task.dataplane.estuary-data.dev instead of naughty-domain and be able to steal data-plane auth tokens.

So to make this watertight, we need to validate that the hostname in orig_url matches exactly the hostname of the task that the user is trying to access. This validation may be slightly more complicated that you'd think, though, because shards of a given task may be accessed through multiple different hostnames. Here's a rough sketch of what I'm thinking this would look like:

• List the shards for the task in the DataPlaneAuthReq page
• Use the shard listing to derive a complete set of endpoints for the task, including any shard-specific endpoints. Note that would differ from the current behavior of useShardDetail_getTaskEndpoints, which does not return any shard-specific endpoints.
• Validate that the hostname of orig_url is included in that set

[kiahna-tucker]

At the time this issue was picked up, shard-specific endpoints are listed on the Overview tab of the Details page. Consequently, the changes identified in the first and second bullets have been satisfied. To ensure that the orig_url hostname matches that of the task shard, the live_specs_ext view will be queried to surface the "hostname" shard label (i.e., 'estuary.dev/hostname') listed in the built_spec and its value used to verify the orig_url hostname. Querying the live_specs_ext view allows the client to avoid additional authorization and a round-trip to the data-plane.