- Allows member logged in with valid session to update their profile info - name, email, subscribed(newsletter subscription status)
- Adds new util method for formatted member response on the endpoints
- Adds common middlewares for body/bool parser and maintenance
- Adds `subscribed` status to member response
- Add a query param that indicates whether signin/up succeeded or failed
- Add unit tests for all 3 possible cases for the createSessionFromMagicLink middleware
- Added an acceptance test to show the behaviour works in principle
- This restores the functionality from 3.14 as follows:
/members/ -> (with no route) rendered 404 error
/members/ -> (with route) renders members template
/members/?token=invalidtoken&foo=bar -> redirects to /?foo=bar
/members/?token=validtoken&foo=bar -> redirects to /?foo=bar
- Use array destructuring
- Use @tryghost/errors
- Part of the big move towards decoupling, this gives visibility on what's being used where
- Biting off manageable chunks / fixing bits of code I'm refactoring for other reasons
- Meant to cleanup the old api/canary/members earlier, removed now as it's unused
- Also removed all the duplicate references to labs.members in various places
no issue
We changed the magic link route handling from setting global value to just redirecting to frontend in [this](d8d5d6b7d0 (diff-0d54454fd954b0203a71ec52df4bd4c0R96-R98)) commit, but missed removing `next()` call which attempts to send response again causing Unhandled rejection error. This change simply removes the extra `next()` call
- Magic link token handling doesn't need to be global, this couples the system to the frontend, which isn't necessary
- Instead, we create a session from the token, and redirect to the frontend
- Move res.locals.members setting into existing middleware function instead of having it separate
- The existing createSessionFromToken was actually doing two things behind the scenes
1. Handling the ?token from the magic link and creating an actual session (mounted globally, which is not necessary)
2. Loading an existing session so that a member is logged in to the frontent
- IMO 1. is part of members, and doesn't need to be global
- IMO 2. is part of the frontend. It does need to be global but should NOT be hidden away behind the token middleware, as it wasn't clear what this was doing
refs https://github.com/TryGhost/members.js/issues/6
This exposes an endpoint on site url (`/members/ssr/member`) to get member's data in exchange for their session/identity on a theme when they are logged in. It essentially uses the same logic and data which is passed down to theme through handlebar helpers, and is used by members.js script to load member data.
refs 91984b54ca
- For request effieciency we should be using a minified file just like we did previously with `ghost-sdk.js`
- Modified 'max-age' caching header to 1 year for both minified and non-minified files as thay won't affect dev environment and should be beneficial for self-hosting instances that don't use minification
- Along the way corrected an extra 301 redirect because `/public/member.js` path wasn't using a bakslach in the end.
no-issue
This name `login` was misleading as this middleware didn't login
members, that was handled by the `authentication` middleware,
specifically `exchangeTokenForSession`
no issue
- In order to keep site/app.js module tidy and less coupled with members module we need to extract some of the functionality where it belongs conceptually
- Added "members enabled check" middleware to stripe webhook endpoint
- Reshuffled members middleware so that siteApp is in control of mounting points. This is meant to be a more explicit way to see which endpoints are being handled by members middleware
- Extracted member-specific public file middleware
- Unified use of `labs.member` alias method. Done for code style consistency
- Added basic members' test suite. This is a base we could work from when more modifications are needed
- Removed route handler for unexisting members file "members-theme-bindings.js". Calling this route otherwise causes a 500. Looks like a leftover from 49672a1e4d
