Forum Administrators
Apparently the last time there was this much snow in Toronto was 1951, back when "bulletin boards" were just things you stuck push-pins into. Times sure change! But one thing that won't change is our ongoing efforts to make NodeBB the best forum software out there.
Under the hood are tons of changes to improve NodeBB, but here are some of the bigger ones we wanted to highlight...
Click here to see the full blog post
Not easily, as /login is hardcoded in a couple places in the codebase. To combat these types of attacks, we introduce a delay when logging in that somewhat matches the bcrypt runtime. You could always edit the codebase to increase the delay some more, but what I'd recommend is setting up spam-be-gone so these requests are curbed before it hits bcrypt.
Yes. bcrypt is processor intensive by design (that's what makes it so good as a password hashing algorithm, but I am no expert).
@gotwf said in Plugin idea: emailrep.io:
Which seems to be nodebb's approach in general w.r.t. stuff like this
In general, yes. We try to not muck around with existing installs too much, but plugins are a little more fast and loose with things like this. Will keep it in mind 
Looks OK to me did you put a console.log here to see if the groups and privileges are correct? Did you check the database directly to see if the change happened?
Hi @sazulo,
Since your plugin hook function is async you should not use the callback and just return strategies from the function.
Change your function to the below and it should work.
OpenIDConnectPlugin.getStrategy = async function (strategies) {
try {
if (!OpenIDConnectPlugin.config.enabled) {
return strategies;
}
OpenIDConnectPlugin.issuer = await Issuer.discover(OpenIDConnectPlugin.config.discoverUrl);
const strategy = new Strategy({
client: new OpenIDConnectPlugin.issuer.Client({
client_id: OpenIDConnectPlugin.config.clientId,
client_secret: OpenIDConnectPlugin.config.clientSecret,
redirect_uris: [nconf.get('url') + AUTH_OIDC_CALLBACK_PATH],
}),
params: {
// In OpenID Connect,
// => issuer and subject in the 'openid' scope
// => email in the 'email' scope
// => username in the 'profile' scope ( as 'preferred_username' )
scope: 'openid email profile',
get nonce() {
return uuid.v4();
},
},
}, OpenIDConnectPlugin.verify);
passport.use(strategy);
strategies.push({
name: strategy.name,
url: AUTH_OIDC_LOGIN_PATH,
callbackUrl: AUTH_OIDC_CALLBACK_PATH,
icon: 'fa-openid',
scope: 'user:username',
});
return strategies;
} catch (err) {
console.log(err);
winston.error(err);
throw err;
}
};
Definitely makes sense to integrate this as an additional verification vector in the spam-be-gone plugin.
Thoughts @akhoury ?
This topic was created as an entry in the Developer FAQ. Respond below if you have additional information to add re: SSO or other session-sharing implementations.
The common causes for a session mismatch error are usually one of the following:
config.json fileIf you have a misconfigured url value in your config.json file, the cookie may be saved incorrectly (or not at all), causing a session mismatch error. Please ensure that the link you are accessing your site with and the url defined match.
cookieDomain set in ACPSometimes admins set this value realising that they probably don't need to set it at all. The default is perfectly fine. If this is set, you'll want to revert the setting by editing your database directly:
Redis: hdel config cookieDomain
MongoDB: db.objects.update({ _key: "config" }, { $set: { "cookieDomain": "" } });
X-Forwarded-Proto header from nginx/apacheIf you are using a reverse proxy, you will need to have nginx pass a header through to NodeBB so it correctly determines the correct cookie secure property.
In nginx, you will need to add the directive like so:
location / {
...
proxy_set_header X-Forwarded-Proto $scheme;
...
}
This topic was created as an entry in the Developer FAQ. Respond below if you have additional information to add re: SSO or other session-sharing implementations.
The recommended method of sharing sessions between two separate and distinct applications is through OAuth2. We recommend this approach because NodeBB maintains its own user records, so that we can keep track of user-related metrics and other data. Relying on another database would be tricky, prone to breaking, and quite possibly dangerous.
Luckily, it's quite straightforward to get things working with OAuth2!
The first step is getting your application to expose an OAuth2 endpoint. If you're running a Node.js based app, you can use a module called OAuth2orize.
Once that is set up, you'll want to take a look at the SSO plugin skeleton for customised OAuth deployments -- nodebb-plugin-sso-oauth. You'll take this plugin, fork it, and modify it to communicate with your OAuth endpoint.
Once everything is working properly, you should be able to register and log in/out via your web app.
By default, NodeBB instances should be able to send email out of the box. However, having the server send emails is not ideal, as the server itself does not have any reputation (and in some cases, may have a negative reputation if a spammer sent messages from the IP in the past).
In nearly all cases, you will want to open up an account with a third-party emailer service, who can handle these outgoing messages for you.
Here at NodeBB, we recommend "nodebb-plugin-emailer-sendgrid", which is installable via the admin control panel. SendGrid has a free tier that is fairly generous, so you should not have to pay any upfront or recurring costs.
Once the plugin is installed and activated, you will need to register a new account at SendGrid and create an API key for NodeBB to use.