1.8.0 Breaking Changes

NodeBB Development

Suggested Topics

  • 0 Votes
    6 Posts

    Oh, we are actually supposed to be merging the version bump back into master, let me do that now.

  • 1 Votes
    3 Posts

    I think I have discovered another breaking change that you didn't mention, though it is probably super-niche.

    This commit: https://github.com/NodeBB/NodeBB/commit/ec91ef1c644044bba44198b031913655e784b4bb
    broke our custom SSO plugin. The result was that after successfully logging in our external identity provider and being redirected to our Forum's callback endpoint, I was ending up not logged in (the button in the header still said "Log in") and stuck on /register/complete roadblock. It looked like our Passport strategy verify callback, that parses output from the identity provider and fetches user data via OAuth2 was not invoked at all.

    It turns out that the changes in this commit don't play well together with passport-oauth2 (https://github.com/jaredhanson/passport-oauth2) internal ability to protect against CSRF (which we were using). This strategy was already using state parameter to pass its own CSRF token. I don't have more time to investigate but I suspect things shipwrecked when NodeBB overwrote the state parameter with its own CSRF token.

    Turning off passport-oauth2 internal CSRF protection (by removing state: true from its options) fixed the issue.

  • 2 Votes
    3 Posts

    Due to changes introduced to loading javascript assets in 1.7.0, using jquery in widgets requires waiting for the page load event.

    Sample widget for 1.7.0+

    if (window.jQuery) { doStuffThatUsesJquery(); } else { window.addEventListener('load', doStuffThatUsesJquery); }
  • timestamp change

    NodeBB Development
    0 Votes
    3 Posts

    But... It's a breaking change.
    You should not do such stuff when you have now 1.0

  • Gotchas for v0.5.0

    NodeBB Development
    2 Votes
    18 Posts

    Related issue: https://github.com/NodeBB/NodeBB/issues/1978

    This is another breaking change. It effects anyone using the hook filter:user.custom_fields and filter:register.build to add custom data to users on registration.

    If you were using filter:user.custom_fields to add new entries into the user object you can just switch the hook you are using to filter:user.create. No need to change anything else.

    If you are using filter:register.build to add new entries into the registration form and want these entries to get added into the user object you need to use the hook filter:user.custom_fields. In your plugin that adds new entries into the registration form just add a listener for filter:user.custom_fields and add the fields that you added to the form into the array passed in, here is a sample.

    // plugin.json { ... "hooks": [ { "hook": "filter:user.custom_fields", "method": "addCustomFields"} ], ... } //plugin code function addCustomFields(fields, callback) { fields.push('newCustomField1'); // must match the input name you added to regForm fields.push('otherCustomField1'); callback(null, fields); }

    After this when a new user registers they will have newCustomField1 and otherCustomField1 entries in their user object.

    @bentael nothing needs to be done for spam-be-gone since we don't want the captcha form entries in the database anyways.

    Before this change it was possible to add any field into the registration form client side and it was inserted into the database. Now only the fields that core and plugins specify are inserted.