Perfect solution to Mix-Space frontend authentication failure / comments not recognizing the owner

Preface#

I don't know if the buddies who followed my last article on building Mix-Space have encountered a problem. After you log in to the backend, the frontend is still in guest mode. At this time, you cannot post comments on your own website, just like this:

~~I don't know if you have encountered it, but I encountered it three times~~

Solution#

In the Shiro theme, you can log in directly using the following methods. I haven't tested it with Kami, so I suggest skipping it and looking at the second method.

According to the description by the developer, you only need to double-click on the avatar on the left side of the header to log in.

~~I have deleted the demonstration server when updating this method, so I just randomly found a friend's website to demonstrate~~

Then you can log in.

API and Frontend on the Same Domain#

But let's think about how this authentication works. Ah, it's very simple, it's done through Cookies. However, when we check the Cookies, we find that both the frontend and backend have the mx-token Cookie, and the values are exactly the same.

~~I know it's ineffective to blur, so you don't have to remind me~~
These days, when developing the OAuth for the member list of the train to success, I also encountered this problem. In other words, if the login API and frontend are not on the same domain, it is not possible to use Cookies across sites.
We also know that the API directory of the backend is /api/v2, so can we put the API and frontend on the same domain?

Obviously, Baota does not allow this.

Actually, the Nginx configuration file allows us to do this, so we can edit the configuration file to achieve such a cool operation like this:

The complete configuration file is as follows, replace it in the reverse proxy configuration file of the frontend site (then you can remove the reverse proxy for the backend).

# See: https://github.com/mx-space/docker/blob/master/configs/nginx.conf

# This is a example for nginx configure if you host mx-space manually
location ~* \.(gif|png|jpg|css|js|woff|woff2)$ {
  proxy_pass http://127.0.0.1:2323;
  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 REMOTE-HOST $remote_addr;
  expires 30d;
}
location ~* \/(feed|sitemap|atom.xml) {
  proxy_pass http://127.0.0.1:2333/$1;
  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 REMOTE-HOST $remote_addr;

  add_header X-Cache $upstream_cache_status;

  add_header Cache-Control max-age=60;
}


location / {
  proxy_pass http://127.0.0.1:2323;
  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 REMOTE-HOST $remote_addr;
  add_header X-Cache $upstream_cache_status;
  add_header Cache-Control no-cache;
  proxy_intercept_errors on;
}

location /api {
  proxy_pass http://127.0.0.1:2333;
  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 REMOTE-HOST $remote_addr;
  add_header X-Cache $upstream_cache_status;
  add_header Cache-Control no-cache;
  proxy_intercept_errors on;
}

location /qaqdmin {
  proxy_pass http://127.0.0.1:2333;
  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 REMOTE-HOST $remote_addr;
  add_header X-Cache $upstream_cache_status;
  add_header Cache-Control no-cache;
  proxy_intercept_errors on;
}

location /socket.io {
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_set_header Upgrade
 $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_pass http://127.0.0.1:2333/socket.io;
}