Passport v0.5.2

After the release of v0.5.1, there were reports of breaking changes. From the perspective of the passport package itself, there should not have been any breakage. After investigating the reports, however, it was confirmed that issues arose when using certain strategies — passport-azure-ad (which is widely deployed) was common across the bug reports.

The issue arose because the 0.5.x series of releases have been refactoring Passport internals, to avoid monkey patching http.IncomingMessage and more cleanly extend the request object as it passes through middleware. This work was completed in v0.5.1, and what had become unused private variables were removed.

However, some strategies depend directly on passport@0.4.x or earlier, as is the case with passport-azure-ad. It’s generally unwise for a plugin to depend on the system it is plugged into, as it creates cyclic dependencies. It would be preferable for a strategy to depend on passport-strategy. Of course, code exists in an ecosystem that is not always ideal.

When such strategies were used in an application, they triggered the old monkey patching behavior. This behavior depended on the newly removed variables existing. And, because they did not exist, things broke with the error message: passport.initialize() middleware not in use.

To accomodate this situation, v0.5.2 introduces a compatibility layer. Simply continue to use passport.initialize() middleware as usual. If your application doesn’t use any strategies that that depend on prior versions of passport, this issue does not impact your app and use of passport.initialize() can be safely removed.

In order to facilitate upgrading strategies, I’d like to assemble a list of strategies which trigger this issue. Please report any issues you encounter.