* wip
* implement list pagination for auth methods
* remove unused code
* update tests to fix sorting
* address PR comments
* simplify query, add token tests
* change test name
* wip sql testing
* add boolean column to indicate whether auth methods should be returned to unauthenticated users, remove secrets from api response
* is_active_public not null
* remove secrets and unwrapping
* move not null to immediately after data migration
* order public_id descending
* fix(db): Fix auth method migrations (#4193)
* wip
* fix db tests
* fix failing api tests
* reverse order of create time and update time in test
---------
Co-authored-by: Michael Gaffney <mike@gaffney.cc>
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids this issue.
* Do not cache or allow searching for old controllers
* Identify resourceless responses as coming from supported or unsupported controllers
* Do not report refresh token status info for unsupported controllers
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
All times in the list tokens are sourced from the database,
and any comparisons to times in the application can
cause false positive validation errors. We've observed
this from multiple users of the pagination logic, and
the value of this validation is very little compared
to the cost of a single false positive error like this
happening to a real world customer. Therefore, remove
any list token validation using the application time,
except the one monitoring for token expiry, which
should not suffer from the issue to a degree
that matters to our users.
Also refactor validation such that the list token subtype
constructors only perform sanity checks on the values
while punting business logic validation to the validate
method on the new token. This means we avoid
duplicating logic.
The iam package is very foundational, and now depends
on the pagination package. Thus, the pagination package
must not import any packages that may import iam,
such as the plugin package. Move the plugin helpers
to a subdirectory to avoid this import cycle.
