Skip to content

docs(public-page): add public page content audit #349

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.

Sign up for GitHub

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

Open
TylerAdamMartinez wants to merge 2 commits into
base: staging
Choose a base branch
from
Open

docs(public-page): add public page content audit #349

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9b97560
docs(public-page): add public page content audit
TylerAdamMartinez Aug 19, 2026
5fd11f6
chore(public-page): rm description of Ocotillo requirement
TylerAdamMartinez Aug 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions docs/public-page-content-audit.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
# Public Page Content Audit

## Summary

Define what unauthenticated users should see on Ocotillo before public-page design begins.

The public page should explain what Ocotillo is, how to access it, and who it is for without exposing internal data, workflows, or infrastructure.

## Recommended Public Content

The public page should include:

- A sign-in button.
- Instructions for requesting access.
- A support contact method.
- A note that access is restricted to authorized users.

Avoid assuming visitors already understand "Ocotillo" or internal acronyms.

## Security

Public pages should not expose:

- API endpoints, infrastructure, environments, or bucket names
- Authentication or authorization implementation details
- Internal documentation, admin tools, dashboards, or logs
- Unpublished datasets, record identifiers, or data schemas
- Internal workflows
- Staff-only (nonpublic) contact information

Public content should generally be limited to application information, authentication, support, and explicitly approved public services.

## Public Routes

Recommended public routes:

- `/login` .
- `/callback` — Required for the authentication redirect flow
- `/about`
- `/analytics-disclosure`
- `/report-a-bug`
- `/ogcapi` — How to connect to ArcGIS manual

Basically, the existing markdown files in `public/content/` for `about`, `analytics-disclosure`, `ogcapi`, and `report-a-bug` are good candidates for these public informational pages.

## Protected Routes

Keep application and data-management functionality authenticated, including:

- `/home` in its current form.
- `/ocotillo/*`
- `/geothermal/*`
- `/st2/*`
- `/geochronology/*`
- `/example/*`
- Create, edit, import, correction, export, inventory, record-detail, and form routes.

Error pages **should** be accessible without authentication but should **not** expose protected navigation or debugging information.
Loading