Skip to content

Releases: DailenG/CheckDeployManager

v0.6.4

Choose a tag to compare

@DailenG DailenG released this 10 Jul 00:12

Inherited baseline rules, visible where you edit

Each tenant's Rules draft tab now shows the instance baseline delta in a collapsed read-only inherited panel above the editor: the summary line carries the counts (exclusion patterns, trusted login patterns, suppressed ids, added indicators), and expanding it shows the full patterns in grayed blocks. Operators editing a tenant see what already applies beneath the draft without switching to the Settings page. The baseline rides along on the tenant detail response (baseline, null when none is configured).

Check-default branding opt-out now covers the color

Use Check's default logo becomes Use Check's default logo and color: while a tenant is opted out, artifact generation also pins primaryColor to Check's default #F77F00, beating both the tenant's stored color and the instance default. The stored color is kept, not cleared, so lifting the opt-out restores it. The button is also offered on the Branding tab regardless of whether an instance default logo exists (previously it was hidden when the choice was a no-op today, which read as a missing feature -- opting out also pins the tenant against defaults added later).

GPO deployment quality-of-life

  • Export-CheckGpoConfig.ps1 is downloadable from the onboarding wizard. The GPO-migration helper is bundled into the Worker and served behind the operator gate, so the adopt-config panel links it directly instead of pointing at the repo.
  • The generated GPO install script retries while SYSVOL settles. New-GPO can return before the new GPO's SYSVOL folder permissions have propagated, so the first Set-GPRegistryValue could die with access denied (hit on a real DC). All registry writes now retry access-denied briefly (5 attempts, 3 seconds apart) before treating it as real; other errors still fail fast. Download a fresh copy from the Artifacts tab to pick this up.

Documentation

Refreshed the tenant Rules and Branding screenshots, the runbook (baseline visibility, Check-default branding, GPO migration download), and the full GitNexus wiki.

Upgrading

From a deploy-button copy, run the Sync upstream workflow from the Actions tab, or git pull and npm run deploy. No new D1 migration in this release (if you are coming from v0.6.2 or earlier, the deploy applies v0.6.3's 0002_use_default_logo.sql automatically). No workflow-file changes.

Full changelog: v0.6.3...v0.6.4

v0.6.3

Choose a tag to compare

@DailenG DailenG released this 09 Jul 20:06

Use Check's default logo, at either level

Branding gains an explicit third logo state alongside "custom logo" and "inherit the instance default": show the Check extension's own built-in logo.

  • Per tenant: a Use Check's default logo button on the Branding tab opts the tenant out of the instance default logo entirely. Its asset URL stops serving and generated artifacts carry an empty logoUrl, so the extension falls back to its built-in logo. Uploading a logo, or removing one to go back to inheriting, clears the opt-out; while opted out, an Inherit the instance default logo button returns to normal inheritance.
  • Instance-wide: the Settings page now states the no-default-logo state explicitly (tenants without their own logo show Check's built-in logo) and presents default-logo removal as Use Check's default logo.
  • The choice is stored in a new use_default_logo column on tenant_branding (migration 0002_use_default_logo.sql), settable through PUT /api/tenants/{id}/branding as use_default_logo: true|false (JSON or form field), and recorded in the audit log.

Covered by an end-to-end API test (opt out -> asset 404 and empty artifact logo URL -> upload clears the flag -> removal returns to inheriting) and an artifact-builder unit test.

Upgrading

This release includes a D1 migration (0002_use_default_logo.sql). From a deploy-button copy, run the Sync upstream workflow from the Actions tab; Workers Builds redeploys with npm run deploy, which applies the migration automatically. Or git pull and npm run deploy. No workflow-file changes.

Full changelog: v0.6.2...v0.6.3

v0.6.2

Choose a tag to compare

@DailenG DailenG released this 08 Jul 12:41

Guided editor on the baseline rules delta

The instance-wide Baseline rules delta (Settings page) now uses the same guided editor as a tenant's Rules draft, instead of a bare JSON textarea:

  • Easy add pattern builder: type a plain domain (or paste a URL) and it produces the anchored regex, subdomain coverage optional
  • one-entry-per-line fields for exclusion patterns, trusted login patterns, and suppressed indicator ids
  • an Advanced JSON block for added indicators and raw overrides, and a raw-JSON toggle for the whole delta
  • a summary of what the saved baseline contains, with an unsaved-edits badge

Under the hood the editor is now shared code (deltaEditorHtml / wireDeltaEditor), so the tenant and baseline editors cannot drift; the tenant Rules draft keeps its published-version diff and behaves exactly as before. The suppressed-ids hint was made context-neutral so it reads correctly in both places.

Documentation

The README's "What it does" section was rewritten for scanability: three headline paragraphs with real sub-lists, replacing three run-on sentences that had accreted a clause per feature. The runbook's baseline section and the affected screenshots were refreshed.

Upgrading

From a deploy-button copy, run the Sync upstream workflow from the Actions tab, or git pull and npm run deploy. No D1 migration and no workflow-file changes; the one-click sync applies cleanly.

Full changelog: v0.6.1...v0.6.2

v0.6.1

Choose a tag to compare

@DailenG DailenG released this 08 Jul 01:25

Migrating from the official Check GPO

The headline: clients already running Check through a GPO built with the official ADMX templates no longer retype anything. A new read-only tool, scripts/Export-CheckGpoConfig.ps1, runs on a domain controller (RSAT), asks for the GPO's name, and exports the Check policy values (Chrome hive, Edge fallback) as JSON. Paste that into the tenant onboarding wizard's Migrating from the official Check GPO? panel and the branding and policy values are adopted into the tenant; the old rules URL is ignored, since the tenant's own config URL replaces it. The GPO is never modified.

Hardening from a real migration: Get-GPRegistryValue returns REG_SZ values with their trailing NUL terminators attached, which rode into saved allowlist entries as invisible characters that would silently break pattern matching. Sanitization now happens at three layers - the export script trims at the source, the adopt panel deep-cleans every pasted string, and every URL-allowlist save path (wizard, Policy tab, Tenant defaults) strips control characters, so simply re-saving an affected list heals it.

Onboarding wizard, clearer

A wording and state pass grounded in first real use:

  • The wizard opens by naming its two delivery channels: detection rules are fetched by browsers from this service, while policy, branding, and the rules URL itself are deployed to devices; steps carry matching deployed with policy / fetched remotely badges.
  • Step 3's description now matches what actually renders (the CIPP tenant id field only appears when CIPP reporting is on).
  • Optional steps wear an optional badge instead of nagging amber, the deploy step completes together with verification, and the verify step no longer implies the config URL is something you visit by hand.
  • An Onboard wizard link now leads every tenant's tab strip, so the wizard is reachable at any stage.

Upgrading

From a deploy-button copy, run the Sync upstream workflow from the Actions tab, or git pull and npm run deploy. No D1 migration and no workflow-file changes; the one-click sync applies cleanly. If you adopted a GPO export before this release and see stray trailing characters in the URL allowlist, re-paste the same JSON in the wizard's migration panel or simply re-save the Policy tab; both now scrub them.

Full changelog: v0.6.0...v0.6.1

v0.6.0

Choose a tag to compare

@DailenG DailenG released this 07 Jul 22:50

Tenant onboarding wizard

The headline of this release: the setup wizard onboards the instance, and now a second wizard onboards each tenant. After creating a client you no longer face six tabs and an implied ordering; Onboard wizard on the tenant list (next to New tenant, so the choice is yours) walks the whole path:

  1. Tenant created - GUID and preview token minted, confirmation shown
  2. Branding (optional) - effective values with inherited-from-defaults badges
  3. Policy essentials - URL allowlist and CIPP tenant id editable inline; everything else stays on the Policy tab
  4. Rules delta (optional) - an Easy add row that builds the pattern regex from a plain domain and writes it straight into the saved draft
  5. Publish - validation gates surfaced inline
  6. Deploy to browsers - a method picker rendering one concise checklist per path (RMM script, managed storage JSON, .reg import, GPO script, Firefox policies.json, Intune, CIPP standard) with the matching artifact download inline
  7. Verify - watches for the tenant's first rules fetch and closes the loop

Every step badge derives from live server state, so the wizard is resumable and safe with several operators working at once; tenants that never published show a Continue onboarding button. Method choice is cosmetic and never stored - all artifacts remain on the Artifacts tab.

One honest label: the Intune checklist ships as untested guidance (documentation parity with Check's own deployment docs; no Intune tenant was available to verify). Reports welcome.

Under the hood

  • The tenant detail response now includes last_fetch_at, feeding the wizard's verify step (covered by a test).
  • README features, screenshot gallery (new onboarding wizard capture), architecture API table, runbook, and the generated code wiki are all refreshed.

Upgrading

From a deploy-button copy, run the Sync upstream workflow from the Actions tab, or git pull and npm run deploy. No D1 migration is required; no workflow files changed in this release, so the one-click sync applies cleanly.

Full changelog: v0.5.1...v0.6.0

v0.5.1

Choose a tag to compare

@DailenG DailenG released this 07 Jul 21:32

Deployment visibility: pinned toolbar icon and an RMM-ready script

A managed security extension users cannot see is one they cannot act on, so every registry-based artifact now force-pins Check to the toolbar: Chrome via toolbar_pin=force_pinned, Edge via its own spelling toolbar_state=force_shown, both derived from the shared registry-writes table so the .reg files and GPO script can never drift (Firefox was already pinned via default_area: navbar).

  • RMM deployment script (check-rmm-deploy.ps1): a new standalone PowerShell artifact built for RMM platforms running as SYSTEM. It force-installs, pins, and writes the tenant's full policy and branding to HKLM for Chrome and Edge, and drops the Firefox distribution\policies.json (backing up any existing one, written BOM-free). Checkboxes on the Artifacts tab preset the three $Include* browser toggles before download, and they stay plain editable variables afterward. Parses clean on PowerShell 5.1 and 7.

Guided rules editing

The Rules draft tab grew from a bare JSON textarea into a guided editor:

  • Easy add, front and center: type a plain domain (or paste a URL), choose exclusion or trusted-login, and the anchored regex is generated for you, with subdomain coverage optional. No regex knowledge needed for the common case.
  • The common delta keys are one-entry-per-line fields; added indicators and raw overrides live under an Advanced JSON block, and Edit raw JSON still exposes the whole delta as one document.
  • An effect summary describes the saved draft and diffs it against the currently published version ("+1 trusted login pattern vs published v1", items on hover).
  • Publish guard: Publish ships the last saved draft, and now warns when the editor holds unsaved edits.
  • The Policy tab opens with a deployed with policy banner making the split explicit: policy settings ship inside the deployment artifacts and need a policy re-push, while rules content is fetched remotely on the update interval.

Setup wizard

  • The branding-defaults step gains primary color and the instance default logo upload.
  • Entering a Default CIPP server URL now also enables the fleet-wide CIPP reporting default (unless already decided), so the URL actually reaches artifacts instead of sitting inert behind a per-tenant switch.
  • The header brand links to the tenant list.

Deploy-button copies: CI and operations fixes

Running a real deploy surfaced several rough edges, all fixed:

  • workers_dev and preview_urls are declared explicitly in wrangler.jsonc, resolving two deploy warnings; preview URLs stay off because their hostnames are never covered by the Access application.
  • Copy CI is now expected green: the fail-closed tests pin their own Access values, the hygiene UUID check exempts wrangler.jsonc (your provisioned database id lives there), and CodeQL skips itself on private repos.
  • The runbook documents the deploy-button realities: workflows are stripped from fresh copies (one-time bootstrap required before the Sync upstream workflow exists), releases that change workflow files need a manual update pass, and Dependabot version updates should be disabled on copies.

Documentation

  • New monitoring guide (docs/monitoring.md): which failure modes the dashboard catches (revoked-GUID stragglers, stale fetches) versus which only Cloudflare's tools can see (typo'd GUID 404 drumbeats, enumeration probes, fleet-volume drops), with Workers Logs recipes and a suggested cadence.
  • New implementation plan for deployment health signals (docs/plans/deployment-health.md) covering the fetch sparkline, health verdicts, and an Analytics Engine dataset.
  • Backlog: scoped items for the tenant onboarding wizard (top priority), a primary-color swatch with picker, and Sync upstream token support.
  • Wizard, rules, policy, and artifacts screenshots recaptured; wiki regenerated.

Upgrading

From a deploy-button copy, run the Sync upstream workflow from the Actions tab, or git pull and npm run deploy. Copies created before this release have no workflows at all (the deploy button cannot push them); see the runbook's one-time bootstrap under "Updating a deployed instance". No D1 migration is required.

Full changelog: v0.4.0...v0.5.1

v0.4.0

Choose a tag to compare

@DailenG DailenG released this 04 Jul 21:23

Tenant defaults: set MSP-standard values once, inherit everywhere

The headline of this release is instance-level inheritance. Values you set once now reach every tenant that has not overridden them, resolved live at artifact generation time — never copied into tenant rows, so a fleet-wide change is a single edit.

  • Branding and policy defaults (Settings > Tenant defaults): standard support info, product name, primary color, and policy values (update interval, page blocking, allowlist, domain squatting, webhook, CIPP toggle). A blank tenant branding field inherits; a policy key the tenant never set inherits. CIPP tenant ids never inherit.
  • Instance default logo: served through each tenant's stable /assets/{guid}/logo URL whenever the tenant has no logo of its own — already-deployed policies pick up a new default logo with no policy change.
  • Inherited-field badges: the Branding and Policy tabs mark inherited fields and show the inherited value; saving the Policy tab keeps a field inherited while its value still matches the default, so tenants follow future default changes until you deliberately override.
  • Baseline rules delta (Settings > Baseline rules delta): an instance-level rule delta (standard MSP exclusions such as RMM domains) merged beneath every tenant delta at publish and preview time. Tenants can suppress baseline-added indicators; duplicate ids are caught by the validation gates. Republish all tenants rolls a baseline change out to the whole fleet immediately.
  • Duplicate tenant: creates a fresh tenant carrying only the source's rules delta draft — branding and policy intentionally inherit instead of copying.
  • Setup wizard: gains an optional "Standard branding defaults" step (now six steps).

Documentation

  • Runbook: new sections for tenant defaults (with the propagation caveat), the baseline delta, and tenant duplication, with embedded screenshots.
  • Architecture doc updated to the current data model, endpoints, and inheritance design.
  • All dashboard screenshots recaptured; three new views (tenant defaults editor, baseline delta editor, policy tab with inherited badges).
  • BACKLOG: the remaining roadmap items are now fully scoped and prioritized.

Upgrading

From a deploy-button copy, run the Sync upstream workflow from the Actions tab, or git pull and npm run deploy. One D1 note: no schema migration is required for this release; the new instance settings seed themselves on first read.

Full changelog: v0.3.0...v0.4.0

v0.3.0

Choose a tag to compare

@DailenG DailenG released this 03 Jul 16:07

GPO deployment artifacts

The Artifacts tab now renders a ready-to-run GPO creation script per tenant: a New-GPO / Set-GPRegistryValue PowerShell script that creates or updates a named GPO carrying the force-install and managed storage values for both Chrome and Edge, then prints the New-GPLink command to run when you are ready to link an OU. The script and the .reg files derive from one shared registry-writes table, so they are provably in sync (locked by golden tests). Links to Check's upstream ADMX/ADML templates (pinned at Check v1.1.0) sit alongside for once-per-domain import.

Webhook relay for false positives

Set the new False positive relay URL instance setting and every report the extension POSTs to /hook/{guid} is forwarded as JSON to your automation platform (n8n, Power Automate, or any webhook receiver) with tenant id and name included for ticket routing. Best effort by design: one attempt after the durable inbox insert, https only, and a dead relay never delays the reporting extension.

Version footer and update path

The dashboard footer shows the running version, links to releases, and flags newer releases (checked from your browser, never the Worker). The runbook gains an Updating a deployed instance section covering the deploy-button copy and local clone paths.

Also

  • Artifacts warn when CIPP reporting is enabled without a tenant id or domain (unattributed events), with a note on when empty is fine (CIPP standard deployments).
  • The CIPP tenant field label explains the same on the Policy tab.

Full changelog: v0.2.0...v0.3.0

v0.2.0

Choose a tag to compare

@DailenG DailenG released this 03 Jul 14:35

First-login setup wizard

A fresh deployment now opens a guided setup wizard on first login, covering everything after the Cloudflare-side runbook steps:

  1. Environment check: confirms your operator identity and ENVIRONMENT, and warns if the development bypass is active on a non-localhost origin. Reaching the page at all proves Access and in-Worker JWT validation are working.
  2. Instance settings: just the values artifact generation needs (public base URL prefilled from the page origin, version suffix label, optional CIPP server URL).
  3. First upstream sync with the snapshot version and fetch time on success.
  4. Tenant zero: creates your first tenant and publishes its default ruleset in one click.
  5. Deploy and verify: points at the Artifacts tab and explains end-to-end verification via the fetch counter.

Every step's badge derives from live server state, so the wizard is resumable, idempotent, and safe with multiple operators. The top nav stays fully usable throughout, Skip for now dismisses it permanently, and instances upgrading from v0.1.0 never see it.

Also in this release

  • GET /api/instance/status: aggregate first-run status endpoint backing the wizard
  • CodeQL scanning on push, pull request, and a weekly schedule
  • Issue templates that enforce the no-real-client-data rule up front
  • Dashboard screenshots in the README, including the wizard

Full changelog: v0.1.0...v0.2.0

v0.1.0

Choose a tag to compare

@DailenG DailenG released this 03 Jul 14:10

First tagged release of CheckDeployManager, a multi-tenant configuration service for the Check by CyberDrain browser extension, hosted entirely on Cloudflare Workers.

Highlights

  • Rules host: mirrors upstream CyberDrain detection rules daily, layers per-tenant deltas (exclusions, trusted patterns, custom indicators, suppressions), validates every merge, and serves immutable published rulesets at unguessable per-tenant URLs.
  • Policy generator: renders ready-to-deploy artifacts per tenant: Chrome and Edge managed storage JSON, Firefox policies.json (fragment and full), .reg files for GPO, the Intune setup script variable block, and CIPP deployment field values.
  • Operations dashboard: draft and publish with validation gates, one-click rollback, GUID rotation and revocation with hit counters, tenant branding with logo hosting, webhook inbox for false positive reports, upstream diff history, and an indefinite audit log.
  • Deploy to Cloudflare button provisioning D1 and R2 automatically, comfortably inside the free tier at a few thousand endpoints.
  • Types are generated from the Worker configuration (wrangler types), with CI enforcing freshness, typecheck, tests, and repository hygiene rules.

See the README for screenshots and the post-deploy runbook, and docs/architecture.md for the full design and threat model.