Appearance

web-app ​

0.2.4 ​

Patch Changes ​

0.2.3 ​

Patch Changes ​

  • b91b948: Let a license linked to a Webflow project choose which of its domains it records, from the license page or the project's Billing tab, with a Webflow domain sync beside the picker, and reopen the Domains settings tab for Webflow projects as sync-only.
  • Updated dependencies [e73fae1]

0.2.2 ​

Patch Changes ​

0.2.1 ​

Patch Changes ​

0.2.0 ​

Minor Changes ​

  • 0ef3fd1: Move Consent Pro checkout and licenses into the web app. New v3 endpoints: GET /v3/billing/plans, POST /v3/billing/checkout-session, GET /v3/billing/licenses[/:id], PUT|DELETE /v3/billing/licenses/:id/domain and POST /v3/billing/licenses/:id/portal-session. Domain changes are written to the Stripe subscription's site_id / site_hostname metadata, so both the Consent Pro and My Account webhooks sync them. Licenses can be linked to a project with PUT /v3/billing/licenses/:id/project, which writes the project's site_id / site_hostname (and project_id) to Stripe metadata; the webhook links the project matching that site_id and clears it when the metadata is cleared. A linked license's domain can't be edited by hand. The web app gets a workspace Licenses page, a license detail page, and an in-app plan picker in place of the My Account deep link.

    Add GET /v3/projects/:id/billing (plan, next payment, billing details and invoices from Stripe, for a subscription billed to the workspace's customer) and POST /v3/projects/:id/billing/portal-session. The project Billing page now lets you choose a plan, review it, pay on Stripe in a new tab while the page waits for the plan to activate, and then shows the active plan, next payment, billing details and invoices. Checkout started from a project returns to that project's billing page.

Patch Changes ​

0.1.6 ​

Patch Changes ​

  • 4e1b094: Admin project preview now opens from a site id as well as a project id. /preview/:id accepts either. The X-ConsentPro-Preview header takes a 24-hex site id and resolves it to that site's project, so support can paste whichever id they have.
  • 5ab0e74: feat: allow users to update the domain and name during onboarding
  • 3407763: Standardise v3 API errors on { error, details? } through a shared httpError helper. Status codes from thrown errors are now preserved instead of becoming 500, and only 5xx failures are logged.

0.1.5 ​

Patch Changes ​

  • 074485d: hotfix: allow deleted tracker restore

0.1.4 ​

Patch Changes ​

0.1.3 ​

Patch Changes ​

  • 2a6322e: Add a read-only project preview for Finsweet system administrators, so support can see a customer's project exactly as the customer does.

    Opening /preview/:projectId in the web app puts that project in preview for the rest of the browser session. The app shows a "Preview Mode" pill in the header with a Stop button. Every page and modal renders as it does for the project's own users. Preview ends when the admin clicks Stop or signs out, and it only applies while that project is open.

    Requests carry an X-ConsentPro-Preview header, which the server honours only for system administrators:

    RequestIn preview
    GET on the previewed projectAnswered as the project's own organization
    GET on another project, same org404
    GET /v3/projects (project list)403, since project pages load the single project
    POST /v3/projects/:id/debugger-tokenAllowed, so Preview opens the live site
    Any other write403

    In the web app, writes never leave the browser. They show a "Preview mode is read-only" warning instead. Opening the live-site preview doesn't tick the customer's "banner previewed" checklist step.

  • bb844a5: Add a Corner style option to banner styling for custom sites, switching the banner between its default, rounded and square corners.

    The web app's banner style step gains a Corner style picker, stored per banner as corner_style and published to the runtime as style.cornerStyle. The runtime maps it to the banner's radius tokens:

    Corner styleButtons & badges (--consentpro-radius-sm)Surfaces (--consentpro-radius-md)
    DefaultSDK defaultSDK default
    Rounded999px (pill)0.75rem
    Square00

    The field is optional. Banners without it, and every Webflow site, keep the SDK's own radii.

  • ba3ce20: Update Axios and SvelteKit to patched releases and refresh vulnerable transitive dependencies.

  • b821430: feat: add endpoint to fetch project details by ID and update related queries

  • Updated dependencies [bb844a5]

  • Updated dependencies [ba3ce20]

  • Updated dependencies [c3fe401]

  • Updated dependencies [b821430]

  • Updated dependencies [9518dbb]

  • Updated dependencies [c3fe401]

0.1.2 ​

Patch Changes ​

  • f5911a6: Add an optional Pinned pages list to Custom scan settings, pinning a scan to exactly the pages listed.

    Cookies & Scripts › Scan Settings gains a Pinned pages field beside Sitemap path and Collections. It is optional and empty by default, which leaves scanning exactly as it was. List pages in it and the scan reads only those, overriding the sitemap, the collection paths and every discovery method.

    Pinned pagesWhat the scan crawls
    EmptyDiscovery as before: sitemap, then page manifest, then link crawling
    Has entriesOnly the listed pages

    Entries are paths on the project's scan base, path prefix included, so moving the project to another domain keeps them working. A pasted full URL is accepted and reduced to its path, and an entry naming another host cannot send the scan off the site. Entries are reduced to a path, so a query string is dropped.

    Applies to manual and scheduled scans started from the web app. Scans from the Webflow Designer extension, the public scan API and the admin route do not read the field and are unchanged.

    Pinned pages also decide which host the scan runs against. Redirects are still followed, but the probe is a pinned page rather than the site root, so a subdomain whose root redirects elsewhere (features.example.com/ bouncing to www.example.com) is still scanned on the host you pinned. A subdomain like that with no pinned pages is still retargeted by the root redirect.

    robots.txt still has the final say: a listed page it disallows is skipped, as with any other page.

  • Updated dependencies [f5911a6]

0.1.1 ​

Patch Changes ​

0.1.0 ​

Minor Changes ​

  • 2ebb655: Add project-scoped scan schedules on /v3/projects/:id/schedule and a Schedule scan dialog on the Cookies page. Scheduled runs now keep the project UUID so they show up in project scan history.

Patch Changes ​

  • 9a490af: Pick the "Powered by Consent Pro" logo colour from the banner background.

    consentpro-utils

    • New relativeLuminance and contrastingMonochrome helpers: WCAG 2.1 relative luminance, and a black/white pick by contrast ratio against a background.

    web-components

    • ConsentBanner's wordmark now reads --consentpro-color-attribution, falling back to the banner's own text colour. The wordmark is already currentColor, so the variable flips it; the "Powered by" label keeps the banner's text colour.

    consentpro-v2 / web-app

    • Both set --consentpro-color-attribution from the banner background, so the live banner and the style preview render the same logo.

  • d7331e4: Style the preferences toggle and the dialog backdrop from the web app.

    web-app

    • The Open preferences colours card now carries Toggle Inactive Track, Toggle Active Track (the former "Preferences Checkbox"), Toggle Circular Handle and Preferences Overlay. Left on their defaults the columns stay null, so an existing banner looks exactly as before.
    • ColorField takes an alpha prop: an opacity track under the hue slider, a checkerboard behind every swatch, and a hex field that accepts #rrggbbaa. Only the overlay opts in — a colour that paints a surface has nothing to be translucent over.
    • The overlay starts at no backdrop (#00000000). Choosing a colour on a transparent field lands at 20% opacity rather than staying invisible; the opacity track can still take it back to nothing.

    web-components

    • ConsentPreferencesDialog's backdrop default drops from 10% black to transparent: a dialog washes the page only where a site asks for it. The backdrop box is unchanged otherwise, so click-to-close still works, and any site setting --consentpro-color-overlay is unaffected.

    server / consentpro-types

    • checkbox_inactive_color, checkbox_handle_color and preferences_overlay_color are read, validated and saved on banner_settings and banner_instances, and published as checkboxInactive, checkboxHandle and preferencesOverlay. The overlay column validates #rrggbb or #rrggbbaa; the rest stay six digits.

    consentpro-v2

    • Maps those to --consentpro-color-toggle-off, --consentpro-color-toggle-thumb and --consentpro-color-overlay. The handle keeps whatever colour is picked in both switch states — nothing recolours it from the track any more.

  • Updated dependencies [fecdc78]

  • Updated dependencies [9a490af]

  • Updated dependencies [fecdc78]

  • Updated dependencies [8384efa]

  • Updated dependencies [d3e426d]

  • Updated dependencies [a580774]

  • Updated dependencies [d7331e4]

  • Updated dependencies [2ebb655]