@baris Indeed, I was logged with admin account. I tried with a regular user and it works correctly. The "Upload Image" button does not show and uploading with CTRL+V gives me the following error:

Thanks for clarifying and sorry for the misunderstanding.

Hey everyone,

Yes, it's a crazy upgrade, but I need it! I will try to be as brief as possible.

Collections in my MongoDB (2.4.8): objects, posts, search, searchpost, searchtopic, sessions
schemaDate value: 1412640000000.000000

Mongodump'ed and Mongorestore'd to another MongoDB database in MongoLab (2.6.9, therefore, textSearchEnabled=true by default).
Collections in my MongoDB (2.6.9): same as above
schemaDate value: 1392925500000.000000 - I think it's different because of some many failed attempts to ./nodebb upgrade

What I did after that:

• git checkout v0.5.x, npm install, ./nodebb setup, configured with my 2.4.8 MongoDB, node app.js - NodeBB ran normally and updated schemaDate to 1413936000000.000000
• Mongodump'ed and Mongorestore'd again to 2.6.9 MongoDB - schemaDate changed to 1413936000000.000000 in my 2.6.9 MongoDB
• git checkout v0.6.x, rm -rf node_modules, npm install, ./nodebb setup, configured with my 2.6.9 MongoDB. Received a couple messages:
  -- "No administrators have been detected, running initial user setup" - Created admin account with different username and email - Schema update complete! schemaDate: 1422576000000.000000
  -- node app.js - Success: NodeBB running normally, but many Categories disappeared from my forum (had 8, only 1 was showing). Tried to login with the admin account created above and it logged, but no admin rights. Logged out, logged with previous admin account, received Admin rights and all 8 categories were shown again. Accessed ACP > Manage > Categories and noticed that all Categories had their privileges (Find category, Access & Read, Create Topics, Reply to Topics) disabled. Enabled them all for 1 category and it started showing again. I guess this is a minor issue, so let's go back to updating to 0.7.0-dev
• git checkout origin/master (commit: 93df7f14d88bd40f88e78c5a39b04975b28b751e), rm -rf node_modules, npm install, ./nodebb setup, again configured with my 2.6.9 MongoDB. Received many warnings after the line "info: [2015/2/23] Activating NodeBB Essential Rewards"
  "warn: [plugins/nodebb-plugin-mentions] This plugin may not be compatible with your version of NodeBB. This may cause unintended behaviour or crashing." - Same message for other 4-5 plugins: nodebb-theme-lavender, nodebb-plugin-soundpack-default, nodebb-rewards-essentials
  -- Error after line "info: [2015/02/24] Upgrading plugins:active to sorted set done"

C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\lib\utils.js:97
    process.nextTick(function() { throw err; });
                                        ^
TypeError: Cannot read property 'length' of undefined
    at Object.async.eachSeries (C:\Users\X\Desktop\openshift\NodeBB\node_modules\async\lib\async.js:141:17)
    at C:\Users\X\Desktop\openshift\NodeBB\src\upgrade.js:903:13
    at C:\Users\X\Desktop\openshift\NodeBB\src\database\mongo\main.js:103:4
    at handleCallback (C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\lib\utils.js:95:12)
    at C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\lib\collection.js:763:5
    at C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\replset.js:371:5
    at C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\server.js:795:13
    at Callbacks.emit (C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\server.js:94:3)
    at null.messageHandler (C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\server.js:235:23)
    at Socket.<anonymous> (C:\Users\X\Desktop\openshift\NodeBB\node_modules\mongodb\node_modules\mongodb-core\lib\connection\connection.js:259:22)

-- Ignored error. Checked schemaDate: 1424736000000.000000, therefore, it got updated.
-- Tried running NodeBB and I was told to ./nodebb upgrade. Did it, received message: Schema update complete!
-- Tried running again, node app.js - Success - Checked schemaDate: 1431302400000.000000
-- Opened the forum and noticed my HTML Widget at the top was missing. Logged with old admin account - had Admin rights normally. Opened ACP and changed theme to Persona - Worked just fine
-- Investigated Widget issue. ACP > Extend > Widgets and no widgets were found, however, I'm stuck with a light-blue empty div on the top of my NodeBB forum.

The funny thing is that I wrote this post while testing everything on my side and expected it to fail because yesterday I tried the same steps and the outcome was quite different: I didn't even manage to run 0.7.0-dev. So yeah, I guess I could just erase all my post and just leave the "light-blue div issue", but I think my use case might be useful for someone. If not, feel free to edit my post.

Anyways, that's basically the entire process that I went through. I will keep investigating the light-blue widget and post here if I managed to remove it. Other than that, all I can say is that you guys did an amazing job with NodeBB and... Persona theme is cute (one of the reasons why I updated everything lol)

Regards!

Yep.

/10chars

Hey everyone,

My question is very specific: is it possible to hide sensitive data when composing/editing a post? I have a NodeBB forum where people may post some private information, but the content of the post itself is relevant to other users, so I don't want to hide it completely: only certain information, which will be shown only for administrators.

Example: to integrate some SDK, a user requires an ID, but this user is having issues with the integration. Then he creates a post with his logs, asks for help and those logs contain his ID and other stuff. While the user can hide his own ID, I want that ID to not be shown at all for regular users/guests, but show normally for administrators, since we can track his bug easier with his ID. That's more or less the use case.

Do you guys know if there's a plugin or markdown command that does this?

Regards!

My forum is getting spammed on /login by more than 8000 computers. The normal daily traffic is about 500-600 unique computers.

The requests are only hitting /login. A GET request is first sent and then 10-15s later a POST request with some dictionary credentials. My instance is a t2.micro on AWS and it's suffering a lot in terms of CPU usage.

At this moment, I'm monitoring all requests in my plugin and then enabling a WAF rule that blocks all requests to /login. I'm also automatically banning the IPs in WAF that only send requests to /login because in theory there should be requests to other endpoints, like /assets, /categories, etc.

I'm mainly using WAF because it prevents the request from hitting the instance/nginx, therefore, it saves a lot of CPU. I've got 2 questions:

1 - Is it possible to "easily" change the /login endpoint to some other random string? The attacker could just look for the new endpoint and change the attack, but I believe this attack is coming from random bots that are simply checking if /login is valid, i.e., doesn't return 404. By changing the endpoint, I could just enable the WAF rule blocking /login and then the legit forum users wouldn't be affected.

2 - Is it normal for a password check with bcryptjs to be somewhat CPU intensive? I've noticed that whenever a regular user logins or the dictionary attack finds a valid username (but not the password), then the CPU usage increases considerably.

Awesome! It worked for me and indeed, there's no delay. Also, to hide the views in the post bar, I used this one:

.topic-main-buttons .stats:nth-child(3) * {
  /* to maintain formatting */
  visibility: hidden;

  /* to hide completely instead */
  /*display: none;*/
}

Thanks a lot!

My forum is getting spammed on /login by more than 8000 computers. The normal daily traffic is about 500-600 unique computers.

The requests are only hitting /login. A GET request is first sent and then 10-15s later a POST request with some dictionary credentials. My instance is a t2.micro on AWS and it's suffering a lot in terms of CPU usage.

At this moment, I'm monitoring all requests in my plugin and then enabling a WAF rule that blocks all requests to /login. I'm also automatically banning the IPs in WAF that only send requests to /login because in theory there should be requests to other endpoints, like /assets, /categories, etc.

I'm mainly using WAF because it prevents the request from hitting the instance/nginx, therefore, it saves a lot of CPU. I've got 2 questions:

1 - Is it possible to "easily" change the /login endpoint to some other random string? The attacker could just look for the new endpoint and change the attack, but I believe this attack is coming from random bots that are simply checking if /login is valid, i.e., doesn't return 404. By changing the endpoint, I could just enable the WAF rule blocking /login and then the legit forum users wouldn't be affected.

2 - Is it normal for a password check with bcryptjs to be somewhat CPU intensive? I've noticed that whenever a regular user logins or the dictionary attack finds a valid username (but not the password), then the CPU usage increases considerably.

My plugin does a lot of caching that I want to save before the server restarts/crashes. Re-building this cache causes high CPU usage for like 30min-1h on my t2.micro so I'm using fs.writeFileSync + JSON.stringify upon process exit and then fs.readFile + JSON.parse when it initializes in order to avoid rebuilding the cache.

I thought NodeBB offered a hook on shutdown, but I guess I can use process.on("exit").

Is there a NodeBB hook that I could use to execute certain synchronous operations when the forum is restarting or even crashing?

I already use the hooks static:app.load and static:app.preload so I guess I'm looking for a static:app.unload.

Right now I'm using process.on("exit") which seems to do what I want, but apparently it is executed after NodeBB has already closed all connections:

2019-11-10T14:58:34.617Z [8081/17108] - info: [app] Shutdown (SIGTERM/SIGINT) Initialised.
2019-11-10T14:58:34.784Z [8081/17108] - info: [app] Web server closed to connections.
2019-11-10T14:58:34.787Z [8081/17108] - info: [app] Live analytics saved.
2019-11-10 14:58:34:807 -  server.js:71:5) -  socketCleanup close 81.165.Y.X:33352 Total 10 > myplugin
2019-11-10 14:58:34:809 -  server.js:71:5) -  socketCleanup close 108.41.Y.X:33300 Total 9 > myplugin
2019-11-10 14:58:34:811 -  server.js:71:5) -  socketCleanup close 81.165.Y.X:33284 Total 8 > myplugin
... 
2019-11-10 14:58:35:685 -  server.js:71:5) -  socketCleanup close 123.186.Y.X:58106 Total 1 > myplugin
2019-11-10 14:58:35:685 -  server.js:71:5) -  socketCleanup close 123.186.Y.X:58066 Total 0 > myplugin
2019-11-10T14:58:35.705Z [8081/17108] - info: [app] Database connection closed.
2019-11-10T14:58:35.708Z [8081/17108] - info: [app] Shutdown complete.
2019-11-10 14:58:35:708 -  app.js:260:5) -  process.on("exit") with code: 0 > myplugin

Apparently it looks at the users:online key instead of the lastonline field of each uniqueuser.

It seems there is some discrepancy between the two which is causing these wrong results. Maybe my server was having issues...

I'm using NodeBB 1.11.1 on AWS. When I check for users that have been inactive for longer than 5 months, I get some results that do not fit my query, i.e., the user actually was online recently. Is this a bug?

I'm using NodeBB 1.11.1 and I would like to delete all users that have been inactive for longer than 1 year:

The feature above works fine, but it only shows 50 results per page. I've got about 10 pages so I need to click the top-left checkbox for each page and then click "Delete user(s) and content".

Is there a faster way to do this? Simply showing more results would be handy.

Yep.

/10chars

With the viewcount, I found the topic in my database:

{
    "_id" : ObjectId("5b0e1c4390dcefcd0d0bd012"),
    "_key" : "topic:107",
    "viewcount" : 810
}

Then I deleted the document and it also disappeared from my category.

Yeah, no luck. The topic is still there.

One of my categories has the following topic:

When I try to delete it, I receive the following error:

In the HTML, the topic is shown with ID 0:

It feels like some user was about to post something and then the server restarted/crashed or whatever.

How do I delete this topic? I've searched for a _key: "topic:0", but there aren't any documents.