I have a new Padrino 0.13.1 project that I am hosting on an AWS Elastic Beanstalk worker instance. The worker instance has a cron job that calls a POST every 5 minutes in my Padrino app. I have defined the routine as follows:
post :myroutine, :with => :myparams, :csrf_protection => false do
# ... do some stuff
status 200
end
I have also configured /config/apps.rb as follows:
Padrino.configure_apps do
set :session_secret, '...'
set :protection, :except => :path_traversal
set :protection_from_csrf, true
set :allow_disabled_csrf, true
end
The worker instance does a post to http://localhost:80/myroutine/somevar every 5 minutes. The nginx access.log file shows:
127.0.0.1 - - [21/Mar/2016:04:49:59 +0000] "POST /myroutine/01234 HTTP/1.1" 200 0 "-" "aws-sqsd/2.0" "-"
But in my AWS production.log file, I also see this come up every 5 minutes:
WARN - 21/Mar/2016 04:49:59 attack reported by Rack::Protection::AuthenticityToken
Strangely, the routine executes fine, and does what it is supposed to do. I would just like to stop my log file from filling up with the Rack::Protection error every 5 minutes.
Is this because of a misconfigured csrf setting somewhere, or a bug?
it is caused by nginx reverse proxy setting.
which may lost http related information , result session information lost.
https://github.com/znc/znc/issues/946
i just add below line and it works :
proxy_set_header X-Real_IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_pass_header Set-Cookie;
Related
Trying to get the two to work together. Is there something I'm missing or way to debug why it's not working?
Edited .devilbox/nginx.yml as suggested here although trying to contain it to path: wsapp
---
###
### Basic vHost skeleton
###
vhost: |
server {
listen __PORT____DEFAULT_VHOST__;
server_name __VHOST_NAME__ *.__VHOST_NAME__;
access_log "__ACCESS_LOG__" combined;
error_log "__ERROR_LOG__" warn;
# Reverse Proxy definition (Ensure to adjust the port, currently '8000')
location /wsapp/ {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://php:6001;
}
__REDIRECT__
__SSL__
__VHOST_DOCROOT__
__VHOST_RPROXY__
__PHP_FPM__
__ALIASES__
__DENIES__
__SERVER_STATUS__
# Custom directives
__CUSTOM__
}
Installed laravel-websockets and configured to use '/wsapp'
Visit the dashboard to test:
https://example.local/laravel-websockets
But console has error:
Firefox can’t establish a connection to the server at
wss://example.local:6001/wsapp/app/a558686cac00228eb003?protocol=7&client=js&version=4.3.1&flash=false.
2 pusher.min.js:8:6335 The connection to
wss://example.local:6001/wsapp/app/a558686cac00228eb003?protocol=7&client=js&version=4.3.1&flash=false
was interrupted while the page was loading. pusher.min.js:8:6335
I've Created a Setup that works...
first you need 2 domains in devilbox...
For you Laravel App (example.local)
For you Laravel Websocket (socket.example.local)
on your socket.example.local directory...
create htdocs and .devilbox here you'll add your nginx.yml file
when you try to connect to your socket.
don't use the port anymore...
and don't isolate the socket to /wsapp anymore...
use socket.example.local in .env PUSHER_HOST value
run your laravel websocket on example.local...
visit /laravel-websockets dashboard... remove the port value then click connect
I don't suggest you'll serve your socket in /wsapp because it's hard to configure nginx to serve 2 apps... (it's hard for me, maybe someone more expert on nginx can suggest something regarding this setup)
but that's my solution... if you didn't understand, please do comment
I have been doing some work trying to update our gitlab servers. Somewhere along the line, something in the configuration changed and now I can't access the web client. The backend starts up correctly and when I run rake gitlab:check everything comes back as green. Same for nginx, as far as I can tell it is working correctly. When I try to go to the landing page in the browser though, I keep getting an error about 'too many redirects'.
Looking at the browser console, I can see that it is repeatedly trying to redirect to the login page until the browser gives up and throws an error. I did some looking around, and most of the answers seem to involve going to the login page directly and then changing the landing page from the admin settings. When I tried that I got the same problem. Apparently any page on my domain wants to redirect to the login, leaving me with an infinite loop.
I'm also seeing some potentially related errors in the nginx logs. When I try to hit the sign in page the error log is showing
open() "/usr/local/Cellar/nginx/1.15.9/html/users/sign_in" failed (2: No such file or directory)
Is that even the correct directory for the gitlab html views? If not how do I change it?
Any help on this would be greatly appreciated.
Environment:
OSX 10.11.6 El Capitan
Gitlab 8.11
nginx 1.15.9
My config files. I have removed some commented out lines to save on space.
nginx.config
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
include servers/*;
}
nginx/servers/gitlab
upstream gitlab-workhorse {
server unix:/Users/git/gitlab/tmp/sockets/gitlab-workhorse.socket fail_timeout=0;
}
server {
listen 0.0.0.0:8081;
listen [::]:8081;
server_name git.my.server.com; ## Replace this with something like gitlab.example.com
server_tokens off; ## Don't show the nginx version number, a security best practice
## See app/controllers/application_controller.rb for headers set
## Individual nginx logs for this GitLab vhost
access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;
location / {
client_max_body_size 0;
gzip off;
## https://github.com/gitlabhq/gitlabhq/issues/694
## Some requests take more than 30 seconds.
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Host $http_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 http://gitlab-workhorse;
}
}
I finally found the answer after several days of digging. At some point my default config file (/etc/default/gitlab) got changed. For whatever reason, my text editor decided to split gitlab_workhorse_options into two lines. As a result, gitlab was missing the arguments for authSocket and document root and was just using the default values. If that wasn't bad enough, the line split started on a $ character, so it looked like nano was just doing a word wrap.
I've got my Keycloak Server deployed on aws EC2 behind a reverse Proxy and my Frontend client (Springbootapp) sits on a different EC2.
Now I get Invalid redirect_uri error, although it works when front-client is on localhost and Keycloak on aws. i.e.
Keycloak is reachable under: http://api.my-kc.site/
Valid Redirect URIs: http://localhost:8012/* and /login/* WORKS
The Query: https://api.my-kc.site/auth/realms/WebApps/protocol/openid-connect/auth?response_type=code&client_id=product-app&redirect_uri=http%3A%2F%2Flocalhost%3A8012%2Fsso%2Flogin&state=53185486-ef52-44a7-8304-ac4cfeb575ee&login=true&scope=openid
Valid Redirect URIs: http://awspublicip:80/* and /login/* does not WORK
And I also tried the suggestion not to specify the port, i.e http://awspublicip/*; but still this doesnt work :/
The Query: https://api.my-kc.site/auth/realms/WebApps/protocol/openid-connect/auth?response_type=code&client_id=product-app&redirect_uri=https%3A%2F%2Fawspublicip%3A0%2Fsso%2Flogin&state=8bbb01e7-ad4d-4ee1-83fa-efb7f05397cc&login=true&scope=openid
Does anyone have an idea? I've been looking all the Invalid redirect_uri post, but nothing seem to add up.
It seems Keycloack generates different redirect URis for the query when the initiator of the request is not localhost. Does someone know how to avoid this?
localhost
public dns
I was having the same exact problem. My spring boot app sits behind nginx. I updated nginx to pass through the x-forwarded headers and updated the spring boot config with
spring boot yaml config:
server:
use-forward-headers: true
keycloak:
realm: myrealm
public-client: true
resource: myclient
auth-server-url: https://sso.example.com:443/auth
ssl-required: external
confidential-port: 443
nginx config:
upstream app {
server 1.2.3.4:8042 max_fails=1 fail_timeout=60s;
server 1.2.3.5:8042 max_fails=1 fail_timeout=60s;
}
server {
listen 443;
server_name www.example.com;
...
location / {
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_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port 443;
proxy_next_upstream error timeout invalid_header http_500;
proxy_connect_timeout 2;
proxy_pass http://app;
}
}
The specific change that made it work for me was adding keycloak.confidential-port. Once I added that it was no longer adding port 0 in the redirect_uri.
The only setting I have in Keycloak > Cofigure > Realm > Clients > my-client is Valid Redirect URIs set to: https://www.example.com/*
Hope that helps. It took me hours to track this down and get it working.
It seems that the query parameter "redirect_url" didn't match the setting of valid redirect URIs.
redirect_url: https%3A%2F%2Fawspublicip%3A0%2Fsso%2Flogin <- It's https
Valid Redirect URIs: http://awspublicip:80/* <- But it's http
in my case, I have a Spring boot application uses Keycloak as auth. provider. Used to work fine when redirecting to http://localhost:8080/*. But didn't work when deployed since the redirection is to https://.../*.
Adding server.forward-headers-strategy=framework to application.properties did the magic.
I'm trying to deploy my first Clojure WebSocket app and I think I'm getting close. I get a good response locally, and it looks like the endpoint wants to face the outside world (I see that the port is open when I run netstat), but no response. I'm certain that I have something setup incorrectly in nginx.
I currently already host a few other websites on this server, just want to add the necessary config to get requests made to wss://domain.com:8001 to communicate with my app.
Here is the location entry I'm using now:
location / {
proxy_pass http://localhost:8001;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
access_log /var/www/logs/test.access.log;
error_log /var/www/logs/test.error.log;
}
Could anyone help point me in the right direction? My guess is that I actually have too much in the config, and what's there is probably not correct.
** EDIT: ** For interested parties, I put up my working config (based on Erik Dannenberg's answer) in a gist.
You are missing two more headers, a minimal working config:
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
# add the two below
proxy_set_header Upgrade websocket;
proxy_set_header Connection upgrade;
# optional, but helpful if you run into timeouts
proxy_read_timeout 86400;
}
I've got an Nginx/Gunicorn/Django server deployed on a Centos 6 machine with only the SSL port (443) visible to the outside world. So unless the server is called with the https://, you won't get any response. If you call it with an http://domain:443, you'll merely get a 400 Bad Request message. Port 443 is the only way to hit the server.
I'm using Nginx to serve my static files (CSS, etc.) and all other requests are handled by Gunicorn, which is running Django at http://localhost:8000. So, navigating to https://domain.com works just fine, as do links within the admin site, but when I submit a form in the Django admin, the https is lost on the redirect and I'm sent to http://domain.com/request_uri which fails to reach the server. The POST action does work properly even so and the database is updated.
My configuration file is listed below. The location location / section is where I feel like the solution should be found. But it doesn't seem like the proxy_set_header X-* directives have any effect. Am I missing a module or something? I'm running nginx/1.0.15.
Everything I can find on the internet points to the X-Forwarded-Protocol https like it should do something, but I get no change. I'm also unable to get the debugging working on the remote server, though my next step may have to be compiling locally with debugging enabled to get some more clues. The last resort is to expose port 80 and redirect everything...but that requires some paperwork.
[http://pastebin.com/Rcg3p6vQ](My nginx configure arguments)
server {
listen 443 ssl;
ssl on;
ssl_certificate /path/to/cert.crt;
ssl_certificate_key /path/to/key.key;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
server_name example.com;
root /home/gunicorn/project/app;
access_log /home/gunicorn/logs/access.log;
error_log /home/gunicorn/logs/error.log debug;
location /static/ {
autoindex on;
root /home/gunicorn;
}
location / {
proxy_pass http://localhost:8000/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Protocol https;
}
}
Haven't had time yet to understand exactly what these two lines do, but removing them solved my problems:
proxy_redirect off;
proxy_set_header Host $host;