Ajaxify interfering with links outside of NodeBB

phenomlab

@yariplus @gotwf I have this working over at https://sudonix.com for the most part now, but have one remaining issue. I've setup Ghost in a subfolder (https://sudonix.com/content) which works fine when accessed directly. Blog articles are being published to NodeBB, so that works fine. Here's an example

https://sudonix.com/topic/108/changing-passwords-regularly-actually-weakens-security

However, this part

Doesn't seem to play ball. If I click the link, NodeBB tries to resolve it and I land up with the below. If I reload the page at that point, the correct blog article is then displayed.

In the console, I see https://sudonix.com/api/content/changing-passwords-regularly-actually-weakens-security?_=1637325832814 being called, which obviously isn't right as this isn't a NodeBB resource.

Here's my current NGINX config, but I don't think that this is the issue - more NodeBB behaviour I think

server {
	listen x.x.x.x;
	listen [::]:80;
	server_name www.sudonix.com sudonix.com;
	return 301 https://sudonix.com$request_uri;
	access_log /var/log/virtualmin/sudonix.com_access_log;
	error_log /var/log/virtualmin/sudonix.com_error_log;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_redirect off;
    # Socket.io Support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    gzip            on;
    gzip_min_length 1000;
    gzip_proxied    off;
    gzip_types      text/plain application/xml text/javascript application/javascript application/x-javascript text/css application/json;
}
server {
	listen x.x.x.x:443 ssl http2;
    server_name  www.sudonix.com;
	ssl_certificate /home/sudonix/ssl.combined;
	ssl_certificate_key /home/sudonix/ssl.key;
	return 301 https://sudonix.com$request_uri;
	access_log /var/log/virtualmin/sudonix.com_access_log;
	error_log /var/log/virtualmin/sudonix.com_error_log;
}
server {
	server_name sudonix.com;
	listen x.x.x.x:443 ssl http2;
	access_log /var/log/virtualmin/sudonix.com_access_log;
	error_log /var/log/virtualmin/sudonix.com_error_log;
    # Socket.io Support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    location ^~ /content {
        root /home/sudonix/ghost/;
        try_files $uri $uri @ghost;
    }
	location ^~ /content/uploads {
    alias /home/sudonix/ghost/uploads/;
	}
    location @ghost {
        proxy_pass http://127.0.0.1:2368;
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    } 
    location @nodebb {
        proxy_pass http://127.0.0.1:4567;
    	proxy_set_header X-Real-IP $remote_addr;
    	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto https;
    	proxy_set_header Host $http_host;
    	proxy_set_header X-NginX-Proxy true;
    	proxy_redirect off;
    	gzip            on;
    	gzip_min_length 1000;
    	gzip_proxied    off;
    	gzip_types      text/plain application/xml text/javascript application/javascript application/x-javascript text/css application/json;
    }
    location ~ ^/assets/(.*) {
        root /home/sudonix/nodebb/;
        try_files /build/public/$1 /public/$1 @nodebb;
        add_header Cache-Control "max-age=31536000";
    }
    location /plugins/ {
        root /home/sudonix/nodebb/build/public/;
        try_files $uri @nodebb;
        add_header Cache-Control "max-age=31536000";
    }
    location / {
        proxy_pass http://127.0.0.1:4567;
    }
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Download-Options "noopen" always;
    add_header Content-Security-Policy "upgrade-insecure-requests" always;
    add_header Referrer-Policy 'no-referrer' always;
    add_header Permissions-Policy "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()" always;
    add_header X-Powered-By "Sudonix" always;
   # add_header Access-Control-Allow-Origin "*.sudonix.com" always;
    add_header X-Permitted-Cross-Domain-Policies "none" always;
	fastcgi_split_path_info ^(.+\.php)(/.+)$;
	ssl_certificate /home/sudonix/ssl.combined;
	ssl_certificate_key /home/sudonix/ssl.key;
	rewrite https://sudonix.com/$1 break;
	if ($scheme = http) {
		rewrite ^/(?!.well-known)(.*) https://sudonix.com/$1 break;
	}
}

phenomlab

The issue i am experiencing is that NodeBB seems to process anything for /content* when it shouldn't be. Is there any way to prevent this behaviour ?

julian

@phenomlab Are you using nginx as reverse proxy? In that case, nginx should be set up to only ever direct requests to your forum, to your forum...

That's confusing, let me try again.

If your forum is forum.example.com, your nginx config should be set up to listen for requests to forum.example.com and forward them to NodeBB. For ghost, you'll set up a different server block directing requests to blog.example.com (or example.com) to ghost.

That way there's no confusion.

If you're using a subfolder things get a little harder. You'd have to proxy requests to both ghost and nodebb from within the same server block.

So it would look something like this:

server {
    location /forum {
        ... proxy stuff  for nodebb here
    }

    location /content {
        ... proxy stuff for ghost here
    }
}

The issue now seems to be that NodeBB seems to be considering requests outside of its relative path to be part of NodeBB, which is incorrect. I don't think NodeBB should do that, but it might be a bug.

Can you confirm the reverse proxy config is correct?

phenomlab

@julian It's correct, yes, as Ghost works fine. However, I've worked around this by placing ghost into https://content.sudonix.com which works fine

phenomlab

@phenomlab @julian and now the issue I have is that previously published articles that I was tested with are recorded in the MongoDB. Is there a way these can be removed ? The problem here is that Ghost and NodeBB think they have been published when in fact they have not. I guess I need to modify the DB directly, but have no idea where to start with MongoDB

I thought that perhaps uninstalling the plugin and reinstalling would strip the older entries, but this does not work.

julian

@phenomlab Now that is a harder problem to solve

Let me test to see if there's a bug with ajaxify and relative paths.

phenomlab

@julian A quick workaround would be to delete from the database and re-publish. The problem with that is I don't know how to do this - not being overly familiar with the intricate structure of MongoDB.

And, to be clear, I am now using Ghost at https://content.sudonix.com which works fine - the link to the actual article in the NodeBB post works as it should do, so it looks as though attempting to use a sibdirectory does not work owing to NodeBB's insistence that it should route that path internally

julian

@phenomlab I'm trying this locally, and the routing seems fine...

If my forum is hosted on /forum and I make a link to /test/foobar, clicking said link will attempt to open it as a new page, not internally.

What did the link structure look like on your site before you switched Ghost over to content.sudonix.com?

phenomlab

@julian See https://community.nodebb.org/post/86030 for the NGINX config.

julian

@phenomlab If you want to blow up the internal hash for blog comments, you can likely just delete the blog-comments object in Mongo. Back up your DB first, I have no idea what side-effects there will be.

db.objects.deleteMany({ _key: "blog-comments" });

That key stores the Ghost comment ID reference to the topic ID.

phenomlab

@julian Perfect. Thanks - works as intended and has allowed me to recreate the associations.

julian

@phenomlab Right, ok, I looked at the nginx config, and I can see that it is configured so NodeBB thinks it is at root level.

... which it is, which is why NodeBB thinks it owns /content and hence why it tries to ajaxify into it, because NodeBB does not expect a mounted route within NodeBB's realm of control that doesn't belong to NodeBB.

phenomlab

@julian Fair enough - no issues for me - simply cosmetic, but not essential, so content.sudonix.com works fine for me.

Thanks very much for looking into this, and providing the database command.

julian

@phenomlab You're welcome. I don't frequent this board often enough... Need to pick up the slack