Checking that trusted peers exist means that you have to create clients
in a certain order, or else create all the clients, then update trusted
peers. Either way, not a great experience during setup.
The downside, of course, is that you lose validation of peer
IDs.
The Client object on its own doesn't fully express everything about a
single client, and so when loading clients from a static configuration
it's not enough to just (de)serialize clients.
To that end, LoadableClient contains the full representation of a client
and associated entities.
Replaced by ClientRepoFromClients, which makes more sense IMO. Also, it
was doing the wrong thing: it was ignoring the client_id and client_secret
passed into it as far as I can tell.
* TestCreateClient was missing test coverage on error cases
* Fixed bug where 500s were being reported for bad requests
* changed function signature of NewAdminAPI back to old way of passing
in lots of repos: passing in a DbMap made it difficult to test
* added swappable ID and Secret generators when creating Clients
When client secrets are not base64 encoded, print an error message
that's not a generic base64 decode error:
client secrets must be base64 decodable. See issue #337.
Please consider replaceing "secret" with "c2VjcmV0"
When a user file is missing a mandatory field print an error message.
Unable to build Server: user elroy-foo is missing email field
For #400
The "redirectURLs" field in the client metadata has been updated
to the correct "redirect_uris". To allow backwards compatibility
use Postgres' JSON features to update the actual JSON in the text
field.
json_build_object was introduced in Postgres 9.4. So update the
documentations to require at least this version.