Docs Auth Progress — Timeline for Non-Developers

This document explains, in plain language, what was done to improve the documentation app’s security and who can access what.

The Problem We Solved

The documentation admin area used a single shared password. That meant:

• Anyone with the password could access admin tools
• There was no way to know who did what
• The password was stored in a separate system from the main platform

We wanted to align the docs admin with the rest of the platform: use the same login system and restrict admin to specific roles.

What Changed (Timeline)

1. New Login System

Before: Admin used a password form that checked against a single shared password.

After: Admin uses the same login as the rest of the platform (email + password). You log in once and can access both the main app and the docs admin if you have the right role.

Why: One login system, better security, and clear accountability.

2. Who Can Access Admin

Before: Anyone with the shared admin password.

After: Only users with these roles can access the docs admin:

• Executives
• Developers
• Admins
• System (automated/system accounts)

Why: Admin tools (config, analytics, cloud sync) should be limited to trusted roles.

3. Who Can Access Documentation

Before: Same as now — anyone can read docs based on project and privacy settings.

After: No change. Documentation remains available to all users according to:

• Project selection (which documentation set they choose)
• Privacy level (public vs private, with password when required)

Why: Docs are meant to be readable; only admin is restricted.

4. Content Loading Fix (404 Errors)

Before: In development, the app tried to load content from an API that wasn’t set up for that, causing 404 errors.

After: In development, content is loaded from local files instead of the API. The API is only used when configured (e.g. production or cloud mode).

Why: Fewer errors during development and clearer separation between local and cloud modes.

5. Login Page Loading Fix

Before: The login page sometimes failed to load with a “Failed to fetch” error.

After: The login component is loaded with the main app instead of as a separate chunk, so it loads reliably.

Why: More reliable access to the login screen.

Summary Table

Future Steps

• Remove or fully deprecate the old password-based admin login
• Add more detailed audit logging for admin actions
• Consider optional two-factor authentication for admin

Where to Find More

• Technical details: docs-auth-implementation.md
• Session work: docs/english/sessions/S217/ through docs/english/sessions/S219/