MokoConsulting/MokoGitea
1
0
Fork 0
Code Issues 143 Pull Requests Releases 96 Wiki Activity

feat(licenses): domain lock grace period — configurable time before domain binding #394

New Issue
Closed
opened 2026-06-01 10:01:07 +00:00 by jmiller · 2 comments
jmiller commented 2026-06-01 10:01:07 +00:00
Owner
Copy Link
Copy Source

Summary

Add DomainLockHours to packages and FirstUsedUnix to keys. During the grace period after first use, any domain is accepted and auto-added. After expiry, only listed domains allowed.

Implementation (done in dev)

  • DomainLockHours int on LicensePackage (0 = immediate lock)
  • FirstUsedUnix on LicenseKey (set on first TouchHeartbeat)
  • Grace period logic in ValidateLicenseKey domain check
  • UI field in create/edit package forms

Test Plan

  • Set DomainLockHours=48 on package, generate key
  • Validate with domain A → accepted, domain added
  • Validate with domain B within 48h → accepted, domain added
  • Validate with domain C after 48h → rejected
  • Set DomainLockHours=0 → immediate lock on first use

🤖 Generated with Claude Code

## Summary Add `DomainLockHours` to packages and `FirstUsedUnix` to keys. During the grace period after first use, any domain is accepted and auto-added. After expiry, only listed domains allowed. ## Implementation (done in dev) - `DomainLockHours int` on `LicensePackage` (0 = immediate lock) - `FirstUsedUnix` on `LicenseKey` (set on first TouchHeartbeat) - Grace period logic in `ValidateLicenseKey` domain check - UI field in create/edit package forms ## Test Plan - [ ] Set DomainLockHours=48 on package, generate key - [ ] Validate with domain A → accepted, domain added - [ ] Validate with domain B within 48h → accepted, domain added - [ ] Validate with domain C after 48h → rejected - [ ] Set DomainLockHours=0 → immediate lock on first use 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jmiller commented 2026-06-01 10:12:19 +00:00
Author
Owner
Copy Link
Copy Source

Testing Plan — Domain Lock Grace Period

API

  • Create package with DomainLockHours=48
  • Generate key, validate with domain A → accepted, FirstUsedUnix set
  • Validate with domain B (within 48h) → accepted, domain B added to restriction
  • Validate with domain C (after 48h grace) → rejected "domain not allowed"
  • DomainLockHours=0 → immediate lock: second domain rejected immediately
  • Validate without domain param → no domain check (passes)
  • Master/internal keys bypass domain lock entirely

GUI

  • Domain lock hours field in create package form
  • Domain lock hours field in edit package form with current value
  • Help text: "Hours after first use before the key locks to its domain(s). 0 = lock immediately."

🤖 Generated with Claude Code

## Testing Plan — Domain Lock Grace Period ### API - [ ] Create package with DomainLockHours=48 - [ ] Generate key, validate with domain A → accepted, FirstUsedUnix set - [ ] Validate with domain B (within 48h) → accepted, domain B added to restriction - [ ] Validate with domain C (after 48h grace) → rejected "domain not allowed" - [ ] DomainLockHours=0 → immediate lock: second domain rejected immediately - [ ] Validate without domain param → no domain check (passes) - [ ] Master/internal keys bypass domain lock entirely ### GUI - [ ] Domain lock hours field in create package form - [ ] Domain lock hours field in edit package form with current value - [ ] Help text: "Hours after first use before the key locks to its domain(s). 0 = lock immediately." 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jmiller added the pending: testing label 2026-06-01 10:13:56 +00:00
jmiller reopened this issue 2026-06-02 11:21:44 +00:00
jmiller commented 2026-06-03 00:39:46 +00:00
Author
Owner
Copy Link
Copy Source

Tested and verified in production on MokoWaaS. All three download gating modes (none/prerelease/all), feed visibility, XML metadata, download URLs, and access control confirmed working.

Tested and verified in production on MokoWaaS. All three download gating modes (none/prerelease/all), feed visibility, XML metadata, download URLs, and access control confirmed working.
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
 pending: testing
Feature implemented but not yet tested with documented proof
 priority: critical
Must fix immediately
 priority: high
Important, fix soon
 priority: low
Nice to have
 priority: medium
Normal priority
 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
 status: blocked
Blocked by dependency or decision
 status: in-progress
Actively being worked on
 status: needs-review
Awaiting code review
 status: on-hold
Paused intentionally
 status: wontfix
Will not be addressed
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 type: bug
Something isn't working
 type: bug
type: chore
Maintenance, dependencies, cleanup
 type: enhancement
Improvement to existing feature
 type: feature
New functionality
 type: refactor
Code restructuring without behavior change
 type: version
Version bump or release
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
bug
Something is not working
 chore
Maintenance and housekeeping
 documentation
Documentation improvements
 enhancement
Improvement to existing functionality
 feature
New feature or request
 pending: dependency
Blocked by another issue or external dependency
 pending: deployment
Tested and approved, awaiting deployment to production
 pending: design
Needs UI/UX or architecture design before implementation
 pending: documentation
Feature works, needs documentation/wiki update
 pending: feedback
Awaiting feedback or decision from stakeholder
 pending: review
Implementation complete, awaiting code review
 pending: testing
Feature implemented but not yet tested
 priority: critical
Must fix immediately
 priority: high
Should fix soon
 priority: low
Nice to have
 priority: medium
Fix when convenient
 refactor
Code restructuring without behavior change
 roadmap
Planned feature or enhancement tracked on the roadmap
 scope: client
Client-specific work
 scope: dolibarr
Dolibarr modules and customizations
 scope: infrastructure
Server, CI, backups, monitoring
 scope: joomla
Joomla templates and extensions
 scope: waas
MokoWaaS platform
 security
Security vulnerability or hardening
 status: blocked
Waiting on external dependency
 status: duplicate
Duplicate of another issue
 status: in-progress
Being worked on
 status: needs-review
Ready for review
 status: wontfix
Will not be addressed
No labels pending: testing
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#394
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?