The hard part of an internal tool isn’t the API. It’s the second user

Описание и применение

Небольшой контейнер, использующий внешние сервисы, обеспечивает внутренний инструмент с несколькими пользователями, изолированными данными и журналами аудита, устраняя необходимость подписки.

Задача

Internal tools often become costly subscriptions when they rely on vendor services for glue, but the real challenge is adding a second user with proper isolation, authentication, and auditability.

Результат

The tool now runs on a small container, keeps data on the LAN, supports multiple users with proper isolation and audit logs, and eliminates subscription costs by using existing infrastructure.

Рабочий процесс

• 1. Design container to be lightweight (239 MB) and delegate heavy dependencies to external URLs.
• 2. Store all data locally; photos never leave LAN except to the vendor API.
• 3. Enforce tenant isolation by making tenant a required field in all data access APIs.
• 4. Remove default tenant value; require explicit tenant assignment to prevent unauthenticated access.
• 5. Implement three auth modes: solo (no auth), signin (app‑managed sessions), proxy (forward‑auth).
• 6. Separate seat (billing entitlement) and role (trust level) checks in permission logic.
• 7. Add support access via scope switch instead of impersonation, logging both operator and client actions.
• 8. Display active auth mode and scope banner in UI for transparency.

Доказательства

The container stays small (239 MB) because it contains no model weights, no browser, no search index. It is Python, SQLite and templates.

Источник

Anonymous, unauthenticated requests constructed a user object without overriding it — so an unauthenticated request resolved to the default tenant's data.

Источник

The default is no authentication, and the failure is silent.

Источник