Dynamically adding headers

[dcaton]

I'm using the reverse proxy to add Azure ADB2C authorization to a legacy web site that is too old and fragile to add native support for OAuth. A proof of concept test works well; authorization happens in the proxy prior to any requests being forwarded to the proxied site.

The problem I face now is telling the proxied site who the authenticated user is. Seems to me that adding some headers to the forwarded request is the most straightforward way. However, this requires the ability to add headers dynamically. I see that's on the 1.0 backlog as issue #60 . I really need to get this working ASAP, even if I have to hack something up for the time being and change the code later, once it's a supported feature.

Any advice on how I should approach this? Is there any undocumented extensibility point I could make use of? I have not yet downloaded the source and tried to compile it, but that's my next step today. I don't see any pull requests for this feature. I certainly would be willing to contribute to the project if anything I come up with is deemed useful.

Thanks in advance for any advice or guidance.

[Tratcher]

See #375 for some related suggestions.

[dcaton]

I've also tried this:

    "Transforms": [
      {
        "RequestHeader": "foo",
        "Append": "foobar"
      }
    ]

and it has no effect either. Am I doing something stupid? I was on preview 3 but just changed to preview 4.20424.2. Made no difference.

[Tratcher]

That should have worked... are the other request headers are forwarded?

I prefer the set indexer Headers["foo"] = "bar"'; to avoid conflicts, but it shouldn't matter in your case.

[dcaton]

Perhaps I am doing something stupid. If I look at the proxied page in the developer console (f12) in the browser, should I see the request headers I added? Or are those the original headers sent from the browser's request, not the headers that are sent between the proxy and the proxied site?

[dcaton]

I suppose I need to attach the remote debugger to the proxied site and examine the incoming headers that way.

[Tratcher]

I suppose I need to attach the remote debugger to the proxied site and examine the incoming headers that way.

Right, modified request headers won't show up on the client. That's why I use code like this in the destination server to debug:

reverse-proxy/samples/SampleServer/Controllers/HttpController.cs

Lines 31 to 50 in 8b9fa3d

	[HttpGet, HttpPost]
	[Route("/api/dump")]
	[Route("/{**catchall}", Order = int.MaxValue)] // Make this the default route if nothing matches
	public async Task<IActionResult> Dump()
	{
	var result = new {
	Request.Protocol,
	Request.Method,
	Request.Scheme,
	Host = Request.Host.Value,
	PathBase = Request.PathBase.Value,
	Path = Request.Path.Value,
	Query = Request.QueryString.Value,
	Headers = Request.Headers.ToDictionary(kvp => kvp.Key, kvp => kvp.Value.ToArray()),
	Time = DateTimeOffset.UtcNow,
	Body = await new StreamReader(Request.Body).ReadToEndAsync(),
	};
	return Ok(result);
	}

[dcaton]

Thanks very much. The example in #375 works perfectly to add headers dynamically. Not sure what #60 would offer beyond this.

This whole reverse proxy thing fills a huge need we have, and the fact that it will be a supported thing in .net is a big plus over rolling my own, or using someone else's code. Many thanks to all of you working on this project.

[samsp-msft]

Thanks very much. The example in #375 works perfectly to add headers dynamically. Not sure what #60 would offer beyond this.

#60 may not offer much beyond this - its a capability we know we need, and have yet to spend time on the design - it may end up being exactly what we have in #375, but we need to make sure that there is a clean & performant way to extend the pipeline and add/remove and modify headers for the request and responses.

[Tratcher]

#60 would let you do this as per route rules rather than writing a custom middleware that ran on every request. The middleware is adequate for many scenarios, but it could be cleaner.