* Add boundary connect alias bats tests
Adding tests that validate the authorize-session requests when a host-id is provided when an alias is used, both configured and not configured with a host id already.
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>
* Add aliases to target resource and alias resolution to target service
* Wire up the target alias domain package to the target service handler
* Adding alias resolution to target api tests
This adds support for tracking and reporting monthly active users for
the purpose of billing. It adds a new API endpoint,
`/v1/billing:monthly-active-users` and new cli command, `boundary
billing monthly-active-users` that can be used to view the monthly
active user counts.
This adds a new accumulating fact table to the data warehouse for auth
tokens. This fact table is used to calculate the number of active users
within a month, where an active user is a user that has at least one
issued auth token within the time range of the month.
This updates the billing repository to use timestmap.Timestamp when
constructing the queries to retrieve monthly active users. This allows
for specifying NegativeInfinity to easily retrieve all monthly active
user counts.
When converting a timestamp.Timestamp for use in SQL, this now correctly
converts the NegativeInfinity and PositiveInfinity constants into the
corresponding `-infinity` and `infinity` SQL constants.
These functions will ensure that UTC time is used for billing queries,
eliminating the need for the repository to set the timezone. This also
means the repository no longern needs a writer.
This adds two sql functions that can be used to access the views to
retrieve monthly active user counts. The functions ensure that any time
calculates are performed in UTC, so that the month bounds align with the
start of the month in UTC.
1. hcp_billing_monthly_active_users_last_2_months() will return monthly
active users for the current and previous month.
2. hcp_billing_monthly_active_users_all() will return monthly active
users for all months. This function can also be provided a start time
and or end time to filter the results to a specific range.
This test started failing now that the data warehouse records a auth
token fact when an auth token is issued and it requires that the auth
token has a user associated with it.
Since this test is testing the interaction with the database directly,
and not via the repository, it by-passes the application checks that
would prevent an auth token without an associated user being inserted.
This test is updated to meet this same pre-condition prior to attempting
to insert into the database.
Now that there is an auth token fact table in the data warehouse, it is
not possible to insert an auth_token with an old public_id even after
that auth_token was deleted, since it now causes a constraint violation
on the data warehouse table.
With the addition of an after insert trigger to the auth_token table,
entries are added to the wh_user_dimension table when auth token's are
inserted with the 'token issued' status. This caused a number of tests
to fail that assumed the user dimension table would be empty prior to
inserting sessions. This introduces a number of changes to the tests:
- In the test setup, auth tokens are not created with an explicit
expiration time and status. The expiration time ensures that the
tokens are 'valid' for the test. The status allows test to make
assertions on tokens in different statuses, and allow the status to
change during the test.
- Tests make the correct assertions on the number of entries in the user
dimension table after test setup.
- User dimension tests modify a user after the standard setup to ensure
that a new user dimension is added when a session is inserted.
This adds a function and after delete trigger to the auth_token table to
ensure that a corresponding auth token fact is updated with the deleted
time and sets the auth token valid time range. The data warehouse will
only be updated if the token that was deleted is in the 'token issued'
status.
This adds a function and update trigger to auth_token to ensure that:
1. If the auth token is updated to the issued state, a auth token fact
is added to the warehouse.
2. If the auth token's approximate last access time is updated, the
corresponding auth token fact is updated with the new time.