2

My web application has a sub-directory, 192.168.1.8:8088/messages, that I want to expose to the outside world as messages.mysite.com. I've gotten half way there but I seem to be stuck. My requirements are as follows

  1. Redirect the site from HTTP to HTTPS.
  2. As I cannot edit the links the web application generates, I need to be able to accept requests from the client such as messages.mysite.com/messages?id=23023.
  3. Do not allow reverse proxy access to the root web application, 192.168.1.8:8088 or to any sub-directory other than 192.168.1.8:8088/messages and its children.

My current NGINX configuration has some issues.

  1. The HTTP to HTTPS redirection only works for the base path, messages.mysite.com. If an HTTP request like http://messages.mysite.com/messages?id=23023 comes in, my server redirects to http://messages.mysite.com/messages/messages?id=23023 which is incorrect. This is because I have /messages in the return 301 setting, but without it I don't know how else to redirect messages.mysite.com to 192.168.1.8:8088/messages.

  2. The HTTPS site allows access to the full web application, 192.168.1.8:8088, but I only want it to access 192.168.1.8:8088/messages.

My NGINX site configuration file is below. Any help or pointing in the right direction would be greatly appreciated.

server { listen 80; server_name messages.mysite.com; return 301 https://$server_name/messages$request_uri; } server { listen 443 ssl; server_name messages.mysite.com; set $upstream 192.168.1.8:8088; ssl_certificate /etc/letsencrypt/live/messages.mysite.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/messages.mysite.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot location / { proxy_pass http://$upstream; 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; } } 

Update for clarification:

Examples

https://messages.mysite.com => 192.168.1.8:8088/messages https://messages.mysite.com/messages?id=23023 => 192.168.1.8:8088/messages?id=23023 https://messages.mysite.com/messages/send_message => 192.168.1.8:8088/messages/send_message https://messages.mysite.com/calendar => 404 https://messages.mysite.com/notmessages=> 404 
4
  • Please clarify exact example source URL / destination URL pairs in your question in order to provide an accurate answer. Commented Aug 5, 2020 at 21:45
  • I have updated the question with examples. Thanks. Commented Aug 5, 2020 at 22:02
  • Why do you want / to go to /messages, but not /?id=23023 to go to /messages?id=23023? This looks like unnecessary complex setup. Commented Aug 5, 2020 at 22:18
  • Because the business requirement are that the base URL be messages.mysite.com and not messages.mysite.com/messages. Sadly, not my choice. As the application server includes a /messages path in the links it sends out to the clients, the clients send requests with /messages included. I need to remove the /messages the clients send as I'm already sending incoming traffic to 192.168.1.8:8088/messages via the NGINX setup. Commented Aug 5, 2020 at 22:24

1 Answer 1

3

To me it looks you are mixing up redirecting reverse proxying.

Redirecting is a server response to tell client to load another URL.

Reverse proxying is telling the server to send the request to another server and return the response back to the client.

The HTTP to HTTPS redirect should always be a simple redirect of the HTTP URL to the corresponding HTTPS URL, without modifications. There is rarely any need to modify the URL path at this step.

Therefore, your redirect block should be:

server { listen 80; server_name messages.example.com; return 301 https://$server_name$request_uri; } 

To reverse proxy requests arriving at messages.example.com to 192.168.1.8:8088/messages, use the following configuration:

server { listen 443 ssl; server_name messages.example.com; ssl_certificate /etc/letsencrypt/live/messages.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/messages.example.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot location = / { proxy_pass http://192.168.1.8:8088/messages; 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; } location /messages { proxy_pass http://192.168.1.8:8088/messages; 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; } } 

I removed the $upstream variable, because the configuration is easier to read when the location / and proxy_pass variables are next to each other.

This setup forwards requests as follows:

https://messages.example.com/ => http://192.168.1.8:8088/messages https://messages.example.com/?some=value => http://192.168.1.8:8088/messages?some=value https://messages.example.com/message => http://192.168.1.8:8088/messagesmessage 

The proxy_pass operation is documented in nginx documentation

3
  • Thank your for taking the time to explain. I was indeed conflating redirection and reverse proxying. I have implemented your change but there is still a problem. Any incoming request that has /messages needs the /messages part dropped as I am already pointing there with proxy_pass http://192.168.1.8:8088/messages. The additional /messages points the application server to the wrong place. So if the client asks for messages.mysite.com/messages/?id=3231, the application should get http://192.168.1.8:8088/messages/?id=3231 and not http://192.168.1.8:8088/messagesmessages?id=3231. Commented Aug 5, 2020 at 21:31
  • I updated the answer with a separate block for the exception you added. Commented Aug 5, 2020 at 22:29
  • 1
    That seems to be what I need. Thank you for time and patience. Commented Aug 5, 2020 at 22:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.