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
When reading migrations from files, sql-migrate attempts to split
SQL statements. The parsing logic does not handle $BODY$ statements
and broke when the migration included one.
Replace go-bindata with a small migration generation script and use
in memory migrations instead.
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.
Passing an empty list to the overlord or worker's --key-secrets
flag currently causes an out of range panic. Always check to ensure
there's at least one element passed.
Fixes#130Fixes#217
This enables us to control the length of the bytes that will be bcrypted,
by default it's 64.
Also changed the token's stored form from string('text') to []byte('bytea')
and added some test cases for different types of invalid tokens.
The first secret is used to encrypt, the rest are for decryption; if the
first doesn't work, the rest are tried in order.
The makes it possible to rotate keys.
