@rod Thanks, it makes sense. I didn't backup ./nodebb_module dir.
So ./nodebb_module and ./uploads dirs are basically needed right? Is there any other dir is needed also?
I’ve written some express middleware to authenticate users based on a cookie from our other application, or drop them into a new user creation process on first visit. I’d like to refactor this as a plugin if possible.
Is there any way to do “app.use(myMiddleware)” within a plugin so I don’t have to patch authentication.js and maintain that diff across new version releases? (that just seemed like the logical place for it)
Wow, this would be perfect... lots of people ask for SSO/login integration, and this would be a huge step towards getting local auth to play nice with NodeBB...
I think it might be possible on application startup to do
plugins.firehook('app:start', app)and pass the express app object, that way plugins can add their own custom routes.
medwards last edited by medwards
That would solve my problem nicely. I'm only just becoming familiar with the plugin architecture/existing hooks, but most of my code lives in a separate .js file. The only touch point in the main codebase was an extra line in authentication.js init() to give my code access to that object.
@medwards https://github.com/designcreateplay/NodeBB/commit/f62c82c7975af005d68d52f952cadd51f9704d28 looks like we already have that action I just sent in the express app.
medwards last edited by medwards
@baris Nice! I'll refactor to use the hook and factor out the code specific to our authentication process. Should be able to at least create a plugin template where others can add their own authentication stuff.
It may be a little bit before I can get approval to release but it's in the pipe, at least.
Hey @baris ,
I started on the refactoring of our authentication code, but ran into some issues. I'm somewhat new to express but I think the problem is the plugins "action:app.load" method doesn't get invoked until after the app.use(app.router) call in webserver.js line 308 which prevents it from actually intercepting requests before they are routed by the application.
From what I can see it looks like much of the webserver.js initialization is actually launched asynchronously when that file is included by app.js, not when it's init method is invoked. I tried firing the same hook just before the app.use(app.router) call to see if that would work, but it appears that plugins aren't yet initialized by that point - not surprising since the init call is a bit further down in app.js.
I think to accomplish what I'm after might require a bit of refactoring of the timing of the init code to postpone the webserver initialization, or at least part of it, until after the plugins have loaded. I'd be happy to take a crack at this if there's a chance the code might make it back upstream, but I wanted to ask if this was something you guys might want in the core codebase or not before investing the time.
That's correct much of the code in webserver.js is executed when it is required by app.js and not when its init method is called. I don't see any problems with moving that code inside the init method and ensuring that it is called in the correct order. I think webserver.init is already called when plugins and templates are ready see here.
@baris So I believe this relatively smaller refactor would solve my problem.
I hesitated to do more since I'm not 100% sure what drove the initial decision to do some of that initialization at require() time. I see a few database round-trips but most of those calls could be run synchronously if I understand express correctly.
That looks good to me. Although I am not sure if it would have any side effects to other routes without testing can't tell for sure. I only see one db call in there for themes. I am not sure if there could be a case where webserver.js is required from app.js and then webserver.init is called before all the setup is done in webserver.js.