I recently implemented auth for Derby using Passport. It was originally implemented as Everyauth, but due to technicalities (later) had to be migrated to Passport. In the end, however, my server running the same logic as Everyauth, migrated to Passport, started crashing with "memory limit exceeded" errors (500mb).
I'm wondering if:
At first I chose Everyauth because Derby was created by the author of Everyauth - so it's a natural fit; and the Derby folks are using Everyauth themselves internally. However, I found that (1) Everyauth password authentication specifically ("Local Strategy") was less suited for Derby purposes than Passport, and (2) Passport lets us pass in strategy objects for each auth strategy we want to implement, rather than having to implement all the strategies manually in code.
Once that was built out, I replaced all the auth code for my application using derby-auth and git push heroku master'd. The result was the app started crashing due to "memory limit exceeded" errors. The app worked fine when not logged in, but as soon as I logged in - refreshing once or twice crashed the app. Here's the original Everyauth implementation if that's any useful reference. I don't mean this to be a "fix my code" support request, but was hoping you have any top-of-the-dome knowledge so I don't go too far down a rabbit hole if it's not the right direction.
git push heroku master
I don't know of any memory leaks in particular. Passport is deployed in quite a few high-traffic environments, so anything as severe as "refreshing once or twice" would certainly have been caught by now.
When I get a chance, I'll setup derby-auth and see what I can track down. In the meantime, however, please update this issue if you pinpoint a problem in Passport itself.
I noticed you've been pushing updates to derby-auth. Is it safe to assume you found the leak and this issue can be closed?
Oi, I totally forgot about this issue! Do you know, HabitRPG which uses derby-auth in production has had a nasty memory leak for a very long time HabitRPG/habitica#165 - probably not due to Passport, since Passport is used everywhere in production. But I'll close this ticket, and keep it handy as we research the leak. It's gotta be something else in my setup. If it's this, I'll check back.
OK, thanks. Still haven't had time to experiment properly with Derby, but if/when I do I'll update here if I find anything relevant.
I just had a Kickstarter tip, which will help fund a proper investigation on that memory leak. You'll know sooner than later if Passport is the culprit (again, doubtful - but it's good timing you resurfaced this ticket, as I totally forgot about this possibility)
Think I found it. I'm calling passport.use(..) within express.use(..), meaning passport is setup in each request. Don't judge, was my younger days of JS :) Now, the problem with just moving the passport.uses outside is that they need access to the model variable, which is accessible in their current closure scope. I can get it in express routes via req.getModel(), but I need req which isn't available in passport.use() callbacks. Any recommendations?
Might I submit a PR adding req to _verify callbacks?
self._verify(accessToken, refreshToken, profile, verified); becomes self._verify(accessToken, refreshToken, profile, verified, req);
self._verify(accessToken, refreshToken, profile, verified);
self._verify(accessToken, refreshToken, profile, verified, req);
There's already a passReqToCallback option that you can set, and then req becomes the first argument to the verify callback. Details at the bottom section "Association in Verify Callback" here: http://passportjs.org/guide/authorize/
That work for your situation?
You're a mile ahead of me, that's exactly what I need. Thanks Jared!