feat(auth): initial implementation — authmw and rbac (v1.0.0)
Introduces code.nochebuena.dev/einherjar/auth — the provider-agnostic HTTP
authentication and authorization layer of the Einherjar framework. Absorbs
two micro-lib packages (httpauth, rbac) as sub-packages, replacing the
Identity-only context model with a SecurityBag-native design and adding a
composable enrichment chain.
authmw:
- BagEnricher function type — enriches the request-scoped SecurityBag after
the base Identity is built; registered via WithBagEnricher; multiple
enrichers run in order, each receiving the bag from the previous
- IdentityEnricher interface — application-layer contract for loading user
data from uid+claims
- EnrichmentMiddleware — builds SecurityBag from uid+claims, runs enricher
chain, stores via security.SetBagInContext; 401 on missing uid, 500 on
enricher error; routes all errors through httputil.Error
- AuthzMiddleware — per-route permission gate; 401 on missing identity,
403 on provider error (fail-closed) or insufficient permissions
- EnrichOpt type + WithTenantHeader (reads TenantID from header, implemented
as a BagEnricher) + WithBagEnricher (registers custom enrichers for
hardware IDs, grant codes, or any bag attribute)
- SetTokenData / GetClaims — integration contract for auth-jwt / auth-firebase
rbac:
- NewClaimsPermissionProvider — reads flat JWT claim bitmasks from context;
wildcard "*" fallback; handles int64/float64/json.Number; zero DB calls
- NewCachedPermissionProvider — TTL cache wrapping any PermissionProvider;
default key "rbac:{uid}:{resource}" or "rbac:{tenantID}:{uid}:{resource}";
TenantID sourced from SecurityBag automatically; accepts ...CachedOpt
- CachedOpt type + WithCacheKey — overrides the key function for extra
dimensions (hardware IDs, grant codes read from bag attributes)
- NewChainPermissionProvider — tries providers in order; first non-zero wins;
errors short-circuit; typical pattern: claims → cached DB fallback
- Cache interface — pluggable backend satisfied by cache-valkey via duck typing
Compliance test (package auth_test) enforces CT-6 (≤1 exported TypeSpec/file),
compile-time interface satisfaction, and behavioural coverage across the full
middleware and provider surface: enrichment success/failure, tenant header,
custom BagEnricher, bag-in-context, authz allowed/denied/error, claims
hit/wildcard/missing/float64, cached hit/miss/error/tenant-key/custom-key,
chain first-non-zero/fallthrough/error.
Depends on contracts v1.0.0, core v1.0.0, web v1.0.0.
- identifiable.go: package-level Module variable (observability.Identifiable) for version
identification — auth is middleware-only; not registered with the launcher
This commit is contained in:
70
.gitea/pull_request_template.md
Normal file
70
.gitea/pull_request_template.md
Normal file
@@ -0,0 +1,70 @@
|
||||
## Summary
|
||||
|
||||
<!-- One or two sentences: what does this PR do and why? -->
|
||||
|
||||
---
|
||||
|
||||
## Type of change
|
||||
|
||||
- [ ] Bug fix — non-breaking change that resolves an issue
|
||||
- [ ] New feature — non-breaking addition of functionality
|
||||
- [ ] Breaking change — alters existing behavior or public API
|
||||
- [ ] Documentation update
|
||||
- [ ] Refactor — no functional change, no new API surface
|
||||
- [ ] Test improvement
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!--
|
||||
Provide enough context for a reviewer who was not in the room:
|
||||
- What problem does this solve?
|
||||
- What approach did you choose, and why?
|
||||
- Were there alternatives you considered and rejected?
|
||||
- Any known limitations or follow-up work?
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
## Testing
|
||||
|
||||
- [ ] I added or updated tests that cover my changes
|
||||
- [ ] All tests pass locally — `go test ./...`
|
||||
- [ ] No formatting issues — `gofmt -l .` produces no output
|
||||
- [ ] No vet warnings — `go vet ./...` is clean
|
||||
|
||||
---
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] At most one exported type per non-test `.go` file (CT-6)
|
||||
- [ ] No new external dependencies added without prior discussion in an issue
|
||||
- [ ] Public API changes are reflected in `CHANGELOG.md`
|
||||
- [ ] Breaking changes include a migration note in the PR description above
|
||||
|
||||
---
|
||||
|
||||
## Contributor License Agreement
|
||||
|
||||
> **This PR will not be merged until the CLA comment is present.**
|
||||
|
||||
Before a Maintainer reviews your code, you must post the following text **as a comment on this PR** — not here in the description. PR description checkboxes can be silently toggled by anyone; a comment is a timestamped, author-attributed record that cannot be quietly removed.
|
||||
|
||||
**Copy and post this exact text as a PR comment:**
|
||||
|
||||
---
|
||||
|
||||
> I have read the Einherjar Contributor License Agreement (CLA.md) and I agree to all its terms.
|
||||
> I confirm this Contribution is my original work. I grant the Maintainers the rights described
|
||||
> therein, including the right to relicense, and I retain ownership of my copyright.
|
||||
> This agreement covers all future Contributions I submit to any Einherjar repository under
|
||||
> this account.
|
||||
|
||||
---
|
||||
|
||||
First time contributing? Read [CLA.md](../CLA.md) for the full agreement before posting the comment.
|
||||
|
||||
If you are contributing on behalf of a company, an authorized representative of that company must post the comment.
|
||||
|
||||
<!-- Thank you for contributing to Einherjar. For those who come after. -->
|
||||
Reference in New Issue
Block a user