- Change the tag check bar to only select the current page (by default), but allow for selecting ALL tags
- Limit the number of tags compared in the visualization view to 10
- Fix the multiselect dropdown to limit itself to 10 items selected
- Remove saving the selected tags in the URL, as it is too slow and overloads the URLs in Chrome when there are 1000+ tags selected
- Change the images API to not return locations: By skipping the extra join and looping, it made the /images API call 10x faster (in hand tests)
Fixes#292Fixes#293
When the user commits the configuration, if they have chosen a non-DB auth system, we now auto-link the superuser account to that auth system, to ensure they can login again after restart.
Before this change, we used extremely inefficient outer joins as part of a single query of lookup, which was spiking our CPU usage to nearly 100% on the query. We now issue two separate queries for popularity and action account, by doing a lookup of the previously found IDs. Interestingly enough, because of the way the queries are now written, MySQL can actually do both queries *directly from the indicies*, which means they each occur in approx 20ms!
Verified by local tests, postgres tests, and testing on staging with monitoring of our CPU usage during lookup
Add a new scope for SUPERUSER that allows delegated access to the superuser endpoints. CA needs this so they can programmatically create and remove users.
This authentication system hits two HTTP endpoints to check and verify the existence of users:
Existance endpoint:
GET http://endpoint/ with Authorization: Basic (username:) =>
Returns 200 if the username/email exists, 4** otherwise
Verification endpoint:
GET http://endpoint/ with Authorization: Basic (username:password) =>
Returns 200 and a signed JWT with the user's username and email address if the username+password validates, 4** otherwise with the body containing an optional error message
The JWT produced by the endpoint must be issued with an issuer matching that configured in the config.yaml, and the audience must be "quay.io/jwtauthn". The JWT is signed using a private key and then validated on the Quay.io side with the associated public key, found as "jwt-authn.cert" in the conf/stack directory.
Currently, we use the Quay username via `verify_user` when we go to create the encrypted password. This is only correct if Quay has not generated its own different username for the LDAP user, and fails if it has. We therefore add a new method `confirm_existing_user`, which looks up the federated login for the LDAP user and then runs the auth flow using that username.
