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

Preface#

I don't know if the buddies who followed my previous article on building Mix-Space have encountered a problem. After you log in on the backend, the frontend is still in visitor status.
At this time, you are unable to post comments on your own website as your identity, just like this:

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

Solution#

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

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.

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

Then just log in.

API and Frontend on the Same Domain#

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

~~I know it's invalid to blur, so you don't have to remind me~~
These days, when developing the OAuth for the member list of the development team, I also encountered this problem. In other words, if the login API and the frontend are not on the same domain, it is impossible 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 the 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 fancy operation like this:

The complete configuration file is as follows, replace it into 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;
}