I have set up nginx as a reverse proxy for our jenkins server. Nginx is using proxy_pass to the jenkins server so it should just be forwarding the requests and responses.
When I go to my.domain.com/jenkins (hitting the nginx server) the url is fine. I can click on the url for each project and the url will still look like: my.domain.com/jenkins/job/myProject/. Even going to jenkins configure is fine.
The problem:
When I click on Configure Global Security the url changes to jenkin's sever IP. This wouldn't be such an issue but the Google Login Plugin is hitting it as well and my OAuth callbacks are set to hit the nginx server.
What I've Done:
I have set the Jenkins URL in configure to be my.domain.com/jenkins
Made sure the JENKINS_ARGS have the --prefix=/jenkins
Restarted Jenkins after setting the url in the configuration.
Verified jenkins.model.JenkinsLocationConfiguration.xml has the correct location
Any ideas or suggestions would be amazing! Thank You!
The issue was nginx and the way I was redirecting.
I was using:
location /jenkins/ {
proxy_pass $scheme://ip.address.to.server:port;
}
But needed:
location /jenkins/ {
proxy_pass $scheme://ip.address.to.server:port;
proxy_redirect off;
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;
}
Related
How can I correctly configure nginx and phpmyadmin? I've configured nginx and can access phpmyadmin login page through nginx but unable to login, when I try to login it shows Failed to set session cookie. Maybe you are using HTTP instead of HTTPS to access phpMyAdmin.
I'm accessing through https://example.com/phpmyadmin/
and this is the nginx config
location /myphpadminroute/{
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 host $host;
proxy_pass_request_headers on;
root path_to_phpmyadmin/phpMyAdmin/;
proxy_pass http://localhost:8080/phpmyadmin/; # apache is running on 8080
}
The login is working fine when using apache url either http://localhost:8080/phpmyadmin/ or https://localhost:8443/phpmyadmin/
I've also tried with proxy_pass https://localhost:8443/phpmyadmin/; in nginx but same error rises.
Whether it is nginx configuration problem or phpmyadmin I just couldn't figure it out.
Edit: The cookie path is not correct phpMyAdmin_https=utd7tbihn9qp9r4e0f0dvj6tpo; path=/phpmyadmin/; secure; HttpOnly and it's working fine if I change nginx path to /phpMyAdmin/ now how can I change cookie path in phpmyadmin
Finally it's working perfectly fine.
For those who are also facing this type of problem the trick is to just set variable in config.inc.php $cfg['PmaAbsoluteUri'] to the url that your user should see
for example $cfg['PmaAbsoluteUri'] = https://example.com/myphpadminroute
suppose i Have a server on ip 111.111.111.111
on which nginx server is installed as a web server
I want that if someone visit on
http://111.111.111.111/new
They should see the content of
http://example.github.io/new
Someone told me it is possible via NGINX Reverse Proxy or Apache Reverse Proxy
The trick of configuring sites-enabled/default works fine for locally hosted sites on different port but it is not working for external website.
What i have done for this (on server 111.111.111.111):
in /etc/nginx/sites-enabled/default
server {
listen 80;
location /new/ {
proxy_pass http://example.github.io/new;
proxy_redirect default;
proxy_buffering 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-Protocol $scheme;
}
}
What i got :
404
There isn't a GitHub Pages site here.
GitHub Pages allows repository owners to associate a domain with that repository, which it verifies by making sure that domain's A/CNAME records are pointed to GitHub.
If you are pointing the entirety of your domain to this GitHub page, then you do not need a reverse proxy, as the A records will accurately point your domain to GitHub Pages.
Your configuration aims to only reverse proxy a directory of your domain, instead of your domain as a whole. However, you are setting your Host header to match the Host header as requested by the client. As a result, GitHub Pages is checking if that repository is configured to receive traffic as 111.111.111.111, which it is not. This is why you receive the 404 error -- there is not a GitHub Pages configuration that matches that repository and host combination.
Change the Host header in proxy_set_header to example.github.io so that, even though the client requested 111.111.111.111, GitHub receives the request as a request for example.github.io.
I've installed GitLab 8.0.2 on a VM, and I have an nginx reverse proxy set up to direct HTTP traffic to the VM. I am able to view the main login page for GitLab, but when I try to login using the Google OAuth2 method, the callback fails to log me in after entering my correct credentials. I simply get directed back to the GitLab login page.
Where might the problem be? The reverse proxy settings? GitLab settings (ie. Google OAuth config)?
Below is my nginx conf:
upstream gitlab {
server 192.168.122.134:80;
}
server {
listen 80;
server_name myserver.com;
access_log /var/log/nginx/gitlab.access.log;
error_log /var/log/nginx/gitlab.error.log;
root /dev/null;
## send request back to gitlab ##
location / {
proxy_pass http://gitlab;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_redirect off;
proxy_buffering off;
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;
}
}
Interestingly, the old setup I had used iptables to redirect port 81 on the host machine to port 80 on the GitLab VM, and, in that case, the Google OAuth callback worked. I'd prefer to have people simply use standard port 80 for accessing my GitLab instance, though, so I want this reverse proxy method to work.
GitLab 8.x has quite a few new things. Although I don't see anything specifically wrong with your nginx.conf file, it is pretty short compared to the example in the GitLab repository. Look through https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab-ssl to get an idea of the configuration you should consider adding.
Once your nginx.conf file is updated, read through GitLab OmniAuth documentation and the Google OAuth2 integration documentation under 'Providers' on that OmniAuth page. Make sure you provide the correct callback URL to Google when registering.
See image below of vaadin 7, nginx. What could be wrong?
web.xml
sample config:
server {
listen 80;
server_name crm.komrus.com;
root /home/deploy/apache-tomcat-7.0.57/webapps/komruscrm;
proxy_cache one;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080/komruscrm/;
}
}
As it seems (because you don't provide enough info about your problem) you are using nginx as reverse proxy for tomcat/jboss/jetty, and you are deploying a Vaadin application in it.
Just when you enter in the application, session expired message appears.
I had this problem 3 months ago. In my escenario Nginx was 1.0 and Vaadin 7.0+. The issue comes because of the cookies. I know that nginx must set or rewrite something in the cookies, but, you must set it manually in nginx.conf file, else, you will get that error.
Sadly, in my nginx version I wasn't able to pass cookies in the right way, so, I wasn't able to deploy my application under that scenario.
After some issues, I've decided to use Apache's reverse proxy, and never saw that issue again. Hope you can write a rule that enables to pass the cookies in the right way.
EDIT: I remembered this post How to rewrite the domain part of Set-Cookie in a nginx reverse proxy?, this is the case!
I am feeling that I have searched the complete internet and tried nearly everything to solve my problem. Now I decided to ask you and hope that there is anybody out there who is able to help me.
I have a node application running on sub2.domain.tld:3000. Now I want to proxy this application to port 80 with nginx in the way that I am able to reach the app with sub.domain.tld. But that is not the problem. I am able to reach the first site.
The problem follows by an authentification routine with OAuth-API to verify the user for the application.
When surfing to sub2.domain.tld:3000 the process works fine. But when I change the url in the configs and try to surf to sub.domain.tld the authentification process runs into an error (error=redirect_uri_mismatch&error_description=The+redirect_uri+MUST+match+the+registered+callback+URL.....).
So I guess I am making a mistake in the redirecting of the url with nginx.
I am using nginx 1.4.7 and node 0.10.26
My nginx configuration file looks like that:
server {
listen 80;
access_log /var/log/nginx/access_log_sub;
server_name sub.domain.tld;
location / {
include proxy_params;
proxy_pass http://IP:3000;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Client-IP $remote_addr;
proxy_set_header X-Forwarded-for $remote_addr;
}
}
But I belive OAuth is verifying sub2.domain.tld:3000 and that it gets in conflict with sub.domain.tld
I hope you are able to help me, solving this issue.
The error isn't coming from nginx, it's coming from your OAuth provider:
The redirect_uri parameter is optional. If left out, GitHub will redirect users to the callback URL configured in the OAuth Application settings. If provided, the redirect URL's host and port must exactly match the callback URL. The redirect URL's path must reference a subdirectory of the callback URL.
-- https://developer.github.com/v3/oauth/#redirect-urls
This is an old question, but...
Try changing your Host header to
proxy_set_header Host $host:$server_port
This may or may not work depending on your application.
As an aside, X-Forwarded-For should include a comma-separated list of the originating client and any proxies it passes through.