I've seen some limited resources on checking for cookies with Nginx, but I couldn't really find the answer I was looking for, hopefully some of you Nginx masters can give me a hand.
Essentially I have a vhost that I'd like to redirect to a different domain unless the user has a cookie, here is what I've created:
server {
listen 80;
server_name example.com;
if ($http_cookie ~* "dev_cookie" ) {
root /home/deploy/apps/example/current/public;
passenger_enabled on;
rack_env production;
break;
}
rewrite ^/(.*) http://beta.example.com/$1 permanent;
}
But it doesn't seem to work, I get the error:
[emerg]: "root" directive is not allowed here in /opt/nginx/conf/nginx.conf:45
I'm not sure how to proceed here, any ideas guys?
That makes sense.
I would define another virtual host (beta.example.com) with that different root folder
and upon encountering cookie - do a rewrite
You can't set different roots for a domain conditionally, but you can redirect (rewrite) to another domain conditionally
This guy's example helped me a bit ago
http://nicknotfound.com/2009/01/12/iphone-website-with-nginx/
Related
I'm a bit stuck on this one and any assistance would be amazing. I'm very much an Nginx noob.
We have an existing Nginx setup with lots of redirections already configured.
I'm trying to only redirect one subdomain in Nginx to an external url, however no matter what I try it redirects all subdomains.
I've reviewed our existing configs to get some understanding of how things are setup but the life of me I just can't work this one out and all the search results I seem to find are for redirecting all subdomains or sub sites not for redirecting just one subdomain of many.
This subdomain didn't have an existing config and I've had to create one (copy one of our others and edit it) it looks like previously the subdomain was configured under a catch all.
Example:
I need https://foo-bar.test.com.au to redirect to https://externalURL.com
However I don't want https://other-site.test.com.au to redirect to https://externalURL.com
This is the current config
server {
server_name foo-bar.test.com.au;
rewrite ^ https://externalURL.com;
root /opt/nginx-static/foo-bar;
}
server {
listen 443 ssl http2;
server_name foo-bar.test.com.au;
rewrite ^/(.*)$ https://externalURL;
ssl_certificate /etc/ssl/foo-bar.crt;
ssl_certificate_key /etc/ssl/foo-bar.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_timeout 30m;
root /opt/nginx-static/foo-bar;
location / {
root /opt/nginx-static/foo-bar;
index index.html foo-bar.html;
autoindex on;
}
}
I got this figured out.
Turns out the order of the .conf files matters
Renamed the config to zz.foo-bar.conf so it comes after default.conf
Also the permissions weren't set correctly on /opt/nginx-static/foo-bar
The other piece of the puzzle was DNS, I'd altered it earlier in my troubleshooting, turns out I needed to revert it back to the original DNS entry.
I've been having a lot of trouble with rewrite directives - nothing seemed to actually work, so I tried making the most basic rewrite sample that I could:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /var/www/html;
location / {
rewrite ^/a$ /test.html break;
}
}
I was assuming this would return the contents of /var/www/html/test.html at http://localhost/a but it doesn't, it gives me a 404. Permissions on test.html are set correctly and it is accessible at http://localhost/test.html. I'm assuming rewriting is actually disabled - but I can't find anything like that in nginx.conf. The settings file above is the default in sites-available, and other than adding rewrite_log on; to the nginx.conf file everything is stock as distributed by the nginx 1.12.1 package in Ubuntu (17.10).
Logs provide no useful information and enabling rewrite logging has added no extra information to the logs. And yes, I've restarted nginx after each edit of the settings.
I've been trying all sorts of combinations, so at this point I'm just assuming rewrites aren't working/enabled? I'm totally confused here - ANY hints would be a big help.
I have no idea why but changing break to last made it work. This is confusing to me, as with this configuration I wouldn't expect there to be any processing after the rewrite. This is a pretty fresh install and there's not actually anything else on it yet that I would think would be interfering - so there must be some reason for this? If anyone has a better answer I'll switch the accepted, but for now this 'worked'.
i have 2 servers, one has ssl and i config it like this,
in the server with SSL certification(which is https:// www.example.com):
location ~^/abc/.* {
proxy_pass http://www.example.com:8214/
}
in another server(which is http:// www.anotherExample.com):
server {
listen 8214;
server_name www.anotherExample.com;
rewrite ^/(.*)$ http://www.anotherExample.com:8080/$1 permanent;
}
and after access https:// www.example.com/abc/api/getGroup
it can't redirect to http:// www.anotherExample.com:8080/api/getGroup
Anything wrong???
There are a couple of things you could do to improve your configuration.
location ^~ /abc/ {
proxy_pass http://www.example.com:8214$uri;
#You should have other directives set here as well.
}
Also, consider setting up an upstream.
Then, for your server block:
server{
listen 8124;
server_name www.anotherExample.com;
rewrite ^/abc/(.*)$ http://www.anotherExample.com:8080/$1 permanent;
}
server{
listen 8080;
server_name www.anotherExample.com;
location ^~ /api/ {
#your_config_here
}
}
The explanation:
In your first location block, you shouldn't have .* in the expression. Nginx will match this for you. Then, when you're proxying, you can explicitly tell Nginx to send the URI as well.
Next, you're sending the URI www.anotherExample.com:8124, which includes /abc/, so you want to extract everything after that.
Lastly, because you've rewritten it to point to 8080 port, you'll need to define a separate server block for this.
I don't know what you're aiming to achieve, but so much proxying and redirects isn't necessary in most cases, and might lead to poor performance. Another consideration that you should take into account is you're sending unencrypted information to anotherExample.com, which, if not on the same local network, might be a security vulnerability.
I have some 100 or so URLs that need to be permanently redirected from static HTML to dynamic pages served by Wordpress. All examples for Nginx 301 redirection I found suggest that each redirect should be defined as its own server block.
However, I have found out that multiple redirects within one server block work as well such as in this simplified configuration:
server {
listen 80;
server_name www.example.com;
root /var/www/;
location = /subdir/red1.html { return 301 /subdir/?p=1; }
location = /subdir/red2.html { return 301 /subdir/?p=2; }
location = /subdir/red3.html { return 301 /subdir/?p=3; }
}
Curl -I confirms the 301 code. The redirects take place. I prefer this configuration to the one with one server block per redirect because human readability is better. But does this configuration lack something that I'd otherwise have if each redirect was in its own server block?
Well, execrpts you found are probably dealing with http to https redirections where it makes sense not to have anything more in the server block because the vhost is only there to redirect to an other domain. That's completely wrong to pick random examples and take them as a rules of thumb instead of refering to the official documentation.
100 redirects is not a huge count, you could even use permanent rewrites in one unique server block and group them with regexs.
server {
server_name www.example.com;
root /var/www/;
location /subdir/ {
rewrite ^/subdir/red([1-3])\.html /subdir/?p=$1 permanent;
}
}
After adding rewrite block, the Ubuntu 12.04 server hosting Rails 3.2.12 app throws out 404 Not Found error when entering mysite.com/nbhy.
Here nbhy is a symlink under root /var/www/ pointing to /var/www/nbhyop/current/public and it is for hosting rails app. The purpose of the rewrite is to rewrite to /nbhy/authentify/sigin when user entering /nbhy or /nbhy/
Here is server block in nginx.conf:
server {
listen 80;
server_name mysite.com;
root /var/www/;
passenger_enabled on;
rails_env production;
passenger_base_uri /nbhy;
}
location / {
rewrite "/nbhy" /nbhy/authentify/signin last;
rewrite "/nbhy/" /nbhy/authentify/signin last;
}
}
The error.log on nginx for the error is:
2013/06/09 21:36:31 [error] 32505#0: *1 open() "/var/www/nbhy/authentify/signin" failed (2: No such file or directory), client: 67.173.143.107, server: mysite.com, request: "GET /nbhy HTTP/1.1", host: "mysite.com"
Before adding rewrite location block, the system could bring up login page with url mysite.com/nbhy/authentify/signin. But now it throws out error after adding the rewrite block. What's wrong with the rewrite?
The location block must be within the server block:
server {
listen 80;
server_name mysite.com;
root /var/www/;
passenger_enabled on;
rails_env production;
passenger_base_uri /nbhy;
location / {
# Matches /nbhy /nbhy/ /nbhy////////////...
location ~ ^/nbhy/*$ {
return 301 /nbhy/authentify/signin;
}
# Other rules (regex) goes here
}
}
The symbolic link is from no concern at this stage of processing.
You are using rewrite, were the first pattern is always a regular expression. Mohammad AbuShady was absolutely right with his answer of using a more specific location. But using a rewrite is not necessary, a return is better because we want nginx to abort execution and simply—well—return.
Also note how I enclosed the regular expression within the generic block location / {} which matches all locations. This is the proper way to write location blocks according to Igor Sysoev. See this forum post for more info.
My configuration above is also catching URLs with more than one slash (hence the *) and is meant as a more user friendly matching because a user might simply type too many slashes. No need to punish them, instead answer with a proper redirect.
I hope this helps!
Related Links
How nginx processes a request
If I understand correctly, you have a URI your-host/nbhy which you want to rewrite to your-host/nbhy/authentify/signin, which should be linked to /var/www/nbhy/authentify/signin, which is symlinked to /var/www/nbhyop/current/public/authentify/signin?
It looks like nginx is complaining about not finding /var/www/nbhy/authentify/signin. Since you have a symlink from /var/www/nbhy to /var/www/nbhyop/current/public, there has to be a folder /var/www/nbhyop/current/public/authentify/signin. Are you sure there is one, and that your www-data user (or whatever user you're using) has rights to the directories above it?
Also, nginx has an option for disabling symlinks. Try setting that to off. That's the default, I know, but there might be another file that sets it to on.
It might also be that nginx doesn't follow the symlink because you added last to your rewrites. Try removing that, and see if it works then.
why not try adding a more specific location block
location ~ /nbhy/?$ {
rewrite ^ /nbhy/authentify/signin last;
}
or you could remove the regex but it would match longer urls like /nbhy/one/two
location /nbhy {
rewrite ^ /nbhy/authentify/signin last;
}