Run any Skill in Manus with one click

auth-and-ownership

Stars2

Forks0

UpdatedFebruary 27, 2026 at 11:26

Authentication and ownership enforcement rules for LifeOS multi-user isolation. Use when creating or changing auth flows, guarded endpoints, user-scoped queries, or nested resource access checks.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

pvidaal07

pvidaal07/LifeOS

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	auth-and-ownership
description	Authentication and ownership enforcement rules for LifeOS multi-user isolation. Use when creating or changing auth flows, guarded endpoints, user-scoped queries, or nested resource access checks.

Auth and Ownership

Objetivo

Garantizar que cada usuario solo pueda leer y modificar sus propios datos.

REQUIRED

Obtener userId únicamente del contexto autenticado (JWT sub / @CurrentUser).
Aplicar guardas (JwtAuthGuard) en endpoints privados.
Filtrar lecturas y escrituras por userId en repositorios/queries.
Validar ownership en recursos anidados (plan → subject → topic → review).
Invalidar refresh token al logout/rotación según estrategia vigente.

NEVER

No aceptar userId desde body/query/params como fuente de autorización.
No devolver datos de existencia de recursos ajenos.
No saltar validaciones de ownership en operaciones masivas.

Respuesta ante acceso inválido

Preferir respuesta neutra (404 o error de dominio equivalente) para no filtrar existencia.
Loguear intentos sospechosos sin exponer secretos al cliente.

More from this repository

same repository

nestjs-best-practices

pvidaal07/LifeOS

NestJS best practices and architecture patterns for building production-ready applications. This skill should be used when writing, reviewing, or refactoring NestJS code to ensure proper patterns for modules, dependency injection, security, and performance.

2026-02-272

api-contracts

pvidaal07/LifeOS

API DTO and response contract rules for LifeOS backend/frontend compatibility. Use when adding or changing endpoints, request/response DTOs, error payloads, versioning decisions, or Swagger/OpenAPI documentation.

2026-02-272

clean-architecture-ddd

pvidaal07/LifeOS

Clean Architecture + DDD rules for this repo. Triggers: adding/refactoring code across src/domain|application|infrastructure, moving files between layers, creating ports/adapters/use-cases.

2026-02-272

docker-selfhost

pvidaal07/LifeOS

Docker Compose self-hosting conventions for LifeOS development and production. Use when editing compose files, environment variables, service networking, persistent volumes, health checks, or deployment workflows.

2026-02-272

docs

pvidaal07/LifeOS

Repository documentation conventions for LifeOS. Use when creating or updating README, docs/*, architecture notes, API behavior notes, or implementation decisions that must remain clear for future contributors and agents.

2026-02-272

postgresql

pvidaal07/LifeOS

PostgreSQL schema and query safety rules for LifeOS. Use when changing tables, indexes, constraints, migrations, date handling, performance-sensitive queries, or any persistence design decision.

2026-02-272

name	auth-and-ownership
description	Authentication and ownership enforcement rules for LifeOS multi-user isolation. Use when creating or changing auth flows, guarded endpoints, user-scoped queries, or nested resource access checks.

Auth and Ownership

Objetivo

Garantizar que cada usuario solo pueda leer y modificar sus propios datos.

REQUIRED

Obtener userId únicamente del contexto autenticado (JWT sub / @CurrentUser).
Aplicar guardas (JwtAuthGuard) en endpoints privados.
Filtrar lecturas y escrituras por userId en repositorios/queries.
Validar ownership en recursos anidados (plan → subject → topic → review).
Invalidar refresh token al logout/rotación según estrategia vigente.

NEVER

No aceptar userId desde body/query/params como fuente de autorización.
No devolver datos de existencia de recursos ajenos.
No saltar validaciones de ownership en operaciones masivas.

Respuesta ante acceso inválido

Preferir respuesta neutra (404 o error de dominio equivalente) para no filtrar existencia.
Loguear intentos sospechosos sin exponer secretos al cliente.