Hosting MVC6 application behind the gateway and url re-write
Closed this issue · 7 comments
I have a gateway which is running on port 8000 like the example which directs has the following map configuration
// OpsConsole
//
var opsConsoleOptions = new GatewayOptions()
{
ServiceUri = new Uri("fabric:/MKopa.M2M.OpsConsole.App/MKopa.M2M.OpsConsole.Service", UriKind.Absolute),
OperationRetrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(2), TimeSpan.FromSeconds(2), 30)
};
app.Map("/OpsConsole",
subApp =>
{
subApp.RunGateway(opsConsoleOptions);
}
);
app.MapWhen(
context =>
{
StringValues serviceUri;
return context.Request.Headers.TryGetValue("SF-ServiceUri", out serviceUri) &&
serviceUri.Count == 1 &&
serviceUri[0] == "fabric:/MKopa.M2M.OpsConsole.App/MKopa.M2M.OpsConsole.Service";
},
subApp =>
{
subApp.RunGateway(opsConsoleOptions);
}
);
After deploying the application if I deploy to the local cluster I can browse to http://localhost:8000/OpsConsole and I'm redirected to the site but all of the links are broken, for example if I go to the login link I get an error 404 http://localhost:8000/sf-cf6fbac7b32c497db1bb5bfbd37bed77/Account/Login
, I've checked the headers and I'm missing the SF-ServiceUri header value.
Is it my code's responsibility to add this header of have a mis-configured something ?
I've realized that the header functionality is not intended for use in this use case.
I'm thinking I might need to develop some kind of middle ware which would accept the gateway url and re-write the html replacing the SF instance url with the gateway url.
This was resolved with the help (and code) from @rmja
Glad to see the issue got resolved. Leveraging the X-Forward- headers is a great idea! @rmja @johnkattenhorn
I made a fix inside the Hosting package and Gateway package to flow path base from gateway to backend service, which basically is equivalent to the X-Forwarded-PathBase implementation by @rmja. However, I used X-ServiceFabric-PathBase instead of X-Forwarded-PathBase/X-Forwarded-Path as the header name. The reason is that I searched online and found that X-Forwarded-PathBase/X-Forwarded-Path is not as widely adopted as X-Forwarded-For, X-Forwarded-By, etc, and this is a Service Fabric specific gateway implementation, I decided to use a custom header starting with X-ServiceFabric for now.
Ok, sounds good, I think this has been asked before but when can we have some NuGet packages ;-) If I got one of the team to do something with packages this week could you accept a PR ?
What change do you expect to make with packaging?
We likely create NuGet packages post ASP.NET Core 1.0 RTW. Before that, please feel free to grab the source code and make your own NuGet packages if needed.