As the `MacaroonRootKeyID` field of the `AddActionReq` struct also
contains the 4 bytes of the `MacaroonIdentifier`, we change all
call sites to instead use the last 4 bytes of the `MacaroonRootKeyID`
field. As the `MacaroonIdentifier` field therefore becomes redundant,
we also remove it.
When migrating the actions store from kvdb to sql, we will update the
existing actions to include the full mac root key, instead of just the
last 4 bytes (currently called `MacaroonIdentifier`). In order to do so,
we change the sql implementation of the `actions` store to persist the
full mac root key, instead of just the last 4 bytes. As no production
data in the sql actions store exists for users yet, it's fine for us to
change this without having to address old sql actions which only stored
the last 4 bytes.
Note though that since old actions stored in the kvdb implementation
only have the last 4 bytes of the mac root key persisted, we will only
ever persist the last 4 byte of the mac root key ID for kvdb actions.
When the actions are later read back from the kvdb store, the first 4
bytes of the mac root key ID will be padded with zeroes to make up the
full 8 bytes.
As no call site currently utilizes the full 8 bytes of the mac root key
ID, this is okay for now. When we later deprecate and remove the kvdb
implementation, we can then update the rest of `litd` to also use the
full mac root key ID.
For our kvdb firewalldb, we use an empty 4 byte array as the macaroon
identifier even if no macaroon was used to create the action. This is so
that we have some sort of "session ID" bucket to store these set of
actions under. For our SQL impl, however, this is not needed and we will
likely just use a nullable field for the macaroon ID. So in preparation
for this, we move the kvdb specific logic to the kvdb impl.
In this commit we add an optional AccountID to the RequestInfo type.
Then, we populate it if the caveat of the macaroon being used contains
an accounts caveat.
We also add an unused AccountID type to the AddActionReq and pass in the
value from the RequestLogger.
In this commit, we update our various firewall interceptors so that they
rely on the session ID passed via gRPC metadata to extract a session ID.
For the PrivacyMapper and RuleEnforcer, these _MUST_ always contain a
session ID and so we error out if one was not found. For the request
logger, the session ID is optional and so we pass it to the new
SessionID field in the AddActionReq - our bbolt actions DB will not make
use of this field on persistence (but our incoming SQL version will).
To make it very clear what the data is actually derived from. Then also
add an optional Session.ID. Our bbolt db wont store this real session ID
and will populate it in a best effort manner by casting the persisted
MacaroonIdentifier.
Instead of passing an `Action` to the AddAction method, we introduce an
`AddActionReq` type which only holds the fields that are needed to
create a new Action. The rest of the info is determined by the DB layer.
The current ActionLocator is very specific to how actions are stored in
the bbolt db. In our SQL implementation, we will simply have an
auto-incrementing int64 that we will use as our locator for any action.
In preparation for this, we make ActionLocator an abstract interface and
implement our bbolt version of it.
