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
* Installed stripe@7.4.0
refs #38
We were relying on stripe being installed in Ghost, this moves the dep
to the correct package.
* Created exponentialBackoff wrapper for stripe api
refs #38https://stripe.com/docs/testing#rate-limits The stripe docs suggest to
use exponential backoff when recieving a rate limit error. This wrapper
will wrap stripe api calls, and retry them after 1s,2s,4s,8s,16s until
eventually failing. This gives a total of 5 retries over 31s.
* Added wrappers around the stripe api calls
refs #38
* Ensured all calls to stripe api go via exp backoff
refs #38
* Scaffolding out the error handling for stripe api
* Forwarding all errors
* Refactored stripe api into modules
* Ensured the ready promise object is not replaced
* Added logging setup
- Sets up common logger structure with custom logger passed through
* Ensure logger is kept in module state
* Renamed updateLogger to setLogger
* Removed `logger` param and exposed setLogger method
* Ensured different ids used for test mode
* Ensure setLogger works for prototype methods
* Removed reconfigureSettings method
* Updated payment processer service to keep static ready promise
* Added eventemitter to member api instance to handle errors
* Moved logging of errors to http level
no-issue
This was the original design, to make it easy to incorporate into
another application, but the URL structure in Ghost did not allow for
it, we've since learnt that the URL structure _should_ be how it is
here, so we can export a router with both the auth endpoints and the
static files for the gateway
no-issue
Plans are distinct from subscriptions, as in theory a subscription could
have many plans. These moves the construction of the plans array into
the getMember function so that every consumer has access to the same
data.
* Members: disabled signup button during signup
* Members: disabled non-Stripe signup button during signup
* Members: added check to Log in button logged in state
* Updated close animation speed for members pages
* Updated responsive styles for members mobile screens
* Adding spinner CSS to members pages
* Adding members signup complete page
* Removed support for cookies in members auth middleware
no-issue
The members middleware will no longer be supporting cookies, the cookie
will be handled by a new middleware specific for serverside rendering,
more informations can be found here:
https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5
* Removed members auth middleware from site app
no-issue
The site app no longer needs the members auth middleware as it doesn't
support cookies, and will be replaced by ssr specific middleware.
https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5
* Added comment for session_secret setting
no-issue
We are going to have multiple concepts of sessions, so adding a comment
here to be specific that this is for the Ghost Admin client
* Added theme_session_secret setting dynamic default
no-issue
Sessions for the theme layer will be signed, so we generate a random hex
string to use as a signing key
* Added getPublicConfig method
* Replaced export of httpHandler with POJO apiInstance
no-issue
This is mainly to reduce the public api, so it's easier to document.
* Renamed memberUserObject -> members
no-issue
Simplifies the interface, and is more inline with what we would want to export as an api library.
* Removed use of require options inside members
no-issue
This was too tight of a coupling between Ghost and Members
* Simplified apiInstance definition
no-issue
* Added getMember method to members api
* Added MembersSSR instance to members service
* Wired up routes for members ssr
* Updated members auth middleware to use getPublicConfig
* Removed publicKey static export from members service
* Used real session secret
no-issue
* Added DELETE /members/ssr handler
no-issue
This allows users to log out of the theme layer
* Fixed missing code property
no-issue
Ignition uses the statusCode property to forward status codes to call sites
* Removed superfluous error middleware
no-issue
Before we used generic JWT middleware which would reject, now the
middleware catches it's own error and doesn't error, thus this
middleware is unecessary.
* Removed console.logs
no-issue
* Updated token expirty to hardcoded 20 minutes
no-issue
This returns to our previous state of using short lived tokens, both for
security and simplicity.
* Removed hardcoded default member settings
no-issue
This is no longer needed, as defaults are in default-settings.json
* Removed stripe from default payment processor
no-issue
* Exported `getSiteUrl` method from url utils
no-issue
This keeps inline with newer naming conventions
* Updated how audience access control works
no-issue
Rather than being passed a function, members api now receives an object
which describes which origins have access to which audiences, and how
long those tokens should be allowed to work for. It also allows syntax
for default tokens where audience === origin requesting it. This can be
set to undefined or null to disable this functionality.
{
"http://site.com": {
"http://site.com": {
tokenLength: '5m'
},
"http://othersite.com": {
tokenLength: '1h'
}
},
"*": {
tokenLength: '30m'
}
}
* Updated members service to use access control feature
no-issue
This also cleans up a lot of unecessary variable definitions, and some
other minor cleanups.
* Added status code to auth pages html response
no-issue
This was missing, probably default but better to be explicit
* Updated gateway to have membersApiUrl from config
no-issue
Previously we were parsing the url, this was not very safe as we can
have Ghost hosted on a subdomain, and this would have failed.
* Added issuer to public config for members
no-issue
This can be used to request SSR tokens in the client
* Fixed path for gateway bundle
no-issue
* Updated settings model tests
no-issue
* Revert "Removed stripe from default payment processor"
This reverts commit 1d88d9b6d73a10091070bcc1b7f5779d071c7845.
* Revert "Removed hardcoded default member settings"
This reverts commit 9d899048ba7d4b272b9ac65a95a52af66b30914a.
* Installed @tryghost/members-ssr
* Fixed tests for settings model
no issue
- Added new API to delete members
- Added methods to handle e2e member deletion
- Deleting member via Admin leads to
- Removal of member from payment processor and cancelling all active subscriptions immediately
- Removal of member information from DB
no-issue
- Added member auth middleware to siteApp
- Passed member as context in routing service
- set Cache-Control: private for member requests
- fucked up some tests
- Added member as global template variable
- Updated tokens to have expiry of subscription_period_end
no-issue
* Corrected function names for rpc methods
* Updated gateway to store tokens locally
* Fixed lint
* Added hardcoded 30 minute expiry for member tokens
* Added default contentApiAccess config;
* Updated validateAudience method
This is required for security, we need to restrict which domains can access
tokens meant for the content api
no-issue
* Added getPublicConfig method to stripe payment processor
* Added getPublicConfig method to subscriptions service
* Added initial config endpoint for members api
* Added getConfig method to members gateway
These changes introduce a new "service" to the members api, which handles getting and creating subscriptions.
This is wired up to get subscription information when creating tokens, and attaching information to the token, so that the Content API can allow/deny access.
Behind the subscription service we have a Stripe "payment processor", this holds the logic for creating subscriptions etc... in Stripe.
The logic for getting items out of stripe uses a hash of the relevant data as the id to search for, this allows us to forgo keeping stripe data in a db, so that this feature can get out quicker.
no-issue
* Used camelCase for gateway method calls
* Added some components for building blocks of forms
* Added input specific components
* Added Form component
This handles collecting the data to submit and sharing state between forms
* Added Pages component to handle urls
* Added the pages for the popup
* Added MembersProvider component
This is designed to give its children access to gateway methods
* Added Modal component
This wraps the pages and handles dispatching form submissions to the members gateway
* Refactored index.js to use new components/pages
* Fixed default page from Signup -> Signin
* Update mobile modal animations
* Member popup input error and placeholder refinements
* Adding close animation to members auth popups
* Improve members auth dialog
* Refine members reset password design
no-issue
the ssoOriginCheck exists to ensure that we only allow signin/signup to
be called from the specified auth page, this is a very minor security
feature in that it forces signins to go via the page you've designated.
signout however does not need this protection as the call to signout
completely bypasses any UI (this is the same for the call to /token)
* Added members library inc. gateway
refs #10213
* Added the auth pages and build steps for them
refs #10213
* Cleaned up logs
* Updated gruntfile to run yarn for member auth
* Design refinements on members popups
* UI refinements
* Updated backend call to trigger only if frontend validation passes
* Design refinements for error messages
* Added error message for email failure
* Updated request-password-reset to not attempt to send headers twice
* Updated preact publicPath to relative path
* Build auth pages on init
