Previously the function used to upsert into the user dimension required
both an auth token id, and a user id. However, the user id can be
determined from the auth token, in fact it already was via the
whx_user_dimension_source view. This refactor removes the user id as an
argument, since it is not needed and will not be directly available when
this function is used when populating the new auth token accumulating
fact.
When running the sqltests, sometimes it is helpful to see the full
database container logs, especially when there is an error in a
migration or database setup. However, it also makes it difficult to see
the test results.
This adds a new variable to the makefile to easily toggle the output of
these logs on or off. To run the tests without printing the dtabase logs
use:
DB_LOGS=0 make test
To enable the logs use:
DB_LOGS=1 make test
By default the logs are not printed.
Some of the prepared statement identifies used in these tests exceeded
the identifier character limit. This results in postgres truncating the
name, which is fine for a test, but does result in some noise in the
test output. This change shortens the identifies to eliminate noise like
the following:
psql:/test/credential/vault/credential_vault_library_ssh_private_key_mapping_override.sql:49: NOTICE: identifier "insert_credential_vault_library_ssh_private_key_mapping_override" will be truncated to "insert_credential_vault_library_ssh_private_key_mapping_overrid"
The tests should no longer create notices like these.
This does not currently remove the field from the message on the API but
since it will now always show `pki` it's meaningless and causing
confusion for some users.
* Save and assign hclogger throughout the client cache daemon
* Don't event for errors happening outside of the handlers or tickers.
* Hide and ignore -store-debug and expose the -log-level flag
* test(e2e): Add test to check target's -session-max-seconds
* test(e2e): Add additional test to check new connections are rejected
* test(e2e): Fix test check
* handlers/targets: always return pagination parameters in list
* handlers/authmethods: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/accounts: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/authtokens: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentiallibraries: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentials: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentialstores: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/groups: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/host_catalogs: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/host_sets: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/hosts: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/managed_groups: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/roles: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/scopes: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/sessions: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/users: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* chore: update deps
* tests: update sqlmock tests for breaking chg
* tests (handlers): sort grants in checkEqualGrants(...)
sort the expected and got grants in
checkEqualGrants(...) to make the test more
deterministic.
* tests (asciicast): update backspace enc in TestEventMarshal(...)
* fix: Proxy closing listener with 0 connections left
A bug was introduced in `0.15.0` where sessions with max connection counts were closed when the connections left hit 0. This issue was highlighted by a user: https://github.com/hashicorp/boundary/issues/4364. What was happening was when we have zero connections left the proxy code was closing the listener which closed its connections
To fix this:
- `boundary connect -target-id=xx -host-id=xx` command with no connections left will now wait for all connections to be closed and before exiting the session just like it did in `0.14.3`
- As soon as there are no more connections left, the listener will close to stop accepting new connections
- Fix issue where the websocket connection was throwing closing errors during the session teardown.
* Use the intercepted token if present, use it through the keyring if keyring contains it
* fixup! Use the intercepted token if present, use it through the keyring if keyring contains it
* Apply suggestions from code review
Co-authored-by: Jim <jlambert@hashicorp.com>
---------
Co-authored-by: Jim <jlambert@hashicorp.com>
Timothy Messier
Jeff Mitchell
Michael Li
Todd
Ikko Eltociear Ashimine
Stan Ryzhov
Johan Brandhorst-Satzkorn
Dan Heath
Jim
Elim Tsiagbey
Louis Ruch
Irena Rindos
Yong Zhang
hashicorp-tsccr[bot]andhashicorp-tsccr[bot]
Heat Hamilton