Situation:
Enviroment:
1 Server: Oracle Linux
Micro-integrator 4.1.0 running
Api-Manager 4.1.0 running
Admin,Publisher, DevPortal sites can be accessed within the server and the LAN
An API I've created with oauth2 (authorization+token) can be accessed within the LAN (via Postman)
NOW...I want to expose that API to internet. My IT Team addedfollowing to the DMZ server (NGINX) conf file, where oauth2 is to invoke the auth services and dsFenicio is the API .
location /oauth2 {
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-Proto $scheme;
proxy_pass https://192.168.135.64:9443;
proxy_read_timeout 300;
proxy_ssl_server_name on;
proxy_ssl_session_reuse off;
proxy_ssl_verify off;
}
location /dsFenicio {
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-Proto $scheme;
proxy_pass https://192.168.135.64:8243;
proxy_read_timeout 300;
proxy_ssl_server_name on;
proxy_ssl_session_reuse off;
proxy_ssl_verify off;
}
The Problem:
When I sent the oauth2 autorization code request (from postman), I received a msg in the browser stating: "Suspicious authentication attempts found
Suspicious login attempts found during the authentication process. Please try signing in again"
and this is in the Logs (wso2carbon.log):
ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Exception in Authentication Framework org.ws$wso2.carbon.identity.application.authentication.framework.exception.FrameworkException: Session nonce cookie value is not matching for session with sessionDataKey: bf74d0ec-05ef-4682- ...
This is due to a feature called Session Nonce Cookie Validation which is enabled by default.
I was able to reproduce this scenario and was able to solve this situation while keeping the session nonce cookie validation enabled. The following steps were followed.
Exposed the /commonauth, /authenticationendpoint, /logincontext endpoints through nginx in addition to the /oauth2 endpoint.
Added the following to the deployment.toml
[authentication.endpoints]
login_url="https://<loadbalancer_hostname>/authenticationendpoint/login.do"
retry_url="https://<loadbalancer_hostname>/authenticationendpoint/retry.do"
Without the above steps, you can disable this feature also for your scenario to work. This feature can be disabled by adding the following to the deployment.toml file.
[session.nonce.cookie]
enabled="false"
Related
I'm having some issues hosting blazor WASM standalone (without an asp.net core project as host) behind nginx as a reverse proxy.
Here is my Nginx default config file:
server {
listen 80;
listen [::]:80;
server_name localhost;
location / {
root /var/www/web/BlazorApp/wwwroot;
try_files $uri $uri/ index.html =404;
include /etc/nginx/mime.types;
types {
application/wasm wasm;
}
default_type application/octet-stream;
}
location /service1/ {
proxy_pass http://localhost:5001/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /service2/ {
proxy_pass http://localhost:5002/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /service3/ {
proxy_pass http://localhost:5003/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
This Configuration works in the sense that I can access my blazor app using
http://{server-ip-address}
and my other services using
http://{server-ip-address}/serviceX
where X would refer to service 1,2 and 3 respectively
First issue: when I navigate in my blazor app for example to http://{server-ip-address}/My-Blazor-Page and I refresh the page I get a 404 not found error.
for it to work back again I need to go back to the base address http://{server-ip-address} and navigate back to My-Blazor-Page.
I cannot refresh a page and go back to the same page.
Second issue: I would like my blazor app to have a different location. I would like to use http://{server-ip-address}/Blazor rather than http://{server-ip-address}/.
I tried everything to get it right but this is the only config that semi-works
Many thanks for your help!
The following nginx.conf file is simplified to show how to configure Nginx to send the index.html file whenever it can't find a corresponding file on disk.
When setting the NGINX burst rate limit with limit_req, Blazor WebAssembly apps may require a large burst parameter value to accommodate the relatively large number of requests made by an app. Initially, set the value to at least 60:
Increase the value if browser developer tools or a network traffic tool indicates that requests are receiving a 503 - Service Unavailable status code.
For more information on production Nginx web server configuration, see Creating NGINX Plus and NGINX Configuration Files.
The above will try the URL, and if no file matches, it'll serve index.html instead. This is the way.
For your second issue, you should set the base attribute value to "Blazor" and put all files in the Blazor directory (the config needs to match this). You can also route differently, but this is the easiest.
I am trying to proxy a simple lambda function on AWS through traefik. But AWS is returning status code 403 with message "Bad Request" when tried with the proxied link. I think this is because of the Host header being passed wrongly as seen on other reverse proxies.
I faced the same with nginx as well but this is fixed by providing the following conf settings
proxy_set_header Host <aws_hostname>;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Getting 'Forbidden' on clicking 'Enqueue now' in staging and production environment.
Using 'rails', '5.1.6', sidekiq-cron (1.0.4) which uses fugit (~> 1.1) and sidekiq (>= 4.2.1)
I can see from sidekiq-cron issue 60 and sidekiq-cron issue 61 that issue got resolved a long back but still getting same issue.
Sidekiq::Web uses Rack::Protection to protect application against typical web attacks (e.g CSRF, XSS, etc). Rack::Protection would invalidate session and raise 'Forbidden' error if it finds that request doesn't satisfy security requirements. One of the possible situations is having application working behind a reverse proxy and not passing important headers to it (X-Forwarded-For,X-Forwarded-Proto).
Well after spending enough time figuring out the issue. This is what helped me.
Nginx configuration:
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Connection '';
proxy_pass http://app;
#proxy_set_header X-Forwarded-Ssl on; # Optional
#proxy_set_header X-Forwarded-Port $server_port;
#proxy_set_header X-Forwarded-Host $host;
Other solutions, which did not work for me but worked for others:
Sidekiq monitoring
Sidekiq issue 2487
Rack protection and nginx
Sidekiq issue 2560
I currently have APIs running under http://example.com/api/v3/ and I want to move the APIs to a different server at http://exampleapi.com/v3.
I first thought about creating a location block in nginx to handle the requests such as:
location ~*/api/(v[0-9]+/[a-zA-Z0-9_]+) {
return 301 $scheme://exampleapi.com/$1;
}
However, using a REST client, the requests are being received as GET requests not POST. Same thing using a browser (Firefox).
I have tried the proxy pass but I was not able to make it work. This is what I tried:
location ~*/api/(v[0-9]+/[a-zA-Z0-9_]+) {
proxy_pass http://exampleapi.com/$1;
# proxy_redirect http://exampleapi.com/ /;
proxy_read_timeout 60s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
I am getting 502 or 500.
What is the best way to achieve moving the APIs?
After debugging locally the same issue, I found out that I cannot proxy pass to a domain, but only to IP address as there is no resolver to resolve this domain.
Hence I created a new server block for exampleapi.com to listen on a port, and proxy passed to that port, such as:
location ~*/api/(v[0-9]+/[a-zA-Z0-9_]+) {
proxy_pass http://127.0.0.1:4545/$1;
proxy_read_timeout 60s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
I'm flummoxed.
I have a server that is primarily running couchdb over ssl (using nginx to proxy the ssl connection) but also has to serve some apache stuff.
Basically I want everything that DOESN'T start /www to be sent to the couchdb backend. If a url DOES start /www then it should be mapped to the local apache server on port 8080.
My config below works with the exception that I'm getting prompted for authentication on the /www paths as well. I'm a bit more used to configuring Apache than nginx, so I suspect I'm mis-understanding something, but if anyone can see what is wrong from my configuration (below) I'd be most grateful.
To clarify my use scenario;
https://my-domain.com/www/script.cgi should be proxied to
http://localhost:8080/script.cgi
https://my-domain.com/anythingelse should be proxied to
http://localhost:5984/anythingelse
ONLY the second should require authentication. It is the authentication issue that is causing problems - as I mentioned, I am being challenged on https://my-domain.com/www/anything as well :-(
Here's the config, thanks for any insight.
server {
listen 443;
ssl on;
# Any url starting /www needs to be mapped to the root
# of the back end application server on 8080
location ^~ /www/ {
proxy_pass http://localhost:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
# Everything else has to be sent to the couchdb server running on
# port 5984 and for security, this is protected with auth_basic
# authentication.
location / {
auth_basic "Restricted";
auth_basic_user_file /path-to-passwords;
proxy_pass http://localhost:5984;
proxy_redirect off;
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-Ssl on;
}
}
Maxim helpfully answered this for me by mentioning that browsers accessing the favicon would trigger this behaviour and that the config was correct in other respects.