authstoredb

lib-authstore-db

Implementasi authstorage:db untuk webcore -- pengganti backend adapter/authstore/yaml bawaan webcore, tapi datanya diambil dari PostgreSQL alih-alih file access.yaml.

Isi package

• entity/entity.go -- model tabel access.auth_users & access.auth_resources
• backend.go -- DBBackend, implementasi interface auth.IStore (query ke DB)
• loader.go -- DBLoader, implementasi core.LibraryLoader (di-daftarkan sebagai authstorage:db)
• migrations/001_create_auth_tables.sql -- DDL tabel yang dipakai entity.go

Cara pakai

1. Jalankan migration

Jalankan migrations/001_create_auth_tables.sql ke database ildki (schema access, sesuai config.yaml).

Jika Anda sudah punya tabel users/permission dengan struktur berbeda, tidak perlu jalankan migration ini -- cukup sesuaikan tag bun:"..." / db:"..." di entity/entity.go supaya cocok dengan tabel existing Anda. backend.go dan loader.go tidak perlu diubah.

2. Daftarkan ke go.work

Tambahkan baris ./libraries/authstoredb ke go.work:

use (
	./libraries/jwt
	./libraries/authstoredb
	./modules/auth
	./webcore
)

3. Daftarkan loader ke APP_LIBRARIES

Edit webcore/auth/libraries.go:

import (
	jwt "github.com/webcore-go/lib-auth-jwt"
	authstoredb "github.com/nersus15/lib-authstoredb"
	memory "github.com/webcore-go/lib-memory"
	postgres "github.com/webcore-go/lib-postgres"
	"github.com/webcore-go/webcore/app/core"
)

var APP_LIBRARIES = map[string]core.LibraryLoader{
	"cache:memory":       &memory.MemoryLoader{},
	"database:postgres":  &postgres.PostgresLoader{},
	"authentication:jwt": &jwt.JWTAuthLoader{},
	"authstorage:db":     &authstoredb.DBLoader{},
}

"cache:memory" wajib terdaftar di sini (bukan cuma authstorage:db) supaya bagian Caching di bawah bisa aktif -- tanpa itu, authstoredb tetap jalan normal, cuma tanpa optimasi cache.

4. Pastikan config.yaml sudah benar

server, auth, database harus top-level (sejajar dengan app:, bukan di dalamnya) -- lihat pembahasan sebelumnya. Yang relevan untuk library ini:

auth:
  type: "jwt"
  control: RBAC
  store: db
  secret_key: your-secret-key-here
  session:
    expires_in: 86400

database:
  driver: postgres
  host: "localhost"
  port: 5432
  user: faskesmanager
  password: jNeOtHQrIPmQsAvHrxB1
  name: ildki
  schema_name: access
  ssl_mode: disable

5. go mod tidy

Karena module ini baru, go.sum-nya belum ada. Jalankan dari root project:

cd libraries/authstoredb && go mod tidy

(butuh akses internet untuk resolve dependency uptrace/bun, golang.org/x/crypto, dst.)

Cara kerja singkat

• Login (POST /auth/token, hanya relevan untuk auth.type: jwt): GetUserLoginInfo query user by username, verifikasi password dengan bcrypt.CompareHashAndPassword.

• Request terproteksi: GetUserAuthInfo menentukan 1 kandidat user dulu (query murah, bukan brute-force seperti backend YAML) dengan cara berbeda tergantung validator.Name():

  • "jwt" -- decode klaim user_id dari JWT (tanpa verifikasi signature -- cuma untuk tahu user mana yang perlu di-query), lalu query by username.
  • "apikey" -- key yang dikirim klien dicari di access.auth_apikey (findUserByAPIKey), lalu user pemiliknya diambil dari access.auth_users lewat user_id. UserAuthInfoRBAC.UserId yang dikirim ke validator.VerifyUser diisi dengan nilai API key itu sendiri (bukan user.ID) karena ApiKeyValidator.VerifyUser bawaan webcore membandingkan key ke UserId secara literal -- id asli user tidak pernah keluar dari server.

  Setelah kandidat user ditemukan, verifikasi akhir (signature JWT / kecocokan API key) tetap diserahkan ke validator.VerifyUser (JWTAuthValidator / ApiKeyValidator bawaan webcore) -- kita tidak menduplikasi logic verifikasinya di sini.

• Authorization (RBAC): GetResourceInfo query access.auth_resources berdasarkan method, lalu cari prefix path yang paling spesifik -- perilakunya disamakan dengan adapter/authstore/yaml/backend.go, dan tidak terpengaruh tipe auth (jwt/apikey) sama sekali.

Caching

Berbeda dengan backend YAML (semua data di-load sekali ke memori saat startup), backend DB ini secara default query ke Postgres di setiap request. Untuk kurangi beban itu, DBBackend punya field Cache port.ICacheMemory (opsional -- diisi otomatis oleh loader.go dari instance "cache:memory" yang sudah dimuat, atau nil kalau tidak ada).

Kenapa login sengaja tidak di-cache: ini titik kontrol paling sensitif (mis. admin menonaktifkan user karena akun dicurigai kompromi) dan jauh lebih jarang dipanggil dibanding pengecekan per-request, jadi manfaat caching-nya kecil dibanding risiko user nonaktif masih lolos beberapa detik.

Trade-off yang perlu disadari: dengan cacheTTLUser = 30s, perubahan active/groups/roles pada user yang sedang login butuh waktu maksimal 30 detik untuk kerasa di endpoint terproteksi (bukan lagi instan). Kalau butuh revoke akses instan tanpa delay sama sekali, turunkan cacheTTLUser (bahkan ke beberapa detik) atau non-aktifkan cache untuk backend ini dengan tidak mendaftarkan "cache:memory" di APP_LIBRARIES -- Cache akan nil dan seluruh lookup otomatis balik ke query DB langsung tanpa cache sama sekali.

Tidak ada invalidasi cache manual (mis. saat admin update user lewat tool lain) -- staleness murni dibatasi oleh TTL. Kalau butuh update near-instant tanpa TTL pendek, perlu mekanisme invalidasi aktif (mis. pub/sub ke semua instance saat ada perubahan), yang belum diimplementasikan di sini.

Tipe auth yang didukung

Batasan saat ini

• Hanya mendukung control: RBAC (belum ada mapping ABAC).