77e7379ab5
In order to implement this efficiently, I have introduced the concept of "singleton" backends -- currently, 'sys' and 'cubbyhole'. There isn't much reason to allow sys to be mounted at multiple places, and there isn't much reason you'd need multiple per-token storage areas. By restricting it to just one, I can store that particular mount instead of iterating through them in order to call the appropriate revoke function. Additionally, because revocation on the backend needs to be triggered by the token store, the token store's salt is kept in the router and client tokens going to the cubbyhole backend are double-salted by the router. This allows the token store to drive when revocation happens using its salted tokens. |
||
|---|---|---|
| .. | ||
| framework | ||
| testing | ||
| auth.go | ||
| connection.go | ||
| error.go | ||
| lease.go | ||
| lease_test.go | ||
| logical.go | ||
| request.go | ||
| response.go | ||
| secret.go | ||
| storage.go | ||
| storage_inmem.go | ||
| storage_inmem_test.go | ||
| system_view.go | ||
| testing.go | ||
| uuid.go | ||