A refresh request must fail if it asks for scopes that were not
originally granted when the refresh token was obtained.
This Commit:
* changes repo to store scopes with tokens
* changes repo interface signatures so that scopes can be stored and
verified
* updates dependent code to pass along scopes
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
In --no-db mode, load passwords from the users file instead of the
connectors file. This allows us to remove the password infos field
from the local connector and stop loading them during connector
registration, a case that was causing panics when using a real
database (see #286).
Fixes#286Closes#340
This change solves the User's API problem when you want to create an user that its email hasn't been verified yet but it exist.
At now, you can resend invitation email using endpoint /users/{id}/resend-invitation
Fixes#184
The DB implementation expects secrets to be base64 encoded blobs.
Because of this a bunch of tests broke moving to sqlite.
A lot of this commit is fixing those tests.
This commit moves the user.Manage to its own package (user/manager)
so it can import the connector package in a later commit.
For clarity, it renames "Manager" to "UserManager" using gorname.
This commit has no functional changes.
Invite emails are essentially just reset password emails with a
different template (though this can and probably will change (slightly)
in the near future)
Admin API now requires a 128 byte base64 encoded secret to be passed in
Authorization header, closing up a potential security hole for those
who expose this service.
