MokoConsulting/MokoGitea-APP
1
0
Fork 0
Code Issues 158 Pull Requests 5 Releases 96 Wiki Activity

feat(licenses): heartbeat mode — validate license key on first registration with domain matching #363

New Issue
Closed
opened 2026-05-31 16:26:21 +00:00 by jmiller · 1 comment
jmiller commented 2026-05-31 16:26:21 +00:00
Owner
Copy Link
Copy Source

Summary

Add a "heartbeat mode" option that validates license keys on first registration (initial install/activation) and optionally enforces domain matching on subsequent heartbeats.

Behavior

First Registration

When an extension first contacts the update server with a license key:

  1. Validate the key is active and not expired
  2. If domain matching is enabled, lock the key to the requesting domain
  3. Record the registration event (IP, domain, user-agent, timestamp)
  4. Return success with license metadata (package name, channels, expiry)

Subsequent Heartbeats

On periodic check-ins (update checks, daily heartbeats):

  1. Re-validate the key is still active and not expired
  2. If domain matching is enabled, verify the domain matches the registered one
  3. Update last_heartbeat timestamp
  4. If key has been revoked/expired since registration, return invalid

Domain Matching Option

A per-key or per-package setting:

  • Off: Key works from any domain (current default behavior)
  • Lock on first use: Domain is auto-set on first heartbeat (already implemented)
  • Strict matching: Every heartbeat must come from a registered domain, reject mismatches immediately

Configuration

Add to package or key settings:

  • : none | register_once | periodic (default: periodic)
  • : none | lock_on_first_use | strict (default: lock_on_first_use)

Use Cases

  • Detect pirated/shared keys (same key from multiple domains)
  • Auto-revoke keys that haven't checked in for X days
  • Notify admin when a key is used from an unexpected domain

Claude Opus 4.6 (1M context) noreply@anthropic.com

## Summary Add a "heartbeat mode" option that validates license keys on first registration (initial install/activation) and optionally enforces domain matching on subsequent heartbeats. ## Behavior ### First Registration When an extension first contacts the update server with a license key: 1. Validate the key is active and not expired 2. If domain matching is enabled, lock the key to the requesting domain 3. Record the registration event (IP, domain, user-agent, timestamp) 4. Return success with license metadata (package name, channels, expiry) ### Subsequent Heartbeats On periodic check-ins (update checks, daily heartbeats): 1. Re-validate the key is still active and not expired 2. If domain matching is enabled, verify the domain matches the registered one 3. Update last_heartbeat timestamp 4. If key has been revoked/expired since registration, return invalid ### Domain Matching Option A per-key or per-package setting: - **Off**: Key works from any domain (current default behavior) - **Lock on first use**: Domain is auto-set on first heartbeat (already implemented) - **Strict matching**: Every heartbeat must come from a registered domain, reject mismatches immediately ## Configuration Add to package or key settings: - : none | register_once | periodic (default: periodic) - : none | lock_on_first_use | strict (default: lock_on_first_use) ## Use Cases - Detect pirated/shared keys (same key from multiple domains) - Auto-revoke keys that haven't checked in for X days - Notify admin when a key is used from an unexpected domain --- *Claude Opus 4.6 (1M context) <noreply@anthropic.com>*
jmiller commented 2026-06-02 05:01:38 +00:00
Author
Owner
Copy Link
Copy Source

Implemented across multiple commits:

  • FirstUsedUnix field on LicenseKey (set on first TouchHeartbeat)
  • Auto-domain association (lock-on-first-use) in ValidateLicenseKey
  • DomainLockHours grace period on LicensePackage
  • LastHeartbeatUnix tracking on every validation
  • IsDomainKnownForKey for efficient domain lookups
Implemented across multiple commits: - FirstUsedUnix field on LicenseKey (set on first TouchHeartbeat) - Auto-domain association (lock-on-first-use) in ValidateLicenseKey - DomainLockHours grace period on LicensePackage - LastHeartbeatUnix tracking on every validation - IsDomainKnownForKey for efficient domain lookups
Sign in to join this conversation.
Labels
Clear labels
breaking-change
Breaking API or behavior change
 ci-cd
CI/CD pipeline changes
 config
Configuration changes
 dependencies
Dependency updates
 deploy-failure
Deployment failed
 docker
Docker/container changes
 documentation
Documentation changes
 good first issue
Good for newcomers
 health-check
Repo health check result
 help wanted
Extra attention needed
 mokostandards
Related to MokoStandards framework
 push-failure
Git push operation failed
 security
Security vulnerability or hardening
 size/l
200-500 lines changed
 size/m
50-200 lines changed
 size/s
10-50 lines changed
 size/xl
500+ lines changed
 size/xs
< 10 lines changed
 standards-drift
Deviates from MokoStandards
 standards-update
MokoStandards compliance update
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
No labels
Priority Medium
Type Feature
Status —
Priority —
Type —
Milestone
No items
No Milestone
Assignees
Clear assignees
jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-APP#363
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?