Volunteer Portal · Access Control

Two patterns.
One decision.

Both demos use CloudFront Functions at the edge — zero origin exposure, sub-millisecond gate logic. The difference is the user experience and operational model.

Pattern A

HTTP Basic Auth

A single shared username and password protects the entire site. The browser provides the native login dialog — no custom UI required.

Gate mechanism CloudFront Function checks Authorization: Basic … header on every viewer request

Demo credentials Username: la28demo · Password: volunteer2028

Credential management Update the CloudFront Function + redeploy to rotate. One global secret for all users.

Best for Internal stakeholder previews, quick staging access, technical teams

Open Basic Auth demo →

Pattern B

Invite Code + Cookie Gate

A code entry page (branded, mobile-friendly) sets a first-party cookie. All other pages check for the cookie at the CloudFront edge.

Gate mechanism CloudFront Function checks invite_access=1 cookie. Missing → 302 redirect to entry page.

Demo code VOLUNTEER2028

Cookie lifetime 4 hours. Users must re-enter code after expiry. Fully configurable.

Best for Volunteer cohort previews, event-specific access, branded partner demos

Open Invite Code demo →

Side-by-side comparison

Factor	HTTP Basic Auth	Invite Code + Cookie
User experience	Browser-native dialog (no branding control). Simple, universal.	Fully branded entry form. Familiar to non-technical users.
Mobile experience	Works but dialog UI varies by browser/OS	Custom form — fully responsive and polished
Credential model	One shared secret for all users	One shared code (demo) or unique per-user codes (production)
Rotation effort	Redeploy CloudFront Function to change password	Redeploy function or update validation API endpoint
Revocation	Shared Rotate password → everyone locked out	Targeted Per-user codes invalidated individually (with API)
Security model	Strong Enforced server-side by CloudFront on every request	Demo Cookie set client-side (forgeable). Production needs signed tokens.
Implementation complexity	Low ~15 lines of CloudFront Function JS	Medium Entry page + cookie logic + CloudFront Function
Infrastructure cost	CloudFront Function invocations (~$0.10/million)	Same. S3 stores one additional HTML page.
Upgrade path	Add Lambda@Edge for per-user auth (Cognito, JWT)	Move validation to API + issue CloudFront signed cookies

Recommendation by use case

🏗️

Internal / stakeholder preview

Use Basic Auth. Zero UI work, instant setup. Staff and partners are comfortable with login dialogs. Easy to rotate when access period ends.

🎯

Cohort or partner access

Use Invite Code. Distribute codes per-cohort, brand the entry experience, and issue different codes to different groups for tracking.

🚀

Production volunteer portal

Neither — use the full auth flow (magic link + JWT + waiting room). These demos illustrate lightweight gate patterns for preview environments only.

Shared infrastructure note

Both demos share the same CDK infrastructure pattern: an S3 bucket (private, OAC) behind a CloudFront distribution with a custom domain in sit.dgplatform.net. ACM certificates are provisioned in us-east-1 via a separate stack (CloudFront requirement) and passed by ARN using CDK cross-region references. Each CloudFront distribution has a single CloudFront Function attached at the viewer-request event — the only difference between the two sites is the function logic (15–40 lines of JS).