- Use Symfony's Session component to work with sessions, instead of a custom database model. Separate the concept of access tokens from sessions once again.
- Extract common session/remember cookie logic into SessionAuthenticator and Rememberer classes.
- Extract AuthenticateUserTrait into a new AuthenticationResponseFactory class.
- Fix forgot password process.
- Use cookies + CSRF token for API authentication in the default client. This mitigates potential XSS attacks by making the token unavailable to JavaScript. The Authorization header is still supported, but not used by default.
- Make sensitive/destructive actions (editing a user, permanently deleting anything, visiting the admin CP) require the user to re-enter their password if they haven't entered it in the last 30 minutes.
- Refactor and clean up the authentication middleware.
- Add an `onhide` hook to the Modal component. (+1 squashed commit)
Specifically, the crash would occur when the first notification had a subject without a discussion relationship (e.g. the Subscriptions extension's newPost notification, where the subject itself was a discussion). Instead of simply eager loading the nested subject.discussion relationship, we load discussions manually instead.
This means that the "Start a Discussion" button will still be enabled if the user is not allowed to start globally, but only in certain tags.
Also add some other stuff to the changelog.
closes#640
This affects version numbers, extensions and paths, which might be
skeleton-specific. This commit moves those hardcoded values out of
the classes and instead injects them through the constructor. This
way, all prerequisites can be configured in the service provider.
Even when no language packs are enabled, a forum-en-xxx.js (or whatever the default locale is) file is still generated because other extensions may contain translations. But when enabling the English language pack, since no locales are registered with the LocaleManager, that file doesn't get flushed and therefore doesn't get regenerated with the English translations. This fix always registers the default locale with the LocaleManager so that's not the case.
Since we'll be encouraging (requiring?) people to include an "en" translation in extensions they want to put on the Marketplace, we should have a further fallback to "en" if it can't find translations in the forum's default language. That way if people only use extensions from the Marketplace, they'll hardly ever see any key names.
Thanks to @dcsjapan for the suggestion.
