During writing of the update notes, found that the upgrade path would be
tricky from a security point of view. If people were pending email
confirmation but had an active session, they could technically be
actively logged in after the next release.
Added middlware as an extra precaution for now.
- Updated auth system for mfa to not update intended URL so that the
user is not redirected to mfa setup after eventual login.
- Added notification for users setting up MFA, after setup when
redirected back to login screen to advise that MFA setup was complete
but they need to login again.
- Updated some bits of wording to display better.
- Restructured some of the route naming to be a little more consistent.
- Moved the routes about to be more logically in one place.
- Created a new middleware to handle the auth of people that should be
allowed access to mfa setup routes, since these could be used by
existing logged in users or by people needing to setup MFA on access.
- Added testing to cover MFA setup required flow.
- Added TTL and method tracking to session last-login tracking system.
Discovered some difficult edge cases:
- User image loading in header bar when using local_secure storage
- 404s showing user-specific visible content due to content listing on
404 page since user is in semi-logged in state. Maybe need to go
through and change up how logins are handled to centralise and
provide us better control at login time to prevent any auth level.
- Added new DB column for control and role updated create/update actions.
- Created new middleware as a start to actual enforcement logic.
- Added indicator to role list of whether MFA is enforced.
So that DB/User access is not explicitly enforced.
Same for GlobalViewData middleware although that was also just doubling
up on ways to access user/auth info.
Also cleaned up Localization Middleware doc blocks.
Added iframe CSP headers with configuration via .env.
Updated session cookies to be lax by default, dynamically changing to
none when iframes configured to allow third-party control.
Updated cookie security to be auto-secure if a https APP_URL is set.
Related to #2427 and #2207.
Was accidentally skipped during previous updates. Will now be used on
saml, ldap & standard registration where required.
Uses session to know if the email was just sent and, if so, show the
confirmation route.
- Included tests to cover for LDAP and SAML
- Updated wording for external auth id option.
- Updated 'assertPermissionError' test case to be usable in BrowserKitTests
API listing endpoint filter can be found via &filter[name]=my+book query
parameters. There are a range of operators that can be used such as
&filter[id:gte]=4
Email confirmation middleware caused more mess than good, As caused
priority issues and it depended on auth actions. Instead its now a trai
used on auth middlewares.
Also used 'EncryptCookies' middleware on API instead of custom
decryption in custom middleware since we'd need to do replicate all the
same actions anyway. Shouldn't have too much effect since it only
actions over cookies that exist, of which none should be there for most
API requests.
Also split out some large guard functions to be a little more readable
and appease codeclimate.
Also implemented more elegant solution to allowing session auth for API
routes; A new 'StartSessionIfCookieExists' middleware, which wraps the
default 'StartSession' middleware will run for API routes which only
sets up the session if a session cookie is found on the request. Also
decrypts only the session cookie.
Also cleaned some TokenController codeclimate warnings.
Base logic in place but needs review and refactor to see if can better
fit into Laravel using 'Guard' system. Currently has issues due to
cookies in use from active session on API.
- Aligned and formatted config options.
- Provided way to override onelogin lib options if required.
- Added endpoints in core bookstack routes.
- Provided way to debug details provided by idp and formatted by
bookstack.
- Started on test work
- Handled case of email address already in use.
