refs https://github.com/TryGhost/Team/issues/530
The RouterController was a grab bag of all controller methods, making it
difficult to mock & test. This adds a MemberController with a smaller
API - making it easier to test.
no-issue
When seeding the database with fake members & stripe data, it's possible
to create stripe plans without a nickname. Similarly some other services
do not have a nickname on their plans. This ensures that we do not error
when working with these plans.
no-issue
If we are to perform the `linkSubscription` method inside of a
transaction, the addition of the paid subscription events would happen
outside of the transaction, and cause errors. This ensures that we pass
the options object (containing the transaction) to the models calls to
add paid subscription events
no-issue
1. We do not want to store payment events for payments of 0 value
2. Stripe webhooks can arrive and be processed "out of order", which can
result in us attempting to add a payment event for a member which
does not yet exist. The change here will 404 in such (edge) cases, so
that Stripe will retry the webhook at a later point, when the Member
has been created, allowing us to store the payment event.
refs https://github.com/TryGhost/Team/issues/469
In order to reduce noise, we want to only display newsletter
subscription events which are not likely to be the result of a member
signup. The approach we've taken is to remove any newsletter
subscription (not unsubscription) event, if when sorted in chronological
order, it is to reside next to a signup event for the same member.
An improvement to this approach might be to add some kind of transaction
id to events which would allow us to group together events which should
be considered to have happened simultaneously.
refs https://github.com/TryGhost/Team/issues/469
Signup events are captured by status changes with no `from_status`, this
means that the member did not have a status (did not exist) before this
change.
refs https://github.com/TryGhost/Team/issues/469
We order the set of all events by created_at, but were not fetching the
individual events with the same order applies, this resulted in
incorrect results.
refs https://github.com/TryGhost/Ghost/issues/12711
We must wait for the stripeSubscriptions relation to be loaded before
attempting to loop through them. As well as this we should use `upsert`
so that we can edit a subscription record by `subscription_id`, rather
than the (internal) `id`
no refs
The member id assigned when creating a new status event on member creation was incorrectly using `data.id` instead of `member.id`, which was undefined causing a validation error.
refs https://github.com/TryGhost/Ghost/issues/12602
* Added Event Repository
** Added method for MRR over time
** Added method for newsletter subscriptions over time
** Added method for gross volume over time
** Added method for status segment size over time
* Captured login events
* Captured newsletter subscription/unsubscription
* Captured email address change events
* Captured paid subscription events
* Captured payment events
* Captured status events
refs https://github.com/TryGhost/Team/issues/479
* Fixed updating payment method for canceled subscriptions
Stripe considers canceled subscriptions as non-existent, so any attempts
to update them will fail with a 404 not found. Prior to this change we
were attempting to update *all* subscriptions for a customer, including
those which were canceled. This would cause an error and the loop to
break.
* 🐛 Fixed errors for members with multiple active customers
Members with multiple active customers would have their first active
customer found updated with the new payment method. We would then
iterate through *all* active subscription, and attempt to update their
payment method. If a subscription was not owned by the customer that was
just updated, it would error and cause the loop to break out.
* Added ability to update a specific subscription's payment method
In order to remove ambiguity we add the ability to update the payment
method for a specific subscription. This will remove room for errors as
we will not have to worry about if a subscription belong to the customer
or not.
refs https://github.com/TryGhost/Team/issues/475
The subscription object here is a database model rather than an
ISubscription from the stripe library, and we need to 1) use the `get`
method to read attributes and 2) read the `subscription_id` attribute,
as the `id` is our internal one.
no-issue
Fetching relations via the model returns a promise, and this was missing
the `await` keyword. We also need to `get` the subscription_id attribute
as we're working with models rather than subscription objects.
no-issue
If we receive webhooks out of order, e.g. a
`customer.subscription.updated` with a status of 'active', followed by a
`customer.subscription.created` with a status of 'incomplete'. We would
overwrite the correct value with data from the "older" webhook. This
ensures that we always fetch the latest data from the Stripe API before
storing in the database.
no-issue
related to ef9cb0862c
In the last patch which fixes the bug for not passing custom redirect urls when a checkout session is created, we missed updating the case where a logged in member tries to update the subscription.
no issue
The logic to fetch member for a checkout session was incorrectly creating a new customer instead of finding an existing one, so the member's billing details was not getting updated.
no-issue
This refactors the members-api module so that it is easier to test going forward,
as well as easier to understand & navigate. The Stripe API no longer contains
storage code, this is all handled via the member repository. And we have dedicated
services for webhooks, and stripe plans initialisation.
no issue
- In case of a member updating their email, the `updateEmail` type was overridden with `signup` or `signin` without the force option. The fix forces the correct email type for when member requests to update their email.
refs https://github.com/TryGhost/Ghost/issues/12253
Allows reading `requestSrc` from Stripe checkout flow metadata to send signup emails with customized action param when requesting from Portal
no issue
refs https://github.com/TryGhost/Ghost/issues/12253
Currently, Ghost uses standard query params like action, success and stripe for all actions and redirects to a site for member events. This needed to be extended to allow for portal specific query params so it doesn't overlap with specific theme handling or custom notifications.
The change here adds an extra option - `requestSrc` - which can be passed when using magic link API to send a link which is passed down to `getSigninURL`, and allows the `action` param to configured to `portal-action` when magic links are sent from Portal
no issue
Previously, we were sending a magic link email to signup in case a logged-in member upgrades to a paid account, as we didn't check for logged in status while sending the magic link and always sent one on finishing checkout. Since Portal allows members to upgrade their account from free, it doesn't make sense to send another email to signup after completing checkout.
The fix here adds a metadata `checkoutType` to checkout session creation which can be passed in with `upgrade` value to denote an existing member is upgrading and doesn't need an email.
refs https://github.com/TryGhost/Ghost/issues/12256 , https://github.com/TryGhost/Ghost/issues/12255
Currently when listing subscriptions for Members, we were only showing the subscriptions which have a status of trialing or active.
Based on discussion, the `unpaid` and `past_due` states on Stripe also represent owner's intention of considering a subscription as active instead of `cancelled`, so we allow any subscriptions under these 2 states to be also listed for a member and consider them as `paid`.
- Subscriptions will go into a past_due state if the payment is missed, this should be considered a grace period where the member still has access.
- After this the subscriptions will either go to the unpaid or the cancelled state - this can be configured on an account by account basis in the Stripe dashboard. `unpaid` is considered as an intention to keep the subscription to allow for re-activation later.
refs https://github.com/TryGhost/Ghost/issues/12270
Previously we would create the member, and then update their name from
stripe data, this mean that webhooks would be sent _without_ a name,
despite us possibly having the information to provide one.
Here we've updated the creation of members to include the name attached
to the default billing method, this will ensure that webhooks are sent
with all availiable information.
no-issue
Subscription created events are required for migrating Stripe subscriptions from
alternative platforms, which involves creating a new subscription for a customer
(outside of Ghost) before cancelling the original subscription.
no issue
- Email update magic link was not sent out for sites which did not allow self signup as it didn't find the member on new email, which is expected.
- Updates sending magic link check in case an old email is found to correctly trigger update email
no-issue
We were passing a string rather than an object to find the member to set
the geolocation on, this was causing us to always find the same member
each time, and so newer members would never have their geolocation set.
no-issue
This paves the way for Ghost to be able to pass in a custom token
provider which will handle the shortening of tokens and making them
single use.
no-issue
This removes the concept of `subject` & `payload` from the function
signatures, making the implementation a little more generic, and less
JWT centric.
We also replace getUserFromToken and getPayloadFromToken with a single
method getDataFromToken, which will contain all the necessary data.
* Updated members-api to use new magic-link module
This updates the usage of magic-link to work with the new interface
* Fixed labels not saving for new members
Due to how bookshelf-relations works, we must fetch the labels before
saving a member, otherwise the labels are all deleted.
* Used a proper class rather than constructor function
This just moves the code to a more modern standard
* Updated methods to be async
This prepares us for a future where token generation and validation may
require access to storage and thus be an asyncronous operation
refs https://github.com/TryGhost/Ghost/issues/12150
- `destroy` method was using incorrect cancel subscriptions method - stripe.cancelStripeSubscriptions - which doesn't exist
- Fixes call with intended method - `stripe.cancelAllSubscriptions` - to cancel all subscriptions
refs TryGhost/Ghost#12127
- Adds new `updateSubscription` method to members-api which allows updating individual subscription for a member
- New method only allows toggling of cancellation at period end for a subscription at the moment
no-issue
Using models internally and in the exported API means that we avoid expensive
`toJSON` calls, which affects performance when looping through large lists of
members. It also allows us to take advantage of the new relations used in the
models.
The addition of "ByID" methods for linking stripe customers and setting
complimentary subscriptions allows bulk imports to avoid the overhead of creating
a model for each members, instead passing an id string. n.b. currently the impl
_does_ still create models, but it makes it easier to optimise and refactor in the
future.
no-issue
Previously we would blindly put subscriptions into the database when we
received a webhook, which could result in orphaned rows that were not
linked to a customer (and by extension a member)
This updates the logic so that we will only add subscriptions if we have
a record of their customer.
Customers are only added during a checkout.session.completed webhook, at
which point a member is guarunteed, but for formailty and safety against
changes in the flow, the logic has been applied to inserting customers
too.
refs https://github.com/TryGhost/Ghost/issues/11557
If a subscription failed to delete, we would error and bailout of the
process, this updates it to log the error so that site owners have a
record of the error in the logs, but also to continue through the rest
of the subscriptions.
no-issue
Destroy is terminology we usually use for the model layer and was a
little confusing without context, this method is used in one place so
it's a low effort cleanup with minimal repercussions
refs https://github.com/TryGhost/Team/issues/342
- Send magic link middleware was not using custom status code from error and sending 500
- Updates error code to be picked from err object if present, or fallback to 500 as before otherwise
refs https://github.com/TryGhost/Ghost/issues/12074
Some sites may have had duplicate webhooks created due to a race
condition. This updates the members-api to cleanup _all_ webhooks before
starting, allowing it to create webhooks on a fresh slate, and removing
possible causes of 401 errors due to incorrect webhook secrets.
refs https://github.com/TryGhost/Ghost/issues/12065
This protects us against multiple instances of the members-api being
started simultaneously and race conditions where inbetween the initial
"GET" of a plan which returns empty, and the "POST" of a plan to create
it, another instance has already created it.
no-issue
This fixes a problem when subscribing to a Plan (Price) with a default
trial period. We also add logging to add a little more information about
which flow we're entering.
Subscriptions that are started with a trial have a `setup_intent`
present on the Checkout Session object, which was incorrectly causing us
to determine that we are in a "setup" flow and attempt to update a
customers card details.
We now use the `mode` property of the Checkout Session to determine
whether we are handling a new Subscription, or if we are in a "setup"
flow and should update the Customer's card details.
no-issue
This fixes a problem when subscribing to a Plan (Price) with a default
trial period. We also add logging to add a little more information about
which flow we're entering.
Subscriptions that are started with a trial have a `setup_intent`
present on the Checkout Session object, which was incorrectly causing us
to determine that we are in a "setup" flow and attempt to update a
customers card details.
We now use the `mode` property of the Checkout Session to determine
whether we are handling a new Subscription, or if we are in a "setup"
flow and should update the Customer's card details.
refs https://github.com/TryGhost/Ghost/issues/12061
Due to a bug in Ghost webhooks are now created with a trailing "/" which
meant that the previous webhooks to that (without a slash) was never
removed.
This results in users receiving emails from stripe about failed webhook
delivery, which is not good at all.
This fix lists out the webhooks and finds (if present) the webhook which
matches the current URL, minus the trailing slash. If found it will then
attempt to delete that webhook thus stopping the emails from Stripe.
I've added a note to remove this code as it should only ever need to run
once, and can be removed for the Ghost release after these changes.
no-issue
* Refactored model dependencies
This groups all of the model depenencies into a single models object,
and renames the models with more concise identifiers
* Fixed spacing
* Added webhook support to metadata
* Refactored stripe configure to have better logging
* Refactored webhook creation to reuse existing webhook
* Installed @types/stripe
no issue
- The extra payload added to magic link token included `name`, `labels` and `oldEmail`
- Refactor in commit [here](bf63ffe424 (diff-9f9ef757543bb9a90baba0d3bea76a83L157-R169)) changed the `body` variable assignment causing the payload objection creation to not include the extra data from request body
- Updates `body` to `req.body` to use correct data from request
- We have many customers asking for INR as there are special rules in Stripe for this currency
- As well as a desire for local-selling
- Meaning it's not valid to use e.g. USD instead
no issue
- This method is needed to be able to validate if customer exist in configured Stripe account before attempting to link one with local member.
refs https://github.com/TryGhost/members.js/issues/38
- In case of incomplete Stripe setup like Account name, checkout session creation fails and throws error, which was not being handled and 200 returned after long timeout
- This change catches the error and returns correct status along with message for clients to handle it downstream
closes https://github.com/TryGhost/Members/issues/148
- geolocation was not being fetched/stored for paid member signup
- magic link was being sent after Stripe webhook but we don't have an IP at that stage
- it only worked when a magic link was requested by the browser
- moved the geolocation fetch/update to `members-ssr`
- kept the ip geolookup and storage inside `members-api` but exposed it as a method so consumers are able to choose when it's performed
- used the new api method in `members-ssr` when exchanging a token from the session as that is always driven by browser requests so we know we have an IP and it's likely the correct one (reliant on consumers having "trust proxy" config correct)
- stopped storing IP addresses in the token payload (keeps links shorter)
refs https://github.com/TryGhost/members.js/issues/30
- Updates `sendMagicLink` middleware to allow adding old email address to payload. Checks for if new email address already exists in db before creating magic link, throws error in case of duplicate email.
- Updates magic link parsing for data to check if the intention is to update email address and update member's email to new email address in case its allowed.
- Return session data from magic link using the new email address
no-issue
Without this flag the checkout session will ignore any default trial periods
attached to the plan. Now we are able to give basic support for trials, by
attaching a trial period in Stripe Dashboard
no issue
- Makes passing `name` and `note` field in member update data as optional instead of making them undefined
- Allows email to be updated
- Adds stripe subscriptions list to updated member's response data to make update consistent with get method
refs TryGhost/members.js#29
- Uses the metadata option in stripe checkout flow to add member's name on creation via anonymous checkout flow
- Allows clients like memebrs.js to pass member's info like name from checkout signup flow
refs TryGhost/members.js#29
- Allows passing metadata to checkout session API
- Metadata is passed to stripe's checkout session on creation and read back from webhook event
- Allows clients like members.js to pass custom info like member name to Stripe flow
no issue
- Current update stripe subscription API calls only allowed cancelling a plan
- This change adds option to pass plan's nickname as `planName` in request to update subscription to new plan
- Checks if plan name is valid and updates stripe subscription to new plan at default prorate behavior
refs https://github.com/TryGhost/members.js/issues/10
- Allows passing an additional `customerEmail` value to our checkout creation API
- This value is used to pass `customer_email` option to stripe's checkout session - https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer_email.
The `customer_email` allows pre-filling the customer's email field in case of an anonymous checkout as customer doesn't exist already, and also ensures the stripe subscription is created with same email address as given by user during signup flow.
no issue
We were using incorrect method for logging in geolocation warning - `this.logging.warn(err)` - as `this.logging` doesn't exist in this file. Updated to use correct logging method.
no issue
- Adding these properties allows specifying which currency is currently used on member's plan.
- Supported currencies list: USD, AUD, CAD, GBP, EUR
- They were chosen based on the most used/requested currencies within Ghost
- With adding multiple available currencies that can be setup also had to add handling of Stripes limitation of having single currency per paying customer
requires f38d490886
- adds `lib/geolocation.js` with `getGeolocationFromIP()` function which uses https://geojs.io to lookup geolocation data from an IPv4 or IPv6 address
- updates `create/updateMember()` functions to work with a `geolocation` property in the passed in object
- if `geolocation` is `undefined` when updating a member do not reset any existing property
- updates `sendMagicLink` middleware to extract the IP address from the request and stores it as part of the token payload
- updates `getMemberDataFromMagicLinkToken()` method to extract the IP address from the token payload and perform a geolocation lookup if we have an IP address and a matching member does not already have geolocation data
This reverts commit 5f0d2168f3.
After discussing the best approach to multipe currency problem would be
to allow creating multiple "Complimentary" plans. All security related
checks should stay strictly based on name and would not cause issues.
refs https://github.com/TryGhost/Ghost-Admin/pull/1430
- When the client creates a complimentary plan with other currency than USD we should not allow for it to avoid creating a mess in the Stripe plans
refs https://github.com/TryGhost/Ghost/pull/11571
- Allows updating members billing information through Stripe's setup intent (stripe.com/docs/payments/checkout/subscriptions/updating#set)
- Accepts 2 new parameter to handle redirects specific to billing update.
no issue
- On model layer in Ghost empty string is always converted to `null` for not nullable fields, which wasn't letting the value through to the database
- Current solution is a stopgap to fix imports of cyclic plans without nicknames. Ideally nickname field should become nullable in the future so this logic can be simplified
no issue
- This solves a problem when connected Stripe plan doesn't have plan `nickname` filled out (possible with older versions of Stripe API)
- Defaulting to empty string instead of creating a migration because SQLite doesn't support `ALTER ... MODIFY` syntax and thus knex can't altter the table that easy
- "Marks the column as an alter / modify, instead of the default add. Note: This only works in .alterTable() and is not supported by SQlite or Amazon Redshift. Alter is not done incrementally over older column type so if you like to add notNull and keep the old default value, the alter statement must contain both .notNull().defaultTo(1).alter(). If one just tries to add .notNull().alter() the old default value will be dropped." (ref. https://knexjs.org/#Chainable)
refs https://github.com/TryGhost/Ghost/pull/11537
- Adds ability to assign and cancel "complimentary" type of subscriptions to the member
- The functionality is needed to be able to provide free premium plans for members (e.g. family members, trials, gifts)
- When member already has an active paid subscription and complimentary one is applied the old one is upgraded. Proration is not given
- When deleting a subscription we need to update localy stored records right away to be albe to reflect the change in the UI. This behavior will also be in line with how subscriptions updates/creates are handled
- Blocked any client update for complimentary subscription. We should prevent non authenticated clients from upgrading/subscribing themselves to "complimentary" plan.
no issue
- `customers` property contains an array of customer for which 'for..of' syntax is more appropriate
- Bug was causing creation of multiple customers in Stripe when new checkout session was initiated for existing customer
- Discussed in https://github.com/TryGhost/Members/pull/90/files#r368889289
refs https://github.com/TryGhost/Members/pull/105
- It's a follow up to a series of refactorings in the module mostly discussed in refed PR
- The sendEmailWithMagicLink and destroyStripeSubscriptions were exposed through members API so that Ghost could call it from the controller level
refs #https://github.com/TryGhost/Ghost/pull/11434
- Added method to allow updating single subscription. Only `cancel_at_period_end` field can be updated.
- Middleware is needed to allow Ghost Core to cancel/uncancel member's subscription.
- Relies on the request containing identity information to be able to verify if subscription belongs to the user
- When member could not be identified by the identity information present in the request we should throw instead of continuing processing
- Handling and messaging inspired by https://github.com/TryGhost/Ghost/blob/3.1.1/core/server/services/mega/mega.js#L132
- When the user initiates subscription cancellation we can safely mark the subscription as canceled so that it's not shown in the interface on subsequent request. Otherwise, we end up in a situation where we still return the subscription in the period until Stripe triggers the webhook.
- Added boolean coercion for cancel_at_period_end parameter. If anything but boolean is passed to Stripe API it throws an error. Coercing the value on our side is a gives a better dev experience
no-issue
When using localhost urls the call to `create` will error and end in teh
catch block - so we need to use the environment variable there, too.
Introduced in 0149dd8f
no issue
- When debugging Stripe with using: `stripe listen \
--forward-to http://ghost.local/members/webhooks/stripe/` this priority is nice to have so that Ghost process can be initialized using WEBHOOK_SECRET env variable
- It was not working in current form because Stripe recognized `ghost.local` as a valid domain and didn't throw any errors
- Removed unneeded secret assignment in a catch statement. It is redundant with the new implementation
no-issue
* customer.subscription.deleted - when a subscription is cancelled
* customer.subscription.updated - when a subscription status/plan changes
* invoice.payment_succeeded - when a subscription has successfully renew
* invoice.payment.failed - when a subscription has failed to renew
no-issue
This flag is used to allow the sendMagicLink middleware to send an email
to members which do not yet exist. When this flag is set to false, the
only way to create members, would be via the stripe webook, or via the
`create` method exposed on the `members` object
no-issue
This updates the initialisation logic to fetch all webhooks (we use
limit: 100, and there are currently a max of 16 webhooks in stripe) and
find one with the corrct url. Once found, delete that webhook. We then
attempt to create a new one, and log out any errors (this is to allow
for local development, creating a webhook with a local url is expected
to fail)
no-issue
Previously members-api exported a pre configured express router with the
paths and handlers defined. This did not allow for much control from the
parent application. This replaces this pattern by exposing middlewares,
which the parent application can mount where it sees fit.
no-issue
This removes the subscription api as we are using stripe checkout to
generate those
This removes the customers api as we no longer need the deterministic
api for it
