GNL
Dokümanlar menüsü
Enterprise@gnldev/auth-ee

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#

paket
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:

src/index.ts
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:

src/index.ts
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:

programatik oluşturma
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() again

4. 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ı#

fncreateJournalUserStore

(journal: JournalLike) => JournalUserStore. journal listKeys desteklemeli (Sqlite/Postgres/InMemory sağlar), yoksa fırlatır.

typeJournalUserStore

authenticate(token, now?), list(), create(input), remove(id), revoke(id) sözleşmesi.

typeEeUserRecord

Journal'da saklanan tam kayıt: id, roles, orgId?, tokenHash, createdAt, expiresAt?, lastUsedAt?, revoked?.

typeEeUserPublic

EeUserRecord eksi tokenHash — list() ve Studio'ya sızan güvenli görünüm.

typeCreateUserInput

create() girdisi: email?, name?, roles?, orgId?, ttlMs? (öncelikli), expiresAt?.

constStudioAppOptions.users

createStudioApp'e verilen StudioUserStore — verilirse Studio 'Kullanıcılar' görünümü + /users uçları açılır.

Dikkat
@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.
Not
Yetkilendirme varsayılan olarak tek eksenlidir: rol '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.
İpucu
Studio'da "Kullanıcılar" görünümü organizasyon modeline uyar: organizasyonsuz operatör tüm üyeleri yönetir, organizasyon-admin yalnız kendi organizasyonunun üyelerini oluşturabilir/silebilir/iptal edebilir — hedef üye var olmayan bir organizasyona atanamaz.