A release-readiness QA pass over the whole product. The commits split into defects a user would hit and gates that were reporting green while measuring nothing. ## Fixes that change behaviour Rate limiting was bypassable on every install: TRUST_PROXY defaulted to true, so request.ip came from a client-set header and a forged X-Forwarded-For got past the login limiter. The default is now a private-network trust list. A transient Postgres outage stranded in-flight jobs, leaving finished output on disk with no row pointing at it. A reconciler now resolves those rows and adopts the bytes rather than dropping the work. A Redis connection that moved to a new address wedged every read-blocked consumer, so completions stopped signalling while health still answered 200. Socket timeouts plus subscriber pings recover it. Installing more than one AI bundle left the shared venv multi-versioned and silently broke three tools. The installer now reconciles distributions to one version each. Converting an image to JXL at quality 1 through 4 returned a 500, because libjxl 0.7 rejects the distance those values compute. The quality is floored at what the encoder honours. A missing ffmpeg was also reported to the user as a corrupt upload; it now says the engine is unavailable. RAW uploads reached an unpatched LibRaw on arm64, so it is built from source at 0.22.2, and the release scan was split so it can fail on an unfixed critical instead of hiding it behind ignore-unfixed. ## Gates that could not fail Two mutation lanes ran zero mutants because Stryker crawled the gitignored docs build; coverage discarded its whole report on any failing test; the lint gate skipped root tests, scripts, and two workspaces; and several generated matrices counted a host missing ffmpeg as a passing tool. Each now measures what it claims. Full evidence and the outstanding release items are tracked locally and are not part of this branch.
12 KiB
description, i18n_source_hash, i18n_provenance, i18n_output_hash, i18n_hash_version
| description | i18n_source_hash | i18n_provenance | i18n_output_hash | i18n_hash_version |
|---|---|---|---|---|
| Hantera användare, inbyggda och anpassade roller, behörigheter, API-nycklar, team, sessioner och granskningsloggen i SnapOtter. | bea8955f3aff | human | 9af24cfc9c89 | 2 |
Användare, roller och behörigheter
SnapOtter levereras med tre inbyggda roller, 17 detaljerade behörigheter och stöd för anpassade roller med valfri åtkomstkontroll per verktyg. Den här sidan täcker hela auktoriseringsmodellen, API-nyckelscoping, teamhantering och granskningsloggning.
::: tip Relaterade sidor OIDC / SSO | SAML SSO | SCIM-provisionering | Säkerhet och härdning :::
Användare
Skapa användare
Administratörer kan skapa användare via administratörspanelen eller POST /api/auth/register-slutpunkten. Varje användare har ett användarnamn, en roll, en teamtilldelning och en valfri e-postadress.
Standardadministratör
Vid första uppstart skapar SnapOtter ett standardadministratörskonto. Inloggningsuppgifterna kommer från miljövariabler:
| Variabel | Standard | Beskrivning |
|---|---|---|
DEFAULT_USERNAME |
admin |
Användarnamn för det initiala administratörskontot |
DEFAULT_PASSWORD |
admin |
Lösenord för det initiala administratörskontot |
Standardadministratören måste byta lösenord vid första inloggningen.
Autentiseringsleverantörer
Användare kan autentisera sig via flera metoder:
- Lokal - användarnamn och lösenord lagrade i SnapOtter-databasen
- OIDC - valfri OpenID Connect-leverantör (se OIDC / SSO)
- SAML - SAML 2.0-identitetsleverantörer (se SAML SSO)
- SCIM - automatiserad provisionering från en identitetsleverantör (se SCIM-provisionering)
Inaktivera autentisering
Ange AUTH_ENABLED=false för att inaktivera autentisering helt. I det här läget används en syntetisk anonym användare med rollen admin för alla förfrågningar. Ingen inloggning krävs.
::: warning Att inaktivera autentisering ger full administratörsåtkomst till alla som kan nå instansen. Använd endast detta i betrodda miljöer. :::
Inbyggda roller
SnapOtter inkluderar tre inbyggda roller. De kan inte ändras eller raderas.
Admin
Alla 17 behörigheter. Full kontroll över instansen.
tools:use files:own files:all apikeys:own apikeys:all pipelines:own pipelines:all settings:read settings:write users:manage teams:manage features:manage system:health audit:read compliance:manage webhooks:manage security:manage
Editor
7 behörigheter. Kan använda alla verktyg och hantera alla filer och pipelines, men kan inte komma åt administratörsfunktioner.
tools:use files:own files:all apikeys:own pipelines:own pipelines:all settings:read
User
5 behörigheter. Kan använda verktyg och hantera sina egna resurser.
tools:use files:own apikeys:own pipelines:own settings:read
Behörighetsreferens
| Behörighet | Beskrivning |
|---|---|
tools:use |
Använd valfritt bearbetningsverktyg |
files:own |
Visa och hantera egna filer |
files:all |
Visa och hantera alla användares filer |
apikeys:own |
Skapa och hantera egna API-nycklar |
apikeys:all |
Visa alla användares API-nycklar |
pipelines:own |
Skapa och hantera egna pipelines |
pipelines:all |
Visa och hantera alla användares pipelines |
settings:read |
Visa instansinställningar |
settings:write |
Ändra instansinställningar |
users:manage |
Skapa och hantera användarkonton inom aktörens behörighetsgräns |
teams:manage |
Skapa, uppdatera och radera team |
features:manage |
Installera och hantera AI-funktionsbuntar |
system:health |
Åtkomst till health- och readiness-slutpunkter |
audit:read |
Visa granskningsloggen och lista roller |
compliance:manage |
Hantera GDPR-livscykel- och efterlevnadsfunktioner; destruktiva användaroperationer förblir auktoritetsbundna |
webhooks:manage |
Konfigurera utgående webhooks |
security:manage |
Hantera säkerhetsinställningar (IP-tillåtelselista, SSO-tvingande) |
Anpassade roller
Administratörer med behörigheten security:manage kan skapa anpassade roller via administratörspanelen eller roles-API:et. Att lista roller kräver audit:read.
Skapa en anpassad roll
curl -X POST http://localhost:1349/api/v1/roles \
-H "Authorization: Bearer si_..." \
-H "Content-Type: application/json" \
-d '{
"name": "reviewer",
"description": "Can use tools and view all files",
"permissions": ["tools:use", "files:own", "files:all", "settings:read"]
}'
Rollnamn måste vara 2-30 tecken, gemena alfanumeriska med bindestreck och understreck.
Delegerade administrationsgränser
Alla 17 behörigheter kan delegeras genom anpassade roller, men en administrativ behörighet gör inte den rollen likvärdig med den inbyggda admin-rollen. Användarmutationer godkända av users:manage, destruktiva operationer godkända av compliance:manage och anpassade rollhantering auktoriserad av security:manage begränsas av skådespelarens nuvarande auktoritet:
- Inbyggda roller följer
admin>editor>user; anpassade roller är under inbyggda roller. - Målets behörigheter måste innehållas av skådespelarens effektiva behörigheter. En scoped API-nyckel kan därför inte utöva behörigheter som utelämnas från dess scope.
- En målrolls verktygsåtkomst ska innehållas av aktörens egen verktygsåtkomst.
- Ett inaktiverat konto kontrolleras mot sin ursprungliga roll när den rollen registreras som
disabled:<original-role>. - Att ta bort en anpassad roll kräver också behörighet att tilldela den inbyggda
userreserv; funktionshindrade medlemmar förblir inaktiverade somdisabled:user.
Globala autentiseringsuppgifter och konfiguration är strängare: utfärdande eller återkallande av SCIM-token och import av instanskonfiguration kräver den inbyggda admin-rollen med fullständig effektiv administratörsbehörighet.
Behörigheter på verktygsnivå
Anpassade roller kan valfritt begränsa vilka verktyg användare får komma åt. Två lägen finns tillgängliga:
| Läge | Beteende | Licenskrav |
|---|---|---|
category |
Begränsa per modalitet (bild, video, ljud, dokument, fil) | Inget (gratis) |
tool |
Begränsa per enskilt verktygs-ID | Kräver enterprise-funktionen per_tool_permissions |
När läget tool är satt men enterprise-funktionen inte är tillgänglig, degraderar SnapOtter graciöst och tillåter åtkomst till alla verktyg.
{
"name": "image-only",
"permissions": ["tools:use", "files:own"],
"toolPermissions": {
"mode": "category",
"allowed": ["image"]
}
}
Radera en anpassad roll
När en anpassad roll raderas tilldelas alla användare som tilldelats den automatiskt om till rollen user.
Team
Team grupperar användare för lagrings- och lagringshantering. Ett Default-team skapas vid första uppstart.
| Fält | Typ | Beskrivning |
|---|---|---|
name |
string | Unikt teamnamn (1-50 tecken) |
storageQuota |
number | Lagringsgräns per team i byte (fungerar utan enterprise) |
retentionHours |
number | Radera utdata automatiskt efter så här många timmar (kräver team_retention_overrides, enterprise) |
legalHold |
boolean | Förhindra automatisk radering av teammedlemmars filer (kräver legal_hold, enterprise) |
::: info
Teamet Default kan inte raderas. Team som fortfarande har medlemmar kan inte raderas. Tilldela om medlemmar först.
:::
API-nycklar
Användare kan generera API-nycklar för programmatisk åtkomst. Varje nyckel använder prefixet si_ och visas endast en gång vid skapandet.
Scopade behörigheter
API-nycklar kan valfritt bära en permissions-array. När den är satt är de effektiva behörigheterna för en förfrågan snittet av användarens rollbehörigheter och nyckelns scopade behörigheter. Detta innebär att en API-nyckel aldrig kan eskalera bortom användarens egna behörigheter.
curl -X POST http://localhost:1349/api/v1/api-keys \
-H "Authorization: Bearer si_..." \
-H "Content-Type: application/json" \
-d '{
"name": "CI pipeline key",
"permissions": ["tools:use", "files:own"],
"expiresAt": "2027-01-01T00:00:00Z"
}'
Utgång
Nycklar accepterar en valfri expiresAt-tidsstämpel. Utgångna nycklar avvisas vid autentiseringstillfället.
Granskningslogg
SnapOtter registrerar säkerhetsrelevanta händelser i en strukturerad granskningslogg som lagras i databastabellen audit_log.
Visa granskningsloggen
GET /api/v1/audit-log?page=1&limit=50&action=LOGIN_FAILED&from=2026-01-01T00:00:00Z&to=2026-12-31T23:59:59Z
Kräver behörigheten audit:read. Stöder paginering (page, limit) och filter (action, ip, from, to).
Granskning av verktygsoperationer
::: warning
TOOL_EXECUTED-händelser loggas inte som standard. De aktiveras via någon av två vägar:
- Ange administratörsinställningen
auditToolOperationstilltrue. - Inneha en aktiv licens med funktionen
audit_export(tillgänglig på både team- och enterprise-planer).
Utan någon av dessa registreras inte enskilda verktygskörningar i granskningsloggen. :::
Exportera
GET /api/v1/enterprise/audit/export?format=csv&from=2026-01-01T00:00:00Z
Kräver behörigheten audit:read och enterprise-funktionen audit_export (tillgänglig på både team- och enterprise-planer). Stöder CSV- och JSON-format, filtrerat efter action, actorId, targetType, targetId, from och to.
Manipuleringsbeständig signering
När det är aktiverat signeras varje granskningsloggpost med en HMAC härledd från DATA_ENCRYPTION_KEY. Detta kräver:
- Att ange
DATA_ENCRYPTION_KEYi din miljö. - Att aktivera administratörsinställningen
tamperResistantAudit. - En enterprise-licens med funktionen
tamper_resistant_audit.
Lagring
Ange AUDIT_RETENTION_DAYS för att automatiskt rensa gamla poster. Standarden är 0, vilket innebär att poster behålls på obestämd tid.
Händelsereferens
| Händelse | Kategori |
|---|---|
LOGIN_SUCCESS, LOGIN_FAILED |
Autentisering |
OIDC_LOGIN_SUCCESS, OIDC_LOGIN_FAILED |
Autentisering |
SAML_LOGIN_SUCCESS, SAML_LOGIN_FAILED |
Autentisering |
LOGOUT |
Autentisering |
USER_CREATED, USER_UPDATED, USER_DELETED |
Användarhantering |
PASSWORD_CHANGED, PASSWORD_RESET |
Användarhantering |
MFA_ENROLLED, MFA_DISABLED, MFA_VERIFIED, MFA_VERIFY_FAILED |
MFA |
MFA_CHALLENGE_ISSUED, MFA_RECOVERY_USED, MFA_RESET |
MFA |
ROLE_CREATED, ROLE_UPDATED, ROLE_DELETED |
Roller |
API_KEY_CREATED, API_KEY_DELETED |
API-nycklar |
SETTINGS_UPDATED, IP_ALLOWLIST_UPDATED |
Inställningar |
FILE_UPLOADED, FILE_DELETED |
Filer |
TOOL_EXECUTED |
Verktyg (opt-in) |
SCIM_USER_PROVISIONED, SCIM_USER_UPDATED, SCIM_USER_DEPROVISIONED |
SCIM |
SCIM_GROUP_SYNCED |
SCIM |
LEGAL_HOLD_APPLIED, LEGAL_HOLD_RELEASED |
Efterlevnad |
GDPR_EXPORT_INITIATED, GDPR_USER_PURGED, GDPR_TEAM_PURGED |
Efterlevnad |
CONFIG_EXPORTED, CONFIG_IMPORTED |
Konfiguration |
Sessionshantering
Sessioner är cookie-baserade, styrda av SESSION_DURATION_HOURS (standard: 168 timmar / 7 dagar).
Rolländringar ogiltigförklarar sessioner
När en administratör ändrar en användares roll raderas alla den användarens aktiva sessioner. Användaren måste logga in igen för att plocka upp sina nya behörigheter.
Säkerhetsspärrar
- Skydd för sista administratören: den sista kvarvarande administratören kan inte degraderas till en lägre roll. API:et returnerar ett fel om du försöker.
- Förhindrande av självradering: administratörer kan inte radera sitt eget konto via API:et.