The loop to add buttons was merged into persona. A similar addition should probably be added to vanilla.

I now add buttons in my plugin via hook filter:post.getPosts and in the hook:

  Plugin.postsBuild = function(params, cb) {
    var histButton = {action: 'posts/edithistory', icon: 'fa-file-text', html: 'Edit History'};

    async.map(params.posts, function(post, next) {
      if(!post) return next();

      if(!!post.tools) {
        post.tools = [];
      }
      post.tools.push(histButton);

    });

    cb(null, params);
  };

here's a PR to take care of it--

https://github.com/NodeBB/nodebb-theme-persona/pull/158
https://github.com/NodeBB/NodeBB/pull/3604

Hey, I feel like I'm missing something but is there currently no method to have a plugin add a button to a post?

partials/topic/post-menu.tpl pulls data from a posts object defined here -- so that's where I guess a filter:posts.build would go, and then we'd add something similar to regFormEntry to the partial.

It feels sorta inefficient to do that for every single post but I guess that's what needs to be done? Am I missing something somewhere?

Redis is just as reliable as mongo and can be backed up to a different server just as easily, above.

No, redis is only installed if you set it to use redis in setup.

@xCausxn There aren't any very good websocket mapping webscanners/tools, the only real option is intercepting each websocket transmission in burp and testing each one. From this I'd assume nobody has really bothered testing all the routes for security purposes.

The NodeBB team will patch security issues reported in the middle of the night in like 15 minutes, so they've got a great security posture.

From a permissions and logging standpoint NodeBB doesn't really step up to the plate. It's likely that if someone compromised your forum you'd have absolutely no helpful logs to detect the attacker or how they got in. This is probably the biggest security concern at the moment I'd say. The permissions system is a little haphazard right now, and I'd wager it is the most likely place you'd find security vulns(but more than likely it'd just be viewing information you shouldn't).

Luckily, if your forum was compromised, user passwords wouldn't really be too at risk. They use a secure hashing algorithm with automatic salts(you'll notice logging in takes a second!). This is because generating that hash is computationally expensive, a good thing.

That's great, I am actually working on pretty much the same thing (semantic-ui, but with everything designed to be more friendly to old-style forum users).

I add semantic-ui as a submodule git submodule add and have a script to handle compilation / then copy the results to the lib and less (even though it is CSS) folders.

I didn't encounter your LESS issue because I'm not throwing everything out just yet, but try running grep -r "state-info-text" ./* to find the culprit.

I was thinking of making this plugin if nobody's already done so. Would just need to observe filter:post.save and purge to remove the history entries. It'd be nice to store just the diffs to save space, if there's already a library to handle diff->json and json back to applying a diff.

One concern I'd have is being able to display an edit history gui for a post that is theme agnostic. Not sure there's a way to do that? A modal with custom styling might be the best option in that case.

So when a page loads, vanilla will fade the contents in. I've looked pretty hard -- does anyone know where this is at? A loading bar/popin is way better, so I was going to fork and pull that out of lavender.

"IP Blacklist" as in a spam/malware blacklist. These are lists that security-conscious owners would naturally block, but occasionally contain innocent infected users.

@Peter-Zoltan-Keresztes said:

Why don't you do that on firewall level. If you don't want to add rules manually try fail2ban

Here's a UX example: What if someone's on an IP blacklist? Timing out their connection to the site is a terrible UX compared to a static page saying they are IPbanned.

So there's obviously something getting lost in translation here... I work in security, I know how proxies and botnets work very well.

@a_5mith said:

Reloading nginx is something that can be worked around, and only happens say, once every now and then.

Not if I've got a net of 20k coming at you. I can stagger them so that your reloads alone(if automated) interrupt service for users for a significant period of time or cause significant annoyance.

Modern proxies (including free ones) are very good at getting a new IP address. Failing that, disconnecting and reconnecting would also get you a new IP address on software based proxies (VPNs etc)

So, the modern internet has the concept of "IP Blacklists." You are not going to find a proxy quickly that is not already on one of these lists. VPNs have a very limited pool of addresses that they pull from.

Not that this matters to any remotely sophisticated attacker: their proxy lists will be from a botnet they control(still going to be a fairly limited pool), or a scan of a large swath of the ipv4 address space that they performed at an earlier time(prob < 1k working from this). The average kid you'd IP ban doesn't have access to this kind of thing, though.

Automated attacks are slightly different, it depends on the attack, if it's one user being a nerd, then I would IP ban them in nginx. If it's a ddos attack, then there's no way I could prevent this using software as by the time theyd reached the software, the connection would already be bottle necked and the best course of action at that point would be damage control. Not prevention.

So ddos is a terrible generic term. It can mean a LOT of things.

The case you described is a bandwidth based DDoS which is actually sorta rare when it comes to them(solutions like cloudflare help prevent bandwidth-based and other simple DDoS methods very well).

The type of DoS that nothing but the application can help you with will take advantage of requests that trigger slow-running or resource intensive code paths. It turns out there's a lot of these and really no external tools that can help you in a websocket-based application. This kind of DoS can be done via a single IP at a time as they don't usually take a lot of bandwidth (of course if you ban one IP it's trivial to automate having another bot continue the attack). They are not complex attacks.

You've got to look for these and stop them at the application layer. This is done via behavioral/attack pattern analysis. If you know a certain code path will easily DoS your site, you can block these attacks via code -- it's very simple. If the software doesn't give you an easy way to programmatically ignore traffic from a certain address/range, you're sort of left to ratelimit everyone(which sucks).

This is just one kind of attack. IP banning applies to a myriad of attacks and is really something necessary for the application to be able to do.

@a_5mith said:

I would always recommend banning using nginx or Apache. Making the software handle who's ip banned is an unnecessary use of resources when deny from IP is so quick and simple. Its a waste of a socket connection in this case.

Is there a way to deny from IP in nginx that doesn't require a config reload? That's a pretty resource-intensive operation.

I could obtain a new IP address faster than you could ban it in most cases.
Etc. Annoy them enough, they'll leave. Basically.

So, the reasoning behind making this functionality is not so much to handle getting rid of mean forum posters who might register new accounts(the time taken to scan for ipv4 proxies and register and make a post would definitely be greater than the time taken to click a "nuke user" button on their post, though).

Automated attacks exist that can be detected very easily programmatically -- and an IP ban issued to stop them. If I have a botnet open socket requests in a specific pattern to your site, it will DoS it pretty easily with very little bandwidth used. Are you going to iptables/proxy ban each of those IPs by hand as they come? It would be a simple matter to have a plugin listen on this functionality and trigger IPbans when an obvious attack is detected.

also I'd hope whatever functionality for IPbanning would not even allow them to open a socket -- serve them some junk static html.

So, you've programmatically identified a malicious request from an IP address. How do you blacklist them to prevent them from crawling/scanning/etc the rest of the site? Just notify the admin that there's a bad IP and make them go ban them by hand?

• Use iptables
  • Requires root privileges to add an entry. Bad thing to give to software.
• Add them to some blacklist in your proxy.
  • Different depending on the proxy used. Easy but high-impact in nginx(do include /opt/nodebb/blacklist.conf in nginx.conf, add deny 1.2.3.4; for each blocked user, reload nginx after each add)
    • potentially suitable to be a plugin? managing it similar to the emailer would allow other plugins to trigger IP bans in a common way regardless of the IPbanner used.
• Build in some nodebb functionality to drop their requests.
  • Wouldn't depend on the environment.
  • Is there still some performance impact to the site if they're sending many requests and nodebb is handling blocking them?

In my eyes this functionality must be provided in some way to legitimize using NodeBB for large environments. It's too tedious to ask administrators to handle banning IPs by hand.

Yeah, events.js seems like it should contain the functionality for this. It currently only logs UID, but a lot of those functions should probably log the IP of the triggering party as well.

It seems like the only way to do that is to have IP be a parameter for most of those calls. That's a little tedious.

my fantasy: events are logged to the db as well as flatfile, have severity/importance levels, contain as much info as possible about who triggered it if the logging fn is passed a socket or request object, there's hooks for events of high severity, by default sends email or notification to admins when high-sev occurs

So, there are certain events which should definitely be logged for administrative review. For example, if my plugin detects a socket request that seems maliciously invalid, it should be logged.

Right now I'm using winston.error and dumping the socket info / specific error info.

Is this correct? Should there be some other logging mechanism for potential attacks/malicious users? Ideally any time something like that occurs, the IP of the attacker should be dumped to the log.

To be clear, we can still access relative_path through nconf.get('relative_path') right? -- this just affects people that may be accessing this stuff before it's parsed into that.

I'd like to chime in that the category management view right now definitely needs UX improvements, 300 categories or not. A tree view that starts with all the options collapsed might be decent. Collecting everything into boxes based on parents may work well. All in all, each cat needs to take up less screen space by default.

@julian said:

Markdown listens on priority 5, listen on 6 or 4 if you want to handle links before or after (though for the life of me I can't remember which is which).

listening on a lower priority and adding HTML will result in the HTML being escaped by the markdown plugin on 5. listening on 5 or greater -- or not specifying a priority, results in your plugin seeing link HTML in many varied cases.

the issue is pretty much certainly not related to this thread though. youtube-lite seems to work fine, I'm sure there is some trick to this in there.

@BDHarrington7 yeah, I'm trying to update his gfycat plugin to work. I have no idea how his youtube-lite plugin catches links before they're linkified, but this does not. It seems like they're functionally the same.

https://github.com/dwendt/nodebb-plugin-gfycat