Allow specifying an address hostname for project/service binding

[tdhatcher]

@davidfowl @mitchdenny This issue I'm trying to solve (or feature enhancement) is related to not being able to provide a specific hostname/address alias to resource.

While I'm not trying to externally access anything orchestrated locally I think there maybe some fundamental overlap with discussions here: #2887 and #3146 and pull request: #3492

I have a couple use cases:

1. I have several UI projects that rely on OIDC and specific domains are whitelisted in Okta for redirects. Of course I can lobby to statically add a whitelist of localhost:port but that requires another team that manages that infrastructure to get involved.
2. We have multi-tenancy logic that utilizes the request's host vanity domain to serve as a parameter to alter context and behavior at runtime. So with the same hosted instance a request with .vanity-A.com would do something slightly different than .vanity-B.com

So it would be awesome to be able supply additional address bindings specifically for local hosting that ALSO display on the dashboard. (This was something I recall doing with Tye)

An existing tye.yaml

- name: ui
  project: ../src/App.UI/App.UI.csproj
  replicas: 1
  bindings:
  - name: http
    host: localhost
    protocol: http
  - name: https
    host: localhost
    protocol: https
  - name: local
    host: my.vanity-a.com
    protocol: https
    port: 1337
  env:
  - ASPNETCORE_ENVIRONMENT=Development

A "kinda" workaround

I've been adapting an existing distributed application into the Aspire model. My goal has been to do this incrementally without being invasive or making modifications to the existing projects to prevent any refactor disruptions or coordination. I have been successful enough so far, so kudos on baking in that flexibility from the start!

The workaround I have found like below so far appears to allow a workable path but not ideal of course from the dashboard or verbosity.

var ui = builder.AddProject<Projects.MyAccount_UI>("ui", null)
    .WithReference(api)
    .WithHttpsEndpoint(port: 7098, isProxied: false)
    .WithEnvironment("ASPNETCORE_ENVIRONMENT", "Development")
    // Need to specify address. Environment customization allows us to provide a hostname other
    // than localhost for Okta whitelist and general compatibility with current codebase state.
    .WithEnvironment(async context =>
    {
        if (context.ExecutionContext.IsRunMode)
        {
            var aspnetUrls = (await (context.EnvironmentVariables["ASPNETCORE_URLS"] as ReferenceExpression)!.GetValueAsync(context.CancellationToken));
            context.EnvironmentVariables["ASPNETCORE_URLS"] = aspnetUrls!.Replace("localhost", "my.vanity-a.com");
        }
    })
    // This does cause another addition endpoint to render under the resource in the dashboard but only localhost, no hostname address parameter
    .WithAnnotation(new EndpointAnnotation(protocol: ProtocolType.Tcp, "https", name: "my-vanity-b", port: 18001, isExternal: true, isProxied: false));

[mitchdenny]

What are you doing for certificates in this scenario? Are you manually installing a self-signed cert for my.vanity-a.com? Or are you just ignoring the cert warnings? Are you manually modifying your hosts file to make this work as well?

[tdhatcher]

@mitchdenny I'd have to say all of the above. Which isn't too much overhead compared to needing clone repos, get secrets, etc. That initial ceremony but could mostly be scripted.

Manually doing the following.

• [x] Modifying the host file
• [x] Generate a self-signed certificate and install locally
• [x] Depending on the project, might just ignore the cert warning locally

[mitchdenny]

At this point we probably aren't going to try to tackle this with Aspire but I'll leave this on the backlog to collect more feedback. I can see the utility of this but there are some inherent security risks of doing this.

[tdhatcher]

@mitchdenny I'm not completely understanding if the security risk part is really relevant.

I think at this point the main thing I'm missing is just having the flexibility to insert an additional "aliased" endpoint link to render on the dashboard for the resource (and the verbosity to achieve that) to steer others who run the Aspire AppHost as configured. Otherwise I already have the behavior and flow working as I need it to. It's just that I have to communicate this in another way to others -- it's not intuitive to other devs off the shelf that it can be accessed in another way.

I did have the hostname and port I'm binding to whitelisted in the external Okta tool (or whatever configurable blackbox that is outside of the purview of Aspire)

[DamianEdwards]

Related to #1116

[tdhatcher]

@DamianEdwards Thanks. Sorry I tried to find if there were any existing issues that were similar before posting. I'd say that #1116 is definitely on the same wavelength more than any other previous issues.

In my case 1) I would want the same port number (and specified) to serve for all hostnames. And 2) for it to be recognized on the Dashboard so a person would easily see "here are all the possible tenants/brands served for this resource". My application won't even function if I try to access it on localhost or 127.0.0.1 because it essentially will not map to a valid configuration state.

From some of what I have gathered service discovery seems to be something a bit more complex to solve for in general. For what it is worth, since I'm retrofitting existing applications into Aspire I'm basically crafting the environment variable for the service url configuration myself so I'm not really depedent on that at the moment. However my hope is to gradually migrate to adopt the Aspire conventions at some later time -- to remove most of the environment variable overrides.

I could live with this syntax of accessing some building blocks like this as it is more concise over what I have working now. I'll continue to experiement to see if I can come up with a cleaner workaround in the meantime.

AppHost.cs

var myUI = builder.AddProject<Projects.MyUI>("myUI")
    // 7085 port is required
    .WithEndpoint(port: 7085, scheme: "https", name: "vanitya", hostName: "my.vanity-a.com")
    .WithEndpoint(port: 7085, scheme: "https", name: "vanityb", hostName: "my.vanity-b.com")
    .WithEndpoint(port: 7085, scheme: "https", name: "vanityc", hostName: "my.vanity-c.com")

    // Maybe another overload
    .WithEndpoint(port: 7085, scheme: "https", hosts: [
        new() {Name = "vanitya", hostName: "my.vanity-a.com"},
        new() {Name = "vanityb", hostName: "my.vanity-b.com"},
        new() {Name = "vanityc", hostName: "my.vanity-c.com"},
    ]);
;

var myServiceApi = builder.AddProject<Projects.MyServiceApi>("myServiceApi")
    // Non-standard service url injection not following Aspire conventions
    .WithEnvironment("Brands__A__Url", myUI.GetEndpoint("vanitya").Url)
    .WithEnvironment("Brands__A__Url", "https://my.vanitya.com" + myUI.GetEndpoint("https").Port) // an less consise alternative
    .WithEnvironment("Brands__B__Url", myUI.GetEndpoint("vanitya").Url)
    .WithEnvironment("Brands__C__Url", myUI.GetEndpoint("vanitya").Url);

HttpClient Service Discovery

services__myui__vanitya__0
services__myui__vanityb__0
services__myui__vanityc__0

https+http://myui_vanitya/user
https+http://myui_vanityb/user
https+http://myui_vanityc/user

https+http://myui:vanitya/user
https+http://myui:vanityb/user
https+http://myui:vanityc/user

// This would look a bit weird (or astonishing).
vanitya://myui/user
vanityb://myui/user
vanityc://myui/user

MyUI.csproj launchSettings.json

{
    "profiles": {
        "http": {
            "commandName": "Project",
            "dotnetRunMessages": true,
            "launchBrowser": true,
            "applicationUrl": "http://*:{port doesn't matter to me}",
            "environmentVariables": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            }
        },
    }
}

[matt1munich]

+1 & subscribed. I am also in the same boat.

[mitchdenny]

I think that this is a super specific scenario so we'd be wanting to collect a lot more evidence around the need before we race off to implementation.

Supporting multi-tenant scenarios is challenging because there are so many different approaches and layers in which tenancy comes into play.

[mitchdenny]

One idle thought about this. My inclination would be to define a reverse proxy as a resource within the app model which is configured to respond on all the domains you want and then pass the host header through to the ASP.NET project. This is more inline with how this kind of tenanting mechanism works in production anyway.

Then you could just have a single wildcard host entry for that endpoint. You'd probably need to handle the cert side of things yourself since we can only issue the standard ASP.NET Core dev cert at this point in time.

[tdhatcher]

@mitchdenny I believe I understand what you are conveying here. It does feel like a heavier handed approach which is additional complexity just for Aspire purposes but not required with the existing application when launched locally with launchProfile with normal Visual Studio or even IIS. The equivalent was very easy to achieve with Tye, any binding added would just render the scheme and hostname/port on the dashboard.

If I'm not mistaken the reverse proxy appeoach still wouldn't help to address the primary "user friendliness" issue of allowing an uninitiated developer to easily discover the all the available hosted vanity urls by strictly relying on what is presented by the dashboard alone. How would the developer know which urls the reverse proxy resource supports?

The current missing vanity url details of a resource would have to be part of some buried and lesser obvious means such as exploring internal documentation or app configuration of the reverse proxy or the multi-tenant app as part of an onboarding process which is what I'm wanting to avoid (but currently appears to be my only option). Ideally, I would like the experience for other new devs on the team to be turnkey without having to dig into docs.

My actual use cases are driven by OIDC requirements and other multi-tenant/branded app behaviors that are already deployed in a production environment without the need for a reverse proxy. On here I've been relying on communicating similat usage scenarios that are contrived for simplification purposes but hopefully still accurate enough to communicate the desire.

Onwards to a better workaround

Assuming no further work is done to make an easier or more convenient interface, at this point I'd say a workaround I'd really be interested in is how to influence what is rendered on the dashboard for all the endpoint links associated with a resource. That would do the trick. I'm just needing to inject a couple vanity urls to render for the resource.

I was able to sort of achieve a new entry using .WithAnnotation(new EndpointAnnotation(...)) however I am still in the same boat as changing localhost does not appear to be a parameter. Maybe I can extend that annotation and override it? I haven't dug deep enough there as to how the dashboard constructs the endpoint urls it renders.

But because I'm already using some of the hackiness around overriding context.EnvironmentVariables["ASPNETCORE_URLS"] that at least does most of the heavy lifting to get the app to listen on host/port other than localhost. So if a developer is aware of the valid hosted vanity urls, they can still interact with the app in that context through thr browser or postman.

I can live with this little hackiness and extra configuration verbosity in the app host if it makes other devs on the project's life much easier. At least I'd have recipe to apply that makes the resource bind correctly and also render all its appropriate links on the dashboard.

[clarkezone]

+1 to the issue. This is currently blocking my environment.

[mitchdenny]

@tdhatcher take a look at the CustomResource playground:

https://github.com/dotnet/aspire/blob/2249f7d4d114784ed4f117a60b1b2963d971bd92/playground/CustomResources/CustomResources.AppHost/TestResource.cs#L49

It uses ResourceNotificationService to add update properties (in this case) on a resource. But you can also do things like add URLs. This is how the Azure provisioning logic works to add links to the deployment URLs in the Azure portal ... example:

https://github.com/dotnet/aspire/blob/2249f7d4d114784ed4f117a60b1b2963d971bd92/src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs#L97

[tdhatcher]

It uses ResourceNotificationService to add update properties (in this case) on a resource. But you can also do things like add URLs.

Thanks @mitchdenny I will dig further into this to see what I can do with it. On vacation at the moment so not a laptop in sight for a couple weeks 😀.

[tdhatcher]

Didn't mean to close this yet. Mobile!

[AndrewBabbitt97]

This would also be useful for unix sockets, which we currently have no way of specifying the file path to the socket for an endpoint as well.

[clarkezone]

@glennc as I was talking to him about this recently

[clarkezone]

Didn't mean to close this yet. Mobile!

Are you planning to reopen?

[hades200082]

Another thing this could help with is running out of space in localhost cookies with Aspire.

I now can't access Redis Commander, PG Admin, etc. because they throw HTTP 431 errors. Clearing cookies doesn't help because Aspire just puts them all back again on next run.

Being able to use different hostnames for services and projects would solve this issue. This is similar to feature request #5508 I opened earlier.

[mitchdenny]

@hades200082 can you create a GitHub repo with a repro of the cookie issue you are seeing. This is the first I've seen of it. If you can reproduce it, then can you open a specific issue for that.