英文:
Asp.netcore behind reverse proxy trigging 307 redirects
问题
I'm working on deploying an ASP.NETCORE web API in a docker container. The application is accessed via a reverse proxy which provides the SSL Layer, and routes the calls from an internet facing IP, to a machine that cannot be accessed from the web.
i.e.
Domain -> ReverseProxy -> ASPNetCoreWebApi
The proxy is up and running here's the nginx.conf file for those who want to see all the details.
I've changed the server names for obvious reasons. example.com is the internet facing domain, actualserver.local is behind the firewall.
worker_processes 1;
events { worker_connections 1024; }
http {
client_max_body_size 0;
sendfile on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
server {
listen 80 default_server;
server_name example.com;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
server_name example.com;
location /api {
proxy_pass http://actualserver.local:7066/api;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /swagger {
proxy_pass http://actualserver.local:7066/swagger;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location / {
proxy_pass http://actualserver.local:3000;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
}
}
The webapi application is deployed using docker-compose, here's the relevant part of the file.
api:
image: myprivateregistry.com/bcb.api:1.0.0.19
restart: always
ports:
- 7066:80
environment:
SQL_SERVER: localhost
MAIL_SERVER: 127.0.01
When I browse to https://example.com, I get the content from actualserver.local:3000 which is a react app, and that's working just fine.
When I browse to https://example.com/swagger/index.html I get swagger link from my web app, so this shows /swagger location above is working just fine, and it shows that the proxy is forwarding the requests directly to the ASP.netcore application.
However, when I try to make a rest call to https://example.com/api/Authentication/login instead of the call being processed and the response being sent back as the others are doing, the ASP.NETCORE application seems to be intercepting the call and responding with a http status 307, giving the location of https://actualserver.local:7066/api/Authentication/login
And of course the call fails.
Can anyone tell me how to stop the ASP.NETCore application from trying to redirect the call, and simply accept the request and handle it, just as when I'm running in debug mode and not using a proxy?
I've tried using swagger, postman and web browsers. to make requests to various requests in the application, all end up with a 307.
In my program.cs I've tried adding
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.KnownProxies.Add(IPAddress.Parse("1.2.3.4"));
});
var app = builder.Build();
// Configure the HTTP request pipeline.
app.UseForwardedHeaders();
and changing the ipAddress 1.2.3.4 with the IP of example.com, and with the IP of actualserver.local
it's had no effect
I've added
app.UseHttpLogging();
which doesn't seem to report anything into the docker logs.
Does anyone have any ideas on what I can do to get the request from the reverse proxy to the web api, to actually process, and not result in a 307 temporary redirect response?
英文:
I'm working on deploying an ASP.NETCORE web API in a docker container. The application is accessed via a reverse proxy which provides the SSL Layer, and routes the calls from an internet facing IP, to a machine that cannot be accessed from the web.
i.e.
Domain -> ReverseProxy -> ASPNetCoreWebApi
The proxy is up and running here's the nginx.conf file for those who want to see all the details.
I've changed the server names for obvious reasons. example.com is the internet facing domain, actualserver.local is behind the firewall.
worker_processes 1;
events { worker_connections 1024; }
http {
client_max_body_size 0;
sendfile on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
server {
listen 80 default_server;
server_name example.com;
# location /.well-known/acme-challenge/ {
# root /var/www/certbot;
# }
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
server_name example.com;
location /api {
proxy_pass http://actualserver.local:7066/api;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /swagger {
proxy_pass http://actualserver.local:7066/swagger;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location / {
proxy_pass http://actualserver.local:3000;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
}
}
The webapi application is deployed using docker-compose, here's the relevent part of the file.
api:
image: myprivateregistry.com/bcb.api:1.0.0.19
restart: always
ports:
- 7066:80
environment:
SQL_SERVER: localhost
MAIL_SERVER: 127.0.01
When I browse to https://example.com, I get the content from actualserver.local:3000 which is a react app, and that's working just fine.
When I browse to https://example.com/swagger/index.html I get swagger link from my web app, so this shows /swagger location above is working just fine, and it shows that the proxy is forwarding the requests directly to the ASP.netcore application.
However, when I try to make a rest call to https://example.com/api/Authentication/login instead of the call being processed and the response being sent back as the others are doing, the ASP.NETCORE application seems to be intercepting the call and responding with a http status 307, giving the location of https://actualserver.local:7066/api/Authentication/login
And of course the call fails.
Can anyone tell me how to stop the ASP.NETCore application from trying to redirect the call, and simply accept the request and handle it, just as when I'm running in debug mode and not using a proxy?
I've tried using swagger, postman and web browsers. to make requests to various requests in the application, all end up with a 307.
In my program.cs I've tried adding
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.KnownProxies.Add(IPAddress.Parse("1.2.3.4"));
});
var app = builder.Build();
// Configure the HTTP request pipeline.
app.UseForwardedHeaders();
and changing the ipAddress 1.2.3.4 with the IP of example.com, and with the IP of actualserver.local
it's had no effect
I've added
app.UseHttpLogging();
which doesn't seem to report anything into the docker logs.
Does anyone have any ideas on what I can do to get the request from the reverse proxy to the web api, to actually process, and not result in a 307 temporary redirect response?
答案1
得分: 1
事实证明根本原因是....
app.UseHttpsRedirection();
这似乎不会影响从同一项目提供的 Swagger 页面发生的任何事情。但将其关闭,嘿,哇啦,它正在起作用!
英文:
Turns out the root cause is....
app.UseHttpsRedirection();
This doesn't seem to cause anything to happen to the swagger pages which are served from the same project. But turning that off and hey presto, it's working!!!
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论