This page contains specific upgrading instructions to help you migrate between Express-Stormpath releases.
We were looking for the option config.web.register.autoAuthorize, to enable the auto-login-after-registration feature. This should actually be autoLogin, and it is documented as this. The library is now looking for this option as autoLogin, so you will need to change your configuration it if you were using autoAuthorize.
If you are using the /forgot endpoint and posting JSON, you need to change the username property to email.
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
Many changes needed!
This is a major release in the life of this library. This release includes tons of new features, refactorings, etc.
To upgrade from 1.0.6, please pay careful attention to the below notes.
Firstly, this library now takes new configuration options. When you initialize the middleware, you'll need to pass in the following basic options:
stormpath.init(app, {
client: {
apiKey: {
id: 'xxx',
secret: 'yyy'
}
},
application: {
href: 'https://api.stormpath.com/v1/applications/xxx'
}
});Every setting in the new configuration can also be set via environment variables. The way it works is that all nested fields are expanded out to their full path. For instance, if you wanted to set client.apiKey.id, you could create an environment variable called:
STORMPATH_CLIENT_APIKEY_ID=xxxLikewise, for the rest of the settings above:
STORMPATH_CLIENT_APIKEY_SECRET=yyy
STORMPATH_APPLICATION_HREF=https://api.stormpath.com/v1/applications/xxxNext, we've disabled default login, registration, and logout routes. To enable them, you'll want to do the following:
stormpath.init(app, {
website: true
});This will enable the default website features this library provides:
- A login page (/login).
- A registration page (/register).
- A logout route (/logout).
Next, we've disabled the /oauth endpoint we previously enabled by default. If you want to enable this, with its default settings, you can now do the following:
stormpath.init(app, {
api: true
});Another important thing to note, our old OAuth functionality created a route that lived at /oauth. When you enable the new OAuth endpoint, it will live at /oauth/token instead. This was done to comply with the OAuth2 spec more closely, and ensure compatibility between libraries / frameworks.
Other than the above, your upgrade process should go smoothly. There are, of course, lots of new features / configuration options, so please read through the new library documentation to get a feeling for it!
Thanks for reading,
-Randall
No changes needed!
No changes needed!
If you were previously working with Stormpath sessions directly, then you'll need to modify your code. While previously Stormpath sessions were referred to by req.session, they are now referred to by req.stormpathSession.
No changes needed!
No changes needed!
No changes needed!
This is a major release that breaks several things from older releases.
Firstly, if you were previously using the postRegistrationHandler to perform custom logic after a new user registers, you'll need to modify this event handler to accept new arguments.
Previously, the postRegistrationHandler had a method signature that looked like this:
postRegistrationHandler(account, res, next) { ... }In this release, we're modifying the method signature to look like this:
postRegistrationHandler(account, req, res, next) { ... }What we've done is add in a new parameter: req, which is the Express request object. This gives you more control over the request, and allows you to do things like modify session data, etc.
Secondly, we no longer support old sessions.
If you are upgrading directly from an older release (version 0.2.x) to this release, then your existing user sessions will be invalid, and this will force your users to re-authenticate the next time they visit your site. This is due to a change in the way we store session data that was introduced in version 0.3.x.
Note
The session change will NOT break your code, but it WILL require your users to re-authenticate the next time they visit your site.
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
If you were previously specifying a value for the stormpathIDSiteVerificationFailedView setting, you'll need to rename that field to stormpathIdSiteVerificationFailedView.
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
- Please upgrade to version 0.4.4 -- this version contains a bug with our user middleware which causes permission assertion to always fail.
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
If you were previously relying on the built-in CSRF validation in your pages, you'll need to include CSRF manually. This release no longer includes CSRF token protection on all pages -- it only protects the Stormpath pages --this was done to be less confusing for users.
To add CSRF protection to your site similar to what was included automatically before, you'll want to use the express-csurf library, which you can find on Github here: https://github.com/expressjs/csurf
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!
No changes needed!