Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify current domain ownership #43

Open
jgryffindor opened this issue Oct 25, 2023 · 1 comment
Open

Verify current domain ownership #43

jgryffindor opened this issue Oct 25, 2023 · 1 comment
Assignees

Comments

@jgryffindor
Copy link
Contributor

It's possible for a user to re-use an existing A record of a domain that no longer has an active site, but the record was left in place.

Describe the solution you'd like

  • To prevent this when creating a site, users should be required to create a unique TXT record related to the current deployment.
  • The ingress system should verify the A Record, www CNAME, and TXT record match the expected values to proceed with creating the site ingress.

Describe alternatives you've considered

  • An alternative would be a secondary system that emails the registered email on the domain.

Additional context

@fmorency fmorency transferred this issue from liftedinit/many-ghostcloud Feb 14, 2024
@fmorency fmorency changed the title As a user I should need to verify current domain ownership Verify current domain ownership Feb 14, 2024
@jgryffindor
Copy link
Contributor Author

jgryffindor commented Feb 23, 2024

Suggested design for this feature: @fmorency

  • Secret token on both ghostcloud-kube and ghostcloud-cosmos-frontend site, loaded as an env var in both apps
  • Token is used to generate a deterministic hash of the deployment, using a common library on both systems
  • Ghostcloud frontend instructs the user to create the TXT record with the hash value.
    • Only the logged-in user will be able to retrieve the generated hash from their dashboard
    • The hash is visible on a deployment create/edit popup, or in the deployments table (tbd)
  • Ghostcloud-kube verifies the hash exists as a TXT record before creating the domain
    • Once a domain has successfully been used, we can prevent creation on both sides
    • Frontend: When creating a domain, do a check for an existing A record for the load balancer. If it exists with a TXT that also conforms to the hash requirements, then prevent the user from attaching that custom domain.
    • Backend: When creating a domain, check to see if it exists already. Kube will prevent this as well, but we can add a check to see if the domain is already registered to an existing deployment.
  • Ghostcloud-kube can additionally verify the presence of both A records and TXT records for every ingress domain on a daily/hourly schedule and delete ingresses that no longer conform to the requirement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants