ExpressJS + serve-favicon + nginx - express

I'm having problems serving favicons with nginx as a reverse proxy in front of my express app.
Tried to search for answers but couldn't find any. My configuration file is as shown:
server {
listen 80;
server_name vogueverve.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|w$
root /var/www/hashiontag/public;
}
}
Please help! Thank you so much!

I found my answer here:
https://serverfault.com/questions/308299/how-to-set-a-favicon-ico-for-a-specific-virtual-host-on-nginx#answer-308304
Apparently, for nginx, the default is to put the favicon at the root directory, because nginx directs the clients to get favicon from www.domainname.com/favicon.ico by default.
This means that, (I think) with nginx as the reverse proxy, the favicon request never reaches the express layer, and hence it can't serve it.

Related

Get Request with Axios to Express return HTML instead of JSON - Suspecting an issue with NGINX reverse proxy set up

I am having an issue when I GET request data from my react.js app to my Express.js backend, I am getting HTML garbage back instead of what my backend is supposed to return. Upon debugging and researching, I found out that the reason for that is because my GET route "/order/getTimeSlots" actually returns HTML content that is displayed when I go to mywebsite.com/order/getTimeSlots instead of my backend. I have set up proxy in my development environment and it works, however, it does not work in production. I am using nginx to serve my react app and here is my nginx config
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/mywebsite.com;
index index.html index.htm index.nginx-debian.html;
server_name mywebsite.com www.mywebsite.com;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404;
try_files $uri /index.html;
}
location /ordersubmit {
proxy_pass http://localhost:8080; #this is where my backend app is running on
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
location /order/getTimeSlots {
proxy_pass https://localhost:8080; #this is where my backend app is running on
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
When trying curl on localhost:8080/getTimeSlots from my server console, I am getting the correct response.
I know there is a problem with my reverse proxy set up, but I cannot figure out what the issue is, so I was wondering if someone here can help
Thank you everyone
Fixed the issue myself, I realized that I was adding those locations under the server that listens to port 80, but since I am using https, I was supposed to use port 443

Nginx config for location/api

Placed frontend and backend in nginx. I'm trying to correctly configure that after authorization, nginx redirected me to the original page.
Nginx Conf:
##Frontend
server_name atlas.com;
location / {
root /ops/front_2.0/dist/;
index index.html;
}
##Backend
location /api {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
With this configuration, the backend does not work, I will not get to the authorization page and a 404 Not Found error occurs.
But if, with the same settings, you place the Backend on another domain name, for example:
server_name server.atlas.com;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
}
Then everything works fine. But such a solution does not suit me, since it is not convenient to use for Frontend, since a CORS error is raised.

Nginx Problem: Nginx adds comma and duplicate the url

I've just deployed a flask application with Gunicorn and Nginx. The application is running under 192.168.25.49 address. Nginx configured as following:
server {
listen 80;
server_name 192.168.25.49;
location / {
include proxy_params;
proxy_redirect off;
proxy_set_header host $host;
proxy_set_header X-real-ip $remote_addr;
proxy_set_header X-forward-for $proxy_add_x_forwarded_for;
proxy_pass http://unix:/home/avin/Saba/saba.sock;
}
}
The problem is: When I enter 192.168.25.49 in the address bar, it automatically changes to http://192.168.25.49,192.168.25.49/login. This problem occurs on login and logout too.
I've searched whole the internet but nothing found for this problem. If anyone with Nginx knowledge help me will appreciate.

Configuration for passing NGINX request to Express?

I'm creating a website with NGINX handling Static content, SSL and all that stuff, while my API and non-static websites are handled by Express.
Now, I'd like NGINX to pass stuff like "/update" to Express. However, I'm not sure how to configure that.
Is the example below from DigitalOcean functional for https websites in the first place? Shouldn't I configure the same SSL certificate that NGINX uses to Express, so it redirect to https://website.com/update instead of http://website.com/update?
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
Thanks in advance!
To proxy pass any API request starting with /update Example: http://localhost:3000/update, http://localhost:3000/update/test etc.. You can use below nginx config inside server block:
location /update {
proxy_pass http://localhost:3000;
}
If you want to redirect http://website.com/update to https://website.com/update . You will need to create a server at 80 port which will redirect any request that come at 80 port will be redirect to https://website.com/update
server {
listen 80;
listen [::]:80;
server_name website.com;
return 301 https://website.com$request_uri;
}

nginx location directive : authentication happening in wrong location block?

I'm flummoxed.
I have a server that is primarily running couchdb over ssl (using nginx to proxy the ssl connection) but also has to serve some apache stuff.
Basically I want everything that DOESN'T start /www to be sent to the couchdb backend. If a url DOES start /www then it should be mapped to the local apache server on port 8080.
My config below works with the exception that I'm getting prompted for authentication on the /www paths as well. I'm a bit more used to configuring Apache than nginx, so I suspect I'm mis-understanding something, but if anyone can see what is wrong from my configuration (below) I'd be most grateful.
To clarify my use scenario;
https://my-domain.com/www/script.cgi should be proxied to
http://localhost:8080/script.cgi
https://my-domain.com/anythingelse should be proxied to
http://localhost:5984/anythingelse
ONLY the second should require authentication. It is the authentication issue that is causing problems - as I mentioned, I am being challenged on https://my-domain.com/www/anything as well :-(
Here's the config, thanks for any insight.
server {
listen 443;
ssl on;
# Any url starting /www needs to be mapped to the root
# of the back end application server on 8080
location ^~ /www/ {
proxy_pass http://localhost:8080/;
proxy_redirect 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;
}
# Everything else has to be sent to the couchdb server running on
# port 5984 and for security, this is protected with auth_basic
# authentication.
location / {
auth_basic "Restricted";
auth_basic_user_file /path-to-passwords;
proxy_pass http://localhost:5984;
proxy_redirect 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-Ssl on;
}
}
Maxim helpfully answered this for me by mentioning that browsers accessing the favicon would trigger this behaviour and that the config was correct in other respects.