@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:
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!
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!
Thanks for the clarification. No need to answer my questions.
When the server is on heavy load, other node processes are spawned:
In the example above, I was running with node app.js so I didn't have NodeBB's daemon running, i.e., I didn't run with nodebb start. So yeah, 2 other processes were spawned.
1 - Is this done by EC2 or by NodeBB?
2 - Do the other new processes load custom plugins as well? If yes, how can I make my custom plugin only load for 1 process?
3 - Is it possible to disable this behavior/feature?
Because of this commit, it's not possible delete events anymore. As I explained in this post, I run NodeBB on a Sandbox MongoDB with 512MB so I'm always doing some database maintenance to make sure I don't hit the limit.
I've got 2 questions:
1 - Is it safe to delete the events: and event: keys?
2 - Why was the "Delete events" button removed?
My NodeBB plugin exposes a webhook where I receive requests from another service that I don't have control over. This service sends a POST request that contains a header which is an HMAC-SHA256 hash of the raw BODY, where the key is provided by this service directly in my account.
Right now in NodeBB v1.13.1, the only way that I found to retrieve this raw BODY is by directly modifying src/webserver.js by adding the following before configureBodyParser(app):
app.use('/webhook', bodyParser.text({ type: '*/*' }));
Is there a better way of doing this without modifying NodeBB's source code?
I had 900k documents in my objects database. After running the following, I now have 300k documents and mLab only shows 131MB:
db.objects.remove({_key: "ip:recent"})
db.objects.remove({_key: {$regex: /^analytics*/})
Thank you so much!
I have a Sandbox MongoDB and I'm almost reaching the 512MB limit. The objects collection currently has 291MB according to mLab's dashboard, but when I run my code to calculate the size of all documents grouped by keys, I get 97MB:
TotalSize 97127973
[ { size: 27893209, key: 'ip:recent' },
{ size: 3589893, key: 'analytics:uniquevisitors' },
{ size: 3397240, key: 'analytics:pageviews' },
{ size: 2156448, key: 'analytics:pageviews:byCid:2' },
{ size: 2076103, key: 'analytics:errors:404' },
{ size: 2006251, key: 'analytics:pageviews:byCid:11' },
{ size: 1570818, key: 'analytics:pageviews:byCid:13' },
{ size: 1477344, key: 'analytics:pageviews:byCid:5' },
{ size: 1361395, key: 'analytics:pageviews:byCid:15' },
{ size: 1113792, key: 'analytics:pageviews:byCid:1' },
{ size: 1050995, key: 'analytics:pageviews:byCid:16' },
{ size: 1035648, key: 'analytics:pageviews:byCid:6' },
{ size: 1022688, key: 'analytics:pageviews:byCid:3' },
{ size: 844767, key: 'analytics:pageviews:registered' },
{ size: 806802, key: 'analytics:pageviews:guest' },
{ size: 752544, key: 'analytics:pageviews:byCid:4' },
{ size: 646116, key: 'analytics:pageviews:bot' },
{ size: 638890, key: 'group:registered-users:members' },
{ size: 624893, key: 'email:sorted' },
{ size: 570543, key: 'username:sorted' },
{ size: 569470, key: 'email:uid' },
{ size: 528288, key: 'users:joindate' },
{ size: 515562, key: 'users:notvalidated' },
{ size: 514863, key: 'users:online' },
{ size: 514790, key: 'users:reputation' },
{ size: 514677, key: 'username:uid' },
{ size: 514671, key: 'userslug:uid' },
{ size: 510899, key: 'analytics:pageviews:byCid:19' },
{ size: 508116, key: 'users:postcount' },
{ size: 470256, key: 'analytics:pageviews:byCid:21' },
{ size: 422241, key: 'analytics:pageviews:byCid:17' },
{ size: 402841, key: 'analytics:pageviews:byCid:22' },
{ size: 296016, key: 'analytics:posts' },
{ size: 265932, key: 'analytics:errors:503' },
{ size: 242494, key: 'posts:pid' },
{ size: 238523, key: 'analytics:pageviews:byCid:20' },
{ size: 135731, key: 'tid:1172:bookmarks' },
{ size: 134130, key: 'analytics:topics' },
{ size: 133489, key: 'uid:1:tids_read' },
{ size: 121778, key: 'tid:615:bookmarks' },
{ size: 117208, key: 'analytics:posts:byCid:2' },
{ size: 90287, key: 'tid:415:bookmarks' },
{ size: 80986, key: 'uid:472:tids_read' },
{ size: 78450, key: 'tid:1206:bookmarks' },
{ size: 69259, key: 'tid:1334:bookmarks' },
{ size: 67261, key: 'tid:540:bookmarks' },
{ size: 64879, key: 'tid:1282:bookmarks' },
{ size: 63157, key: 'tid:1032:bookmarks' },
{ size: 62433, key: 'cid:2:pids' },
{ size: 61880, key: 'uid:453:tids_read' },
{ size: 60052, key: 'uid:2247:tids_read' },
{ size: 55094, key: 'tid:1335:bookmarks' },
{ size: 53289, key: 'analytics:posts:byCid:15' },
{ size: 50034, key: 'analytics:topics:byCid:2' },
{ size: 49931, key: 'topics:recent' },
{ size: 48765, key: 'tid:1576:bookmarks' },
{ size: 48706, key: 'uid:2261:tids_read' },
{ size: 48428, key: 'uid:3478:tids_read' },
{ size: 48344, key: 'topics:tid' },
{ size: 47591, key: 'topics:posts' },
{ size: 47525, key: 'tid:1076:bookmarks' },
{ size: 47058, key: 'analytics:posts:byCid:11' },
{ size: 46948, key: 'topics:views' },
{ size: 46177, key: 'tid:1154:bookmarks' },
{ size: 45983, key: 'uid:447:tids_read' },
{ size: 44066, key: 'uid:2622:tids_read' },
{ size: 43551, key: 'tid:1095:bookmarks' },
{ size: 42209, key: 'posts:votes' },
{ size: 41479, key: 'uid:0:posts' },
{ size: 38412, key: 'uid:1914:tids_read' },
{ size: 37808, key: 'uid:484:tids_read' },
{ size: 37254, key: 'uid:4016:tids_read' },
{ size: 36394, key: 'uid:0:tids_read' },
{ size: 34891, key: 'tid:1524:bookmarks' },
{ size: 34785, key: 'uid:1:sessionUUID:sessionId' },
{ size: 34686, key: 'analytics:topics:byCid:15' },
{ size: 34350, key: 'cid:21:pids' },
{ size: 33387, key: 'analytics:posts:byCid:21' },
{ size: 32650, key: 'tid:1442:bookmarks' },
{ size: 32461, key: 'cid:11:pids' },
{ size: 31518, key: 'tid:1541:bookmarks' },
{ size: 30799, key: 'uid:1:posts' },
{ size: 30318, key: 'analytics:posts:byCid:17' },
{ size: 30068, key: 'cid:15:pids' },
{ size: 30035, key: 'tid:1601:bookmarks' },
{ size: 29180, key: 'uid:2005:tids_read' },
{ size: 29128, key: 'events:time:user-delete' },
{ size: 29003, key: 'tid:473:bookmarks' },
{ size: 28260, key: 'cid:5:pids' },
{ size: 28171, key: 'uid:862:tids_read' },
{ size: 27981, key: 'post:1485' },
{ size: 27816, key: 'events:time' },
{ size: 27271, key: 'tid:1525:bookmarks' },
{ size: 27091, key: 'uid:647:tids_read' },
{ size: 26844, key: 'tid:1705:bookmarks' },
{ size: 26842, key: 'tid:1718:bookmarks' },
{ size: 26227, key: 'tid:1546:bookmarks' },
{ size: 25200, key: 'tid:1172:posts:votes' },
{ size: 25073, key: 'uid:1008:tids_read' },
{ size: 24890, key: 'uid:6111:tids_read' },
... 77671 more items ]
1 - Is it safe to delete the ip:recent and analytics keys?
2 - Why does mLab show 291MB while my code finds 97MB? I suppose the size in the disk doesn't have anything to do with the size calculated using the BSON module. Here's the code that I use on the objects collection:
var bson = require('bson')
function getLargestDocumentsDB(db, callback) {
_DB.collection(db).find().toArray(function (err, data) {
var totalSize = 0
if (data && data.length) {
var BSON = new bson()
data.forEach(function (obj) {
var size = BSON.calculateObjectSize(obj)
totalSize += size
})
}
callback(totalSize)
})
}
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] - [32minfo[39m: [app] Shutdown (SIGTERM/SIGINT) Initialised.
2019-11-10T14:58:34.784Z [8081/17108] - [32minfo[39m: [app] Web server closed to connections.
2019-11-10T14:58:34.787Z [8081/17108] - [32minfo[39m: [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] - [32minfo[39m: [app] Database connection closed.
2019-11-10T14:58:35.708Z [8081/17108] - [32minfo[39m: [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...