search

dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
3.37k stars 348 forks source link

Github codespaces - Dashboard resource urls has incorrect urls not specifying the github code space prefix or port forwarded ports #3441

Open kvenkatrajan opened 2 months ago

kvenkatrajan commented 2 months ago

The dashbaord launched from github codespaces displays the urls as it would locally without the github codespace prefix.

image

Clicking on this would result in 404/invalid url

Modify the url to include the prefix For example of github code space prefix : https://turbo-space-tribble-xv6w5xxj76h6g64.github.dev/ . And here is an example of a port forwarded version of url is : https://turbo-space-tribble-xv6w5xxj76h6g64-5169.app.github.dev/counter

davidfowl commented 2 months ago

I'll take this one.

kvenkatrajan commented 3 weeks ago

@davidfowl - is this something you would like to be assigned to - or move it over to @mitchdenny and @tmeschter for analysis/implementation.

davidfowl commented 3 weeks ago

Moving to @tmeschter sounds good. I think we just need to know how to map the dev tunnels back to resources.

cc @karolz-ms for his thoughts.

mitchdenny commented 3 weeks ago

I see tunnels as being layered on top of the base networking implementation we have today. So certain endpoints will also have a tunnel address. You wouldn't want services that are dependent on containers to have to route through the tunnel in normal circumstances.

For mobile scenarios I also think it would be great if you could bring up a link and show it as a QR code so you can hold you phone up to it and get pre-authenticated access into the tunnel.

karolz-ms commented 2 weeks ago

I assume in this case everything runs inside the codespace and all network traffic initiated by the application stays within the codespace local network. It is just that certain URLs (dashboard, frontend app and the like) are tunnelled to the dev host so that they can interact with them.

If my understanding is correct, I would think the dashboard should be made "tunnel-aware". When the dashboard is launched, there is an invocation parameter/environment variable that tells the dashboard the following: when you display an URL that the user should be able to CLICK (i.e. open with their browser), replace the (local host+port) part of the URL with the (tunnel host+tunnelled port). This also requires access to the "tunelled port configuration", which has to be passed to the dashboard or somehow retrieved by the dashboard from within the codespace. I am sure there is prior art for that already.