NGINX access logs from Single Page Application (SPA) and CMS - nginx

We have a frontend Angular app of Single Page Application and CMS design, where which is hosted in a docker container based on NGINX. The config is simply as below.
The problem is that the access log only writes logs when the whole page is refreshed and not in each user action (ie click different elements of the page).
We want to be able to log every user action, not only when the page is opened or refreshed.
We are not sure if the problem is the SPA or CMS design.
This works as expected with other pages that are designed differently.
events{}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
server {
listen 80;
server_name localhost;
root /usr/share/nginx/html;
index index.html;
location / {
try_files $uri $uri/ $uri.html /index.html;
}
}
}

Related

how to disable basic authentication when using kerberos on nginx?

Foreword
In the main body of the question, the problem is described incorrectly. The correct explanation is described in the UPDATE block. Old text saved for history.
My project consists of two parts: backend and frontend. The following locations are responsible for redirecting requests:
location / {
root /opt/site/;
try_files $uri $uri/ /index.html;
}
location /adminpanel {
proxy_pass http://192.168.1.4:4567;
}
location /api {
proxy_pass http://192.168.1.4:4567;
}
The challenge is to redirect users to url /auth if there is no user login in the $remote_user header.
I tried to make the following construction:
in http I added:
map $remote_user $var {
default 0;
"" 1;
}
And in location / added:
if ($var) {
return 301 http://$server_name/auth;
}
When I try to enter the site, I get an error in my browser:
ERR_TOO_MANY_REDIRECTS
How do I fix my configuration file?
Thanks in advance!!!
UPDATE
My task is to configure Kerberos authentication on nginx. The backend is django. The idea is that when a request is made to api, nginx should perform kerberos authentication. But in case the user is not in the domain, then a redirect to the /auth authorization page must occur, so that the user can authenticate under an account that is registered in django CMS.
Authentication of domain users is successful. But there is a problem with non-domain users. When you open a site page that makes an api call, a basic authentication window appears. I use the auth_gss_allow_basic_fallback off directive, but this does not help.
How can I disable this and configure redirection to /auth?
My configuration file (I do not specify settings such as gzip, headers, etc.):
server {
listen 80;
server_name srv-01.example.com;
proxy_set_header remote-user $remote_user;
location / {
root /opt/site/;
try_files $uri $uri/ /index.html;
}
location /adminpanel {
proxy_pass http://192.168.1.4:4567;
}
location /api {
proxy_pass http://192.168.1.4:4567;
auth_gss on;
auth_gss_realm EXAMPLE.COM;
auth_gss_keytab /etc/krb5.keytab;
auth_gss_service_name HTTP/srv-01.example.com;
auth_gss_allow_basic_fallback off;
}}

using nginx location for having a react app alongside some static pages

I have this Nginx config block
server {
listen 80;
server_name mysite.com;
#charset koi8-r;
access_log /var/log/nginx/host.access.log main;
index index.html;
location /app {
root /www;
try_files $uri $uri.html $uri/ /index.html;
}
location / {
root /www/landing;
}
error_page 500 502 503 504 /50x.html;
}
and I am having a production build of a react application at /www/app and a static Html file in /www/landing. from this configuration, I believe Nginx must redirect all the request that starts with /app (I.E: /app/home/ or /app/markets) to my react application and if the request doesn't start with /app it should try to search in /www/landing folder. This works fine when I enter mysite.com/app, and then if I try to navigate in my site using react-router itself everything works fine due to try_file. However, when I try to directly load (for example) /app/home. Nginx suddenly stops looking in /www/app and tries to load it from /www/landing which breaks everything .
My main concern here is when someone hits the refresh button in the react app.

Configure Nginx subdomains for different paths

I want to configure subdomains, so that it can accept all subdomains except admin. Currently admin is handled by other nginx configuration.
For example,I want to have ru.example.com and en.example.com to navigate to same website without redirection,and admin.example.com to navigate another website without redirection.
Here is my configuration file.
server {
listen 80;
server_name example.com www.example.com;
location / {
root /srv/www/example.com;
try_files $uri $uri/ /index.html;
}
}

Using try_files with uwsgi

I am trying to use the nginx try_files directive with uwsgi_pass and having a ton of difficulty.
Basically what I want is for try_files to ask the uWSGI container if the request URI is valid and if not, then serve up the index.html file instead. My nginx config is as follows:
server {
listen 80;
access_log /tmp/nginx.log;
location / {
try_files $uri $uri/ /index.html;
include uwsgi_params;
uwsgi_pass 127.0.0.1:5001;
}
}
But what this does is check the docroot for every request and if its not there, it simply bails and returns the index.html file.
What I want instead is the following:
Request comes in for www.myapp.com
nginx forwards this request onto the uWSGI container
If that is invalid, then return the index.html
Is there a way to 'ask' uWSGI to try the files instead?
What I'm ultimately trying to accomplish here is HTML5 Pushstate with React Router. I'm running a Flask app with a React front-end. If the user refreshes the browser at www.myapp.com/preferences/userid, then I want nginx to forward that to the container and if its invalid, to return the index.
So, after talking with #Chamindu, I realized I was probably going about this the wrong way. I prevented uWSGI from serving my index.html (even though it could) and instead relied on nginx to serve that instead.
server {
listen 80;
access_log /tmp/nginx.log;
location / {
root /var/www/myapplication/;
try_files $uri $uri/ /index.html;
}
location /api {
include uwsgi_params;
uwsgi_pass 127.0.0.1:5001;
}
}

Nginx serve static content behind authenticated page

I have created a directory call library, that requires authentication to access. Upon completing authentication I would like to list all files in library for the user. I have tried autoindex to no avail, and most material I am finding doesn't cover whether or not the authentication will affect anything.
Would appreciate any help, thanks.
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm index.php;
# Make site accessible from http://localhost/
server_name localhost;
location / {
# First attempt to serve request as file, then as
# directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
# Uncomment to enable naxsi on this location include
# /etc/nginx/naxsi.rules
}
location /website {
}
location /library {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
Your location /library block will impose the requirement of basic authentication and serve the same static files in /usr/share/nginx/html/library to all users who can successfully authenticate. In short, all users who successfully auth will see the same files in your current config.
To serve different static files to different users, consider that Basic authentication will set the $remote_user variable (see docs) which you can utilise to make your configuration dynamic.
For instance, if you wanted to serve a different folder for each user ID (at the same /library URL), you'd use a block like:
location /library {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
alias /usr/share/nginx/html/$remote_user/;
}
assuming your folders are named with the ID of your users and located at that path.
If a user fails the basic auth, they'll be shown a 403 Forbidden error, which you can handle using the error_page directive to show something more useful than just a basic error. Likewise, if a user can successfully auth and a corresponding folder doesn't exist, they'll see a 404, which you could again handle with an error_page directive.

Resources