I've started to use Elastic Beanstalk with Ruby + Passenger Standalone which seems awesome, however I want to redirect all HTTP to HTTPS, I haven't managed to find any resource at all about this. I've been looking at customizing the nginx.conf.erb but can't really find out what to do.
Note that I already have SSL working, I just need to make all requests redirecting to SSL.
Thanks,
Johan
server {
listen 80;
server_name my.domain.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
server_name my.domain.com;
[....]
}
It seems to late to answer this question. Just for those who need to tackle this in the future:
Try adding "port": 80 in your Passengerfile.json, and uncommenting "config.force_ssl = true" in your config/environments/production.rb.
The first change will direct your browser's request (without specifying port or protocol, i.e. something like www.example.com) to passenger. The second line tells passenger to redirect any http request to https.
Related
I have a website running at https://example.com:555
The 80 and 443 port for the same public ip have been forwarded to another server.
I only want to re-direct the url from http://example.com:555/1618/?id=877 to https://example.com:555/1618/?id=877
Right now I am getting the 400 error "Your browser sent a request that this server could not understand..."
I am using apache 2.4 on ubuntu 20.04
Any leads would be highly appreciated.
Thanks.
adding "ErrorDocument 400 https://example.com:555" in .htaccess
works but the id parameter is not passed
adding ErrorDocument in the localized-error-pages.conf in apache
works but the id parameter is not passed
configure Strict-Transport-Security
didnt work
trying different $1 , REQUEST_URI etc in .htaccess
did not work
So I have a Master caddy which redirects to another servers inside the LAN.
The current configuration of the Master is like the following:
http://example.com {
proxy / http://192.168.1.153:80 {
transparent
}
}
https://example.com {
proxy / https://192.168.1.153:443 {
transparent
}
}
And the configuration of the caddy at 192.168.1.153 is the following:
http://example.com, https://example.com {
root /example.com
}
http://example.com works fine but https://example.con gives 502 Bad Gateway.
If i use insecure_skip_verify I receive 403... And I don't want to use it anyway.
Both 80 and 443 are open on the router and redirecting to the Master caddy. There must be something wrong with my configuration but I cannot see what is it.
PD
I have tried:
192.168.1.153:443
https://192.168.1.153
None seem to work.
Updated with solution
http://example.com {
redir https://{host}{uri}
}
https://example.com {
proxy / 192.168.1.153:80 {
transparent
}
}
This also redirects 80 to 443, but the catch is that the "slave" on 192.168.1.153 must respond on port 80, not on 443. Because the 80 gets "upgraded" to 443 on the master caddy.
Of course that will not work. You have at least 2 servers each with a different IP. So, let me explain it to you.
One server has its IP binded to the dns example.com so it is ok for its Caddyfile to listen at http://example.com. Also, this caddyfile redirects to the server with the IP 192.168.1.153 (the second server).
The second server neither has the dns example.com binded to its IP nor should it listen at that dns. Instead you should change its listerner at its IP or just define the port. Here is how the second caddyfile should look like.
:80 {
tls off
root /example.com
}
Regarding enabled SSL
You are not assigning certificates for SSL so it does not make sense to add https:// or even listeners at 443. Keep it in http until you get certificates.
It is possible to proxy to another HTTPS backend with encryption the entire way.
You just need to specify the SNI to send to the backend server.
Using Caddy v2:
http://exmaple.com {
reverse_proxy http://192.168.1.153
}
https://example.com {
reverse_proxy https://192.168.1.153 {
transport http {
tls_server_name example.com
}
}
}
On the backend, just listen as usual:
example.com {
# Do whatever here
}
So we do have our Jekyll app that serves a static webpage, which includes a contact form.
This contact form request then gets passed (POST) to our Sinatra-app at http://sub.example.com/send_email to deliver an email to inform us about the new contact..
So far so good, everything works fine if we run the Sinatra-app by using
bundle exec rackup config.ru
However, upon starting nginx and passenger_ruby, our Sinatra app does not receive any data whatsoever.
We have set up the server like this:
server {
listen 80;
server_name sub.example.com;
error_log /home/example/error.log warn;
access_log /home/example/access.log;
passenger_enabled on;
passenger_ruby /home/example/.rbenv/shims/ruby;
root /home/example/evil_contact/public;
}
Now when accessing http://sub.example.com the access.log and error.log file do not have any entry. It is as if the request wouldn't arrive over at nginx or does not get passed through.
Let me know if there is something else needed.
Maybe we are just missing something obvious here.
Thank you in advance.
Alrighty,
After dozen of coffees the solution was not to change the nginx settings, but check the DNS records.
Afterall, the DNS entry had still a wrong IP assigned, so the request was going somewhere else.
I wasn't sure whether to put this in Serverfault or on Stackoverflow; it doesn't seem to be a server issue so I though here would be best.
I am currently working on a university website, and for some reason Firefox refuses to load the site unless you use www (ex www.university.edu). Every other browser accepts university.edu and simply redirects to www.university.edu as nginx is setup to do. My nginx config:
server {
listen 80;
server_name university.edu www;
rewritei ^http://www.university.edu$request_uri? permanent;
}
server {
listen 80;
server_name www.university.edu static.university.edu m.university.edu www.university.com;
.
.
.
}
So what should happen is when a request comes in and is www.university.edu, the second block catches it and everything runs normally, but if a request comes in and is university.edu the first block catches it and redirects it to the second block. But for some reason Firefox is not doing this.
Any idea's what could be causing this issue?
Update 1:
rewritei is not mispelled. The university's nginx was changed before it was compiled to enable regex case insensitivity, and was placed under the function "rewritei". Also after playing around with the site I found figured out that if you visit the site at www.university.edu first, then try university.edu it will load, but if you clear the cache and try to visit university.edu it will not load until you visit www.university.edu.
You have a typo; "rewrite" and try removing the www.
server {
listen 80;
server_name university.edu;
return 301 http://www.university.edu$request_uri;
}
Also take a look at the pitfalls on rewrite - http://wiki.nginx.org/Pitfalls#Taxing_Rewrites
I'm trying to configure http and https redirects from an old site to a new one.
According to the rewrite directive docs:
If the replacement string begins with http:// then the client will
be redirected, and any further rewrite directives are terminated.
And I'm trying to achieve the same with https to no avail.
This is my server config:
listen 80;
listen 443 ssl;
server_name mydomain.com
rewrite ^/path/resource(.*)$ $scheme://newdomain.com/newpath/resource$1 permanent;
...
return 301 http://newdomain.com/newpath/;
Using http I get what I'm looking for: if I access mydomain.com/path/resource I'm redirected to newdomain.com/newpath/resource.
However, the same with https redirects me to http://newdomain.com/newpath/.
I have rewrite_log on and in both cases the rewrite rule is matched but the https protocol does not stop further rules processing.
I have the feeling that either I'm missing something really obvious or I'm not approaching this problem properly. I wouldn't mind doing this in any different way at all if it works.
Have any of you out there any idea on how to achieve the http redirect with https too?
I usually like to use return instead of rewrite for redirects, try matching the path with a location block
location ~ /path/resource(.*) {
return 301 $scheme://newdomain.com/newpath/resource$1;
}
I think this way you know for sure there will be no further processing, because it's only 1 line, try it and tell me how it goes.
PS: This will maintain the $scheme of the request, requests to http:// will be redirected to a http:// and https:// will be redirected to https://