i have an EC2 instance on AWS that i have deployed a MERN stack on, i have defined nginx as follows:
server {
#listen 80;
listen 80 default_server;
listen [::]:80 default_server;
server_name yourdomain.com;
access_log /home/ubuntu/client/server_logs/host.access.log main;
client_max_body_size 10M;
location /api/ {
add_header X-debug-message innnnnnnnnnnnnn;
proxy_pass http://localhost:3000/;
}
location /admin-dashboard {
root /home/ubuntu;
index index.html;
add_header X-uri "$uri";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
}
location / {
root /home/ubuntu/client/deploy;
index index.html index.htm;
try_files $uri $uri/ /index.html;
add_header X-uri "$uri";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
}
location = /49x.html {
root /usr/share/nginx/html;
}
server_tokens off;
location ~ /\.ht {
deny all;
}
}
And i have attached the security groups as an screenshots.
when i tried to fetch data with this url http://clikjo.com/api/ , using browser or postman it works perfectly, but when i try it using javascript with fetch or Axios it fails with this error:
[TypeError: Network request failed]
can anybody solve my problem?
i have tried to:
change my security groups
add headers, specify mode , fetch options , ... etc
If you load a page in your browser using HTTPS, the browser will refuse to load any resources over HTTP. As you've tried, changing the API URL to have HTTPS instead of HTTP typically resolves this issue. However, your API must not allow for HTTPS connections. Because of this, you must either force HTTP on the main page or request that they allow HTTPS connections.
Note on this: The request will still work if you go to the API URL instead of attempting to load it with AJAX. This is because the browser is not loading a resource from within a secured page, instead it's loading an insecure page and it's accepting that. In order for it to be available through AJAX, though, the protocols should match.
You are getting CORS error.
You need to fix it on server-side with additional header.
add_header Access-Control-Allow-Origin *;
Related
I have cache set for accessing to images
proxy_cache_path /cache/images-cache/ levels=1:2 keys_zone=media:1m inactive=365d max_size=500m;
also I have nginx set
server {
server_name localhost;
listen 80;
location ~ "^/(?<id>.+)/(?<width>)/(?<height>)/(?<image>.+)$" {
proxy_pass http://localhost:8888;
proxy_cache media;
proxy_cache_valid 200 365d;
proxy_cache_key $width-$height-$image;
}
How can I set logging so it shows which images are fetched from cache?
You can add a response header
add_header X-Cache-Status $upstream_cache_status always;
This will enable you to check if the URL was hit or not.
https://nginx.org/en/docs/http/ngx_http_upstream_module.html
You can also use this variable $upstream_cache_status in your logs if you want to generate metrics or persist them in the logs.
Follow the example here
https://rtcamp.com/tutorials/nginx/upstream-cache-status-in-access-log/
and add/remove other variables at your convenience.
some images on nginx server getting error 403 forbidden.
for example if upload files with name test.png everything is fine, but if upload file with name Screen Shot 2022-05-27 at 15.01.42.png i'm getting error 403 forbidden.
location ~ ^/srv/files/(.+\.(svg|png|jpg|jpeg|otf|eot|svg|tiff|psd|raw|mp4|pdf))$ {
alias /srv/files/$1;
error_log /var/log/nginx/srv.error.log debug;
access_log /var/log/nginx/srv.access.log main;
# access_log off;
expires 1d;
add_header Cache-Control "public";
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" always;
I needs to enable cors policy to reach to my api, i did the following configuration on my nginx server file:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name api.domain.com;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_pass http://my_ip:6869/;
set $ref "*";
if ($http_referer ~* ^(http?\:\/\/)(.*?)\/(.*)$) {
set $ref $1$2;
}
add_header 'Access-Control-Allow-Origin' $ref always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,signature,timestamp' always;
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/api.domain.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/api.domain.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
But i keep getting the following error:
Access to fetch at 'https://api.domain.com/data/key?matches=^art(.*)' from origin 'http://localhost:3500' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains multiple values '*, http://localhost:3500', but only one is allowed. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
It seem that the add_header is adding on top of an already set header for Access-Control-Allow-Origin * but i only have this config file and don't see anywhere else where it could come from.
Is there a way to figure out what is setting the initial header cors policy or simply override it instead of adding to it?
Thank you in advance.
This happens if you haven't set up CORS configuration correctly.
you can fix this on you'r local machine using a plugin/extension called Allow-Control-Allow-Origin and add you'r localhost into it.
The other way is to manually fix the configuration in server side.
if you are not familiar with CORS it basically used to allow some cross-origin requests while rejecting others. For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions.
Update
Which compiler are you using for Nginx? If it's this one the following code must fix it:
location ~* \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
I'am trying to set up basic caching in my openresty nginx webserver. I have tried milion different combinations from many different tutorials, but I can't get it right. Here is my nginx.conf file
user www-data;
worker_processes 4;
pid /run/openresty.pid;
worker_rlimit_nofile 30000;
events {
worker_connections 20000;
}
http {
proxy_cache_path /tmp/nginx/cache levels=1:2 keys_zone=cache:10m max_size=100m inactive=60m;
proxy_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;
include mime.types;
default_type application/octet-stream;
access_log /var/log/openresty/access.log;
error_log /var/log/openresty/error.log;
include ../sites/*;
lua_package_cpath '/usr/local/lib/lua/5.1/?.so;;';
}
And here is my server configuration
server {
# Listen on port 8080.
listen 8080;
listen [::]:8080;
# The document root.
root /var/www/cache;
# Add index.php if you are using PHP.
index index.php index.html index.htm;
# The server name, which isn't relevant in this case, because we only have one.
server_name cache.com;
# Redirect server error pages to the static page /50x.html.
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www/cache;
}
location /test.html {
root /var/www/cache;
default_type text/plain;
try_files $uri /$uri;
expires 1h;
add_header Cache-Control "public";
proxy_cache cache;
proxy_cache_valid 200 301 302 60m;
}
}
Caching should work fine, there is nothing in error.log or access.log, caching system folder is empty, X-Cache header with $upstream_cache_status is not even showing, when I get headers from curl (curl -I). Now in my nginx (openresty) configuration there is no --without-ngx_http_proxy_module flag so the module is there. I have no idea what am I doing wrong please help.
You didn't define anything that can be cached: proxy_cache works togeher with proxy_pass.
The add_header defined inside the http block will be covered the one defined in the server block. Here is the snippet from the document about add_header
There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.
If the always parameter is specified (1.7.5), the header field will be added regardless of the response code.
So you cannot see the X-Cache header as expected.
What was (could be) the rationale behind Nginx's decision to only inherit add_header statements from the lowest level that has any?
For instance:
server {
server_name example.com;
root my/root;
listen 443 ssl;
ssl_certificate my.cert;
ssl_certificate_key my.key;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload" always;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy: default-src 'self' https:;
location ~* \.(gif|jpeg|jpg|png|css|js|ico|txt)$ {
add_header Cache-Control "public, max-age=86400";
}
}
None of those security-related headers are added to the assets which match the location block, dedicated to increasing cache time, just because it adds another header.
The fix would be to duplicate all add_header directives into the block which seems counter intuitive to how the rest of Nginx works, e.g. the root directive.
The behaviour is documented here:
There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.
http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
I guess there is a good explanation and I'm curious about what it is.