Skip to content

Integrate the backend infrastructure for a premium version of ABP

Background / User story

We're aiming to offer a premium version of ABP to our users, with more benefits than the existing free solution.

One of the pre-requisites for offering this is having the backend infrastructure that allows us to handle:

  • licensing
  • showing active/inactive states on premium features, depending on whether or not the user has upgraded or should still have access to them

Additionally, as requested by the Web team while discussing the Premium license activation flow for #985 (closed) (see internal discussion), users who want to upgrade to Premium should be directed to the /premium page instead of /upgrade that we configured in #981 (closed).

What to change

Hints for testers

Target branch: feature-premium-1.0

Notes

  • The builds use the production URLs, which aren't online yet though. Until then, they can be replaced with staging URLs by modifying the following files:
    • adblockpluschrome/build/manifest.base.json
    • adblockpluschrome/lib/prefs.js
    • src/premium/content/activation.ts
  • The current implementation doesn't react to changes to the "premium_license" preference yet. This preference should only be modified indirectly via the "payment_success" event from accounts.adblockplus.org/*/premium, or the "premium.activate" message from a UI page.

Noteworthy cases

  • UI pages (i.e. desktop settings page and icon popup) should initialize and react to Premium state changes as expected.
  • There should be no regressions to #1092 (closed).
  • No daily license checks should occur unless the user has an active license.
  • The "payment_success" event should be ignored, unless it was dispatched on and from accounts.adblockplus.org/*/premium.
  • The extension shouldn't dispatch the "ack" event on accounts.adblockplus.org/*/premium, if it failed to activate the license.
  • No permission warnings should be shown (due to the newly added "alarms" permission) when upgrading from an older extension version.
  • License checks
    • License should get deactivated on:
      • fetch() error
      • HTTP 4XX server error
      • Non-JSON server response
      • Invalid license (i.e. version is not 1, status is "expired" or any other value that's not "active")
    • Check should be retried on:
      • HTTP 5XX server error
      • No network connection
    • Check should not be retried on:
      • Other HTTP server error
  • There should be no more than three license checks retries for each daily license check.
  • Daily license checks and license checks retries should work in Manifest v3 (i.e. across service worker restarts).
  • Daily license checks should work across extension restarts.

Hints for translators

N/A

Edited by Thomas Greiner