Documentation
¶
Overview ¶
Package authcodetest provides a shared contract test suite for all core.AuthorizationCodeStore implementations (RFC 6749 §4.1). Each backend — in-memory, fs (follow-up), gorm (follow-up), gae (follow-up) — exercises the same behavioral scenarios by handing this package a Factory closure and calling RunAll. Mirrors the existing deviceauthtest precedent.
Why a shared suite: the per-backend test files for the device store had started to drift on small details (error wording, scope round-trip, LastPolledAt persistence). Pulling the scenarios into one place enforces the contract uniformly and makes adding the next backend a one-line RunAll invocation.
Index ¶
- func RunAll(t *testing.T, factory Factory)
- func TestCleanupExpired(t *testing.T, factory Factory)
- func TestCleanupKeepsUsedUntilTokenExpiry(t *testing.T, factory Factory)
- func TestCollision(t *testing.T, factory Factory)
- func TestConsumeOnce(t *testing.T, factory Factory)
- func TestCreateAndGet(t *testing.T, factory Factory)
- func TestDeleteConsumes(t *testing.T, factory Factory)
- func TestNotFound(t *testing.T, factory Factory)
- func TestRestartPersists(t *testing.T, factory Factory)
- func TestReuseBeforeRecord(t *testing.T, factory Factory)
- type Backend
- type Factory
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func RunAll ¶
RunAll runs the complete AuthorizationCodeStore contract suite against the provided factory. Each scenario gets a fresh Backend via factory(t) so state cannot leak between cases.
func TestCleanupExpired ¶
TestCleanupExpired pins the timer-driven sweep contract: codes with ExpiresAt at or before now are removed; codes still in their window survive.
func TestCleanupKeepsUsedUntilTokenExpiry ¶ added in v0.1.57
TestCleanupKeepsUsedUntilTokenExpiry pins retention: a used code outlives its own expiry until the access token it produced expires, so a late reuse can still find that token.
func TestCollision ¶
TestCollision pins that re-creating a code is rejected. The code is the AS-issued unique handle the client redeems with; a silently-overwritten record would let a second client hijack the first's pending authorization.
func TestConsumeOnce ¶ added in v0.1.57
TestConsumeOnce pins the single-use gate: the first consume succeeds and returns the unused record, and every later one returns ErrAuthorizationCodeUsed with the tokens the first redemption recorded, which the caller revokes.
See: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2 See: https://www.rfc-editor.org/rfc/rfc9700#section-4.5
func TestCreateAndGet ¶
TestCreateAndGet pins the happy-path round-trip: a freshly stored code returns every binding field unchanged on lookup. Pinning Scopes catches backends that drop the slice during JSON / SQL marshalling.
func TestDeleteConsumes ¶
TestDeleteConsumes pins that a deleted code is no longer reachable via GetAuthorizationCode. The redemption handler deletes expired codes this way; redeemed ones are marked used (TestConsumeOnce).
func TestNotFound ¶
TestNotFound pins that GetAuthorizationCode returns ErrAuthorizationCodeNotFound (not a generic error) when the record does not exist. The redemption handler maps the sentinel to `invalid_grant` per RFC 6749 §5.2; a generic error would surface as a 500.
func TestRestartPersists ¶
TestRestartPersists pins durability for persistent backends. The scenario writes a code through the initial Store handle, reopens via Reopen, and reads the code back. For the in-memory backend this is trivially true (Reopen returns the same instance).
func TestReuseBeforeRecord ¶ added in v0.1.57
TestReuseBeforeRecord pins the race: a second redemption that lands between the first one's consume and its record finds no tokens to revoke, so the record step must report the reuse and the first redemption revokes its own tokens.
See: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2 See: https://cwe.mitre.org/data/definitions/367.html
Types ¶
type Backend ¶
type Backend struct {
Store core.AuthorizationCodeStore
Reopen func() core.AuthorizationCodeStore
}
Backend is the per-test fixture handed to every scenario. Store is the initial handle the test exercises; Reopen returns a fresh handle bound to the same backing storage so the RestartPersists scenario can simulate a process restart.
For persistent backends (fs / gorm / gae) Reopen constructs a new store rooted at the same dir / DB connection / namespace. For the in-memory backend Reopen returns the same instance — there is no underlying storage to reconnect to and the property the scenario pins ("data survives a fresh handle") is trivially true.
Source Files