Dokümanlar menüsü
Kullanıcı yönetimi (journal-destekli)
Bearer token → Principal doğrulayan, journal'da token'ı HASH'li saklayan kullanıcı deposu; Studio 'Kullanıcılar' görünümünden ekle/sil, token yalnız oluşturmada bir kez gösterilir.
Ne işe yarar / ne zaman kullanılır#
Açık-çekirdek roleAuth sabit kod içinde tanımlı birkaç token'la çalışır — yeni bir kullanıcı eklemek için deploy gerekir. createJournalUserStore bunun yerine kullanıcıları journal'da tutar (policy/budget'ta olduğu gibi veri-güdümlü): operatör Studio'dan yeni bir kullanıcı oluşturur, dönen token o kişiye verilir, kullanıcı o token'la Authorization: Bearer <token> ile istek atar — deploy'suz, kod değişikliği olmadan.
Somut senaryo: bir SaaS dağıtımında operatör (organizasyonsuz admin) her yeni müşteri organizasyonu için Studio "Kullanıcılar" görünümünden bir üye oluşturur (organizasyon ataması ile), token'ı müşteriye iletir; müşteri o token'la kendi organizasyonuna kapsanmış şekilde API'yi kullanır. Organizasyon-admin ise yalnız kendi organizasyonunun üyelerini yönetebilir.
Kurulum / import#
import { createEnterpriseAuth, createJournalUserStore, createJournalAuditSink } from '@gnldev/auth-ee';
import { toJournal } from '@gnldev/durable';
import { SqliteStorage } from '@gnldev/durable/sqlite';@gnldev/auth-ee paralı/lisanslı bir pakettir. createJournalUserStore, kullanıcıları saklamak için listKeys destekleyen bir journal ister — toJournal(storage.runs) (Sqlite/Postgres/InMemory hepsi listKeys sağlar) buna yapısal olarak uyar.
Adım adım kullanım#
1. Depoyu journal üzerinde kurun ve createEnterpriseAuth'a userStore olarak verin — SSO'dan sonra, açık-çekirdek fallback'ten önce devreye girer:
const userStore = createJournalUserStore(toJournal(storage.runs));
const auth = createEnterpriseAuth({
licenseKey,
failClosed: true,
userStore,
audit: createJournalAuditSink(toJournal(storage.runs)),
fallback: roleAuth({
admin: { token: ADMIN_TOKEN, user: 'ops' }, // bootstrap operator
}),
});2. Aynı userStore'u Studio'ya users seçeneğiyle verin — bu, Studio'da "Kullanıcılar" görünümünü ve /users uçlarını açar:
app.route('/studio', createStudioApp({
reader: toJournal(storage.runs),
gnl,
auth,
users: userStore, // the Studio "Users" view — add/remove; the token is shown once
}));3. Studio'dan (veya userStore.create() ile programatik) yeni kullanıcı oluşturunca dönen token yalnız o an gösterilir — sunucu düz token'ı hiçbir yerde saklamaz, yalnız SHA-256 hash'ini journal'a yazar:
const { user, token } = await userStore.create({
email: '[email protected]',
roles: ['viewer'],
orgId: 'acme',
ttlMs: 30 * 24 * 60 * 60 * 1000, // expires automatically after 30 days
});
// token: 'eeu_...' — returned HERE ONLY; if it is lost, userStore.revoke() then create() again4. Kullanıcı o token'ı Authorization: Bearer eeu_... başlığıyla gönderir; authenticate() token'ın SHA-256'sını journal'daki ters indekste arar, süresi dolmuş (expiresAt) veya iptal edilmiş (revoked) değilse bir Principal döner ve lastUsedAt'i best-effort günceller.
Kullanıcıyı silmeden erişimini kesmek için userStore.revoke(id) kullanılır — kayıt (audit/geçmiş için) kalır, yalnız token ters indeksi kaldırılır ve revoked: true işaretlenir.
API referansı#
createJournalUserStore(journal: JournalLike) => JournalUserStore. journal listKeys desteklemeli (Sqlite/Postgres/InMemory sağlar), yoksa fırlatır.
JournalUserStoreauthenticate(token, now?), list(), create(input), remove(id), revoke(id) sözleşmesi.
EeUserRecordJournal'da saklanan tam kayıt: id, roles, orgId?, tokenHash, createdAt, expiresAt?, lastUsedAt?, revoked?.
EeUserPublicEeUserRecord eksi tokenHash — list() ve Studio'ya sızan güvenli görünüm.
CreateUserInputcreate() girdisi: email?, name?, roles?, orgId?, ttlMs? (öncelikli), expiresAt?.
StudioAppOptions.userscreateStudioApp'e verilen StudioUserStore — verilirse Studio 'Kullanıcılar' görünümü + /users uçları açılır.
@gnldev/auth-ee paralı/lisanslıdır — geçerli bir lisans (licenseKey) olmadan createEnterpriseAuth fallback'e düşer ve userStore devreye girmez; failClosed: true verilmişse geçersiz lisansta boot hata fırlatır.'admin' (yazma) ya da 'viewer' (okuma) olur ve bir organizasyona kapsanır. Gözden kaçması kolay iki tane daha var — 'member' ikisinin arasında durur (okuma artı agents:run, yani biri admin olmadan ajan koşturabilir) ve ayrılmış 'platform-admin' organizasyonlar-arası açık yetkidir. Sonuncusu olmadan organizasyonsuz bir kullanıcı fail-closed'dır, yani kimse bir orgId unutarak süper admin olmaz. Ayrı bir permissions[] verdiğinizde rolün yetkilerini tümden ezer — altı adlandırılmış okuma izni kişi başına böyle atanır.