ldraney/palinks
1
0
Fork 0
Code Issues 12 Pull requests 1 Projects Releases Packages Wiki Activity Actions

feat: add palinks.app to Rails config.hosts (#51) #53

Merged
ldraney merged 1 commit from 51-add-palinks-app-host into main 2026-06-16 00:19:38 +00:00
Conversation 2 Commits 1 Files changed 1 +2 -1
ldraney commented 2026-06-15 23:36:06 +00:00
Owner
Copy link

Summary

Add palinks.app to config.hosts in production so Rails accepts requests from the custom domain instead of returning 403 Blocked Host errors.

Changes

  • config/environments/production.rb -- added config.hosts << "palinks.app" following the same append pattern used in development.rb

Test Plan

  • Deploy to production and verify curl -I https://palinks.app returns 200 instead of 403
  • Verify existing Tailscale access still works

Review Checklist

  • Single-file change, minimal scope
  • Follows existing config.hosts << pattern from development.rb

Related Notes

None.

Related

Closes #51

## Summary Add `palinks.app` to `config.hosts` in production so Rails accepts requests from the custom domain instead of returning 403 Blocked Host errors. ## Changes - `config/environments/production.rb` -- added `config.hosts << "palinks.app"` following the same append pattern used in `development.rb` ## Test Plan - Deploy to production and verify `curl -I https://palinks.app` returns 200 instead of 403 - Verify existing Tailscale access still works ## Review Checklist - [x] Single-file change, minimal scope - [x] Follows existing `config.hosts <<` pattern from development.rb ## Related Notes None. ## Related Closes #51
Allow the custom domain palinks.app through Rails host authorization
so production accepts requests from the public domain.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ldraney commented 2026-06-15 23:37:44 +00:00
Author
Owner
Copy link

PR #53 Review

DOMAIN REVIEW

Stack: Ruby on Rails (production environment config)

The change adds config.hosts << "palinks.app" to config/environments/production.rb, activating Rails host authorization for the production domain. This is the correct fix for the 403 Blocked Host error described in #51.

Pattern consistency: The config.hosts << append pattern matches what development.rb uses for its Tailscale hosts (palinks.tail5b443a.ts.net, dev-tunnel-palinks.tail5b443a.ts.net). Correct approach.

Subdomain coverage: The PR adds only the bare domain "palinks.app". If www.palinks.app or other subdomains eventually route to this app, they will be blocked by host authorization. The commented-out Rails example on line 65 even demonstrates a regex pattern for this: /.*\.example\.com/. Not a blocker today if subdomains are not in use, but worth confirming.

Security posture: This is a security improvement. With config.hosts previously having no entries (all commented out), Rails was either rejecting everything or accepting everything depending on version defaults. Explicitly allowlisting the production domain is correct.

No test coverage concern: This is a one-line framework configuration change, not custom application logic. Rails host authorization is tested by the framework itself. The test plan (deploy, curl, verify 200 vs 403) is the appropriate validation method for this change.

BLOCKERS

None.

NITS

  1. Subdomain future-proofing (optional): Consider whether www.palinks.app or *.palinks.app subdomains will ever route here. If so, adding a regex entry now prevents a repeat of this same issue later:

    config.hosts << "palinks.app"
config.hosts << /.*\.palinks\.app/

    Not blocking -- only relevant if subdomains are planned.

  2. Tailscale host in production: development.rb explicitly allows Tailscale hostnames. If production is also accessed via Tailscale (the test plan mentions "verify existing Tailscale access still works"), you may need to add the Tailscale hostname to production hosts as well, or Tailscale-routed requests to production will start returning 403. Worth verifying during the deploy test.

SOP COMPLIANCE

  • PR body has Summary, Changes, Test Plan, Related
  • No secrets committed
  • No unnecessary file changes (single file, minimal scope)
  • Commit message is descriptive and references issue
  • Branch name follows convention (51-add-palinks-app-host)

PROCESS OBSERVATIONS

Low-risk, single-line config change. Deployment risk is minimal -- worst case is a rollback of one line. The change unblocks the custom domain chain (issue #50 set DNS, this PR makes Rails accept the host). Validate that Tailscale access path is not broken by host authorization activation (see nit #2).

VERDICT: APPROVED

## PR #53 Review ### DOMAIN REVIEW **Stack:** Ruby on Rails (production environment config) The change adds `config.hosts << "palinks.app"` to `config/environments/production.rb`, activating Rails host authorization for the production domain. This is the correct fix for the 403 Blocked Host error described in #51. **Pattern consistency:** The `config.hosts <<` append pattern matches what `development.rb` uses for its Tailscale hosts (`palinks.tail5b443a.ts.net`, `dev-tunnel-palinks.tail5b443a.ts.net`). Correct approach. **Subdomain coverage:** The PR adds only the bare domain `"palinks.app"`. If `www.palinks.app` or other subdomains eventually route to this app, they will be blocked by host authorization. The commented-out Rails example on line 65 even demonstrates a regex pattern for this: `/.*\.example\.com/`. Not a blocker today if subdomains are not in use, but worth confirming. **Security posture:** This is a security improvement. With `config.hosts` previously having no entries (all commented out), Rails was either rejecting everything or accepting everything depending on version defaults. Explicitly allowlisting the production domain is correct. **No test coverage concern:** This is a one-line framework configuration change, not custom application logic. Rails host authorization is tested by the framework itself. The test plan (deploy, curl, verify 200 vs 403) is the appropriate validation method for this change. ### BLOCKERS None. ### NITS 1. **Subdomain future-proofing (optional):** Consider whether `www.palinks.app` or `*.palinks.app` subdomains will ever route here. If so, adding a regex entry now prevents a repeat of this same issue later: ```ruby config.hosts << "palinks.app" config.hosts << /.*\.palinks\.app/ ``` Not blocking -- only relevant if subdomains are planned. 2. **Tailscale host in production:** `development.rb` explicitly allows Tailscale hostnames. If production is also accessed via Tailscale (the test plan mentions "verify existing Tailscale access still works"), you may need to add the Tailscale hostname to production hosts as well, or Tailscale-routed requests to production will start returning 403. Worth verifying during the deploy test. ### SOP COMPLIANCE - [x] PR body has Summary, Changes, Test Plan, Related - [x] No secrets committed - [x] No unnecessary file changes (single file, minimal scope) - [x] Commit message is descriptive and references issue - [x] Branch name follows convention (`51-add-palinks-app-host`) ### PROCESS OBSERVATIONS Low-risk, single-line config change. Deployment risk is minimal -- worst case is a rollback of one line. The change unblocks the custom domain chain (issue #50 set DNS, this PR makes Rails accept the host). Validate that Tailscale access path is not broken by host authorization activation (see nit #2). ### VERDICT: APPROVED
ldraney commented 2026-06-15 23:51:08 +00:00
Author
Owner
Copy link

PR #53 Review

DOMAIN REVIEW

Stack: Ruby on Rails (production environment configuration)

This is a Rails config.hosts change -- the HostAuthorization middleware in Rails 6+ blocks requests from unrecognized hosts with a 403. Adding "palinks.app" to the allowlist is the correct fix for the custom domain routing chain (DNS A record -> Hetzner edge proxy -> Rails app).

Observations:

  1. Pattern consistency: The PR body states this follows the same config.hosts << append pattern used in development.rb. The append-style (<<) is idiomatic Rails and correct.

  2. Bare domain only: The config adds "palinks.app" but not "www.palinks.app" or a wildcard regex like /.*\.palinks\.app/. This is fine IF the DNS/proxy setup only routes the bare domain. If www.palinks.app ever resolves to this app, a follow-up will be needed. Not a blocker -- just noting for awareness.

  3. No subdomain coverage: Same point -- if future subdomains (e.g., api.palinks.app) are needed, they would require separate entries or a regex. Acceptable for current scope.

  4. Placement: The line is inserted in the correct location -- right where the commented-out example hosts block was, before the host_authorization skip comment. Clean placement.

  5. No test coverage concern: This is a Rails environment config line, not application logic. There is no unit-testable behavior here -- the test plan (deploy and curl -I) is the appropriate verification method for a host allowlist change. No blocker.

BLOCKERS

None.

NITS

  1. Consider adding a comment: A brief inline comment explaining why this host is allowed (e.g., # Custom domain routed via Hetzner edge proxy) would help future readers. Very minor -- the git history and PR body provide the context.

  2. Future-proofing: If www.palinks.app will eventually redirect or resolve here, consider adding it now or noting it as a follow-up in issue #28 (the umbrella custom domain issue).

SOP COMPLIANCE

  • PR body has Summary, Changes, Test Plan, Related sections
  • Closes #51 references the parent issue
  • No secrets or credentials committed
  • No unnecessary file changes -- single file, minimal diff, tightly scoped
  • Commit message is descriptive (matches PR title)
  • Change is within scope of issue #51

PROCESS OBSERVATIONS

  • Change failure risk: Very low. This is an additive config change with no side effects. The worst case is a typo in the domain string, which would simply not fix the 403 -- it cannot break existing functionality.
  • Deployment frequency: No impact. Standard single-file config change.
  • Documentation: The umbrella issue #28 tracks the full custom domain chain. This PR is one step in that chain. No doc update needed for this specific change.

VERDICT: APPROVED

## PR #53 Review ### DOMAIN REVIEW **Stack**: Ruby on Rails (production environment configuration) This is a Rails `config.hosts` change -- the HostAuthorization middleware in Rails 6+ blocks requests from unrecognized hosts with a 403. Adding `"palinks.app"` to the allowlist is the correct fix for the custom domain routing chain (DNS A record -> Hetzner edge proxy -> Rails app). **Observations**: 1. **Pattern consistency**: The PR body states this follows the same `config.hosts <<` append pattern used in `development.rb`. The append-style (`<<`) is idiomatic Rails and correct. 2. **Bare domain only**: The config adds `"palinks.app"` but not `"www.palinks.app"` or a wildcard regex like `/.*\.palinks\.app/`. This is fine IF the DNS/proxy setup only routes the bare domain. If `www.palinks.app` ever resolves to this app, a follow-up will be needed. Not a blocker -- just noting for awareness. 3. **No subdomain coverage**: Same point -- if future subdomains (e.g., `api.palinks.app`) are needed, they would require separate entries or a regex. Acceptable for current scope. 4. **Placement**: The line is inserted in the correct location -- right where the commented-out example hosts block was, before the `host_authorization` skip comment. Clean placement. 5. **No test coverage concern**: This is a Rails environment config line, not application logic. There is no unit-testable behavior here -- the test plan (deploy and `curl -I`) is the appropriate verification method for a host allowlist change. No blocker. ### BLOCKERS None. ### NITS 1. **Consider adding a comment**: A brief inline comment explaining why this host is allowed (e.g., `# Custom domain routed via Hetzner edge proxy`) would help future readers. Very minor -- the git history and PR body provide the context. 2. **Future-proofing**: If `www.palinks.app` will eventually redirect or resolve here, consider adding it now or noting it as a follow-up in issue #28 (the umbrella custom domain issue). ### SOP COMPLIANCE - [x] PR body has Summary, Changes, Test Plan, Related sections - [x] `Closes #51` references the parent issue - [x] No secrets or credentials committed - [x] No unnecessary file changes -- single file, minimal diff, tightly scoped - [x] Commit message is descriptive (matches PR title) - [x] Change is within scope of issue #51 ### PROCESS OBSERVATIONS - **Change failure risk**: Very low. This is an additive config change with no side effects. The worst case is a typo in the domain string, which would simply not fix the 403 -- it cannot break existing functionality. - **Deployment frequency**: No impact. Standard single-file config change. - **Documentation**: The umbrella issue #28 tracks the full custom domain chain. This PR is one step in that chain. No doc update needed for this specific change. ### VERDICT: APPROVED
ldraney deleted branch 51-add-palinks-app-host 2026-06-16 00:19:38 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ldraney/palinks!53
No description provided.