Running a frontend based on VueJS / TypeScript in Chrome and sending a GET-Request with an Authentication header set to a token. Thus, Chromse sends an OPTIONS-Request, retaining that the Authentication header is allowed, and then sends the GET-Request. I except that GET-Request to be forwarded the same way.
Instead of rerouting the Request to the backend service, Ocelot replies to the GET-Request with 307 Redirect and the browser then sends the raw request directly to the endpoint, not using the middleware.
Ocelot has injected an AuthenticationMiddleware that validates the token and adds custom headers for the backend service, giving it more detailed information which user is mapped to the token. To achieve this, we have tried two things:
1) Injecting with
var configuration = new OcelotPipelineConfiguration
{
AuthenticationMiddleware = async (context, next) =>
{
await AuthorizeAsync(context, next);
}
};
2) Adding a Global Handler:
services.AddOcelot(Configuration).AddDelegatingHandler<AuthHandler>(true);
In both solutions we add the header to the _DownstreamRequest_. The path is correctly mapped to the Downstream-Service. In both cases the DownStream-Service gets only half of the requests, the other half get Statuscode 307.
There is no additional configuration.
This only happens in the browser and not when using another tool like Postman, however I still suspect that has to happen somewhere when Ocelot sets the Statuscode for the Response.
I looked at the repository but was not able to find anything that gives me hint on to what I am doing wrong.
Hi
Just in case, this is still relevant to you (or somebody else).
I had the same problem. It was caused by the target micro-service where the .UseHttpsRedirection() was enabled. So the request ended up at the correct target service but was redirected there from http to https.
Cheers, Mike
Most helpful comment
Hi
Just in case, this is still relevant to you (or somebody else).
I had the same problem. It was caused by the target micro-service where the .UseHttpsRedirection() was enabled. So the request ended up at the correct target service but was redirected there from http to https.
Cheers, Mike