It's possible there are acceptable use cases for still matching account
ID if the account no longer maps to a user, but it's equally possible
that this can cause confusion. Removing it seems safer.
The changed auth logic + verify logic in the scope handler pass the
parent ID for validation, which is correct, as a scope lives in its
parent ID. However, the global scope has no parent, and the changes
resulted in an empty ID being passed in rather than the global scope
itself. This fixes that lookup.
* Shave off an IAM lookup if the user is the anonymous user
* Fix build
* If authz failures are turned off, make the token type unknown instead of invalid
* Change returned token format when authz failures are disabled
* Change logic back
* Fix logic
* Encrypt tokens on the way out and decrypt on the way in
This isn't a security feature related to tokens specifically; it's so
that we can discard cryptographically bad tokens before we ever hit the
DB. This way we can't pass through a DDoS to the database due to
fetching obviously invalid token values.
I'm using base58 to encode the resulting value as there aren't great
base62 options, and allowing base64 / and + values can hamper usability
by creating copying/highlighting breaks.
* Change auth validity feedback
Move from a bool indicating validity to lack of an error. This allows
the error to be directly returned and typed.
* Fix erroneous line
Don't rely on token for scopes collection actions
This requires `scope_id` to be passed (via query param) for actions on
the scopes collection; that is, listing or creating. However, it removes
the dependency on using the token for the scope of the command. For
actions on a specific scope, we use the given ID to determine the scope
we should be operating at, doing a lookup if necessary.
Existing tests have been updated. Of particular note, the CORS test was
already operating on the scopes collection so served as a good test to
ensure that from an API level the scope_id parameter was being parsed
and passed through (the tests fail without adding that query parameter
in).
* Move verification to a shared package
The verifier is constructed at HTTP request time and added to the
context. It can then be called from appropriate handlers with
standardized error handling after all the routing.
I intentionally did not add to the handlers yet as I am a good distance
into the scope updates and didn't want to cause even more merge
conflicts. So at the moment authz is again disabled, but once the scope
updates are done, this will be integrated back in.