I've added some output to the generated migrations files to make them
easier to recreate, hence the big diff.
These are important:
```
persistence/sql/migrations/20211004110001000000_change_client_primary_key.cockroach.down.sql
persistence/sql/migrations/20211004110001000000_change_client_primary_key.cockroach.up.sql
persistence/sql/migrations/20211004110003000000_change_client_primary_key.cockroach.down.sql
persistence/sql/migrations/20211004110003000000_change_client_primary_key.cockroach.up.sql
persistence/sql/migrations/20211011000001000000_change_jwk_primary_key.cockroach.down.sql
persistence/sql/migrations/20211011000001000000_change_jwk_primary_key.cockroach.up.sql
persistence/sql/migrations/20211011000003000000_change_jwk_primary_key.cockroach.down.sql
persistence/sql/migrations/20211011000003000000_change_jwk_primary_key.cockroach.up.sql
persistence/sql/src/20220210000001_nid/20220210000001000000_nid.cockroach.up.sql
```
Closes#3964
Supersedes #3993 (thanks @hperl)
This patch adds the ability to execute down migrations using:
```
hydra migrate sql down -e --steps {num_of_steps}
```
Please read `hydra migrate sql down --help` carefully.
Going forward, please use the following commands
```
hydra migrate sql up ...
hydra migrate sql status ...
```
instead of the previous, now deprecated
```
hydra migrate sql ...
hydra migrate status ...
```
commands.
See https://github.com/ory-corp/cloud/issues/7350
This patch changes the internal data structure and reduces four (sort of redundant) tables into one. As part of this change, a few new tools have been added:
* Introduce the `hydra sql gen` command and a convenience Make target with autocompletion. The command reads migration templates from a source directory and produces migration files in a target directory. Its main function is to split a single source file into multiple files using split marks.
* Introduce the `hack/db-diff.sh` command to generate database schema diffs at different commits. This script is used to view and review the impact of migrations on the database schema.
BREAKING CHANGES: This patch merges four SQL Tables into a new table, deleting the old tables in the process. The migrations in this patch are expected to be applied offline. Please be aware that *there are no down migrations*, and if something goes wrong, data loss is possible. Always back up your database before applying migrations. For more information, see [Hydra 2.x Migration Guide](https://www.ory.sh/hydra/docs/guides/migrate-v2).
Rows with NULL login_challenge in `hydra_oauth2_consent_request` and corresponding `hydra_oauth2_consent_request_handled` are deleted as a side effect of the merge migration. This is done with the assumption that only a very small number of sessions, issued by pre-1.0 Hydra, will be affected. Please contact us if this assumption doesn't apply or if the deletion adversely affects your deployment.
Signed-off-by: Grant Zvolsky <grant@zvolsky.org>
BREAKING CHANGES: After battling with [spf13/viper](https://github.com/spf13/viper) for several years we finally found a viable alternative with [knadh/koanf](https://github.com/knadh/koanf). The complete internal configuration infrastructure has changed, with several highlights:
1. Configuration sourcing works from all sources (file, env, cli flags) with validation against the configuration schema, greatly improving developer experience when changing or updating configuration.
2. Configuration reloading has improved significantly and works flawlessly on Kubernetes.
3. Performance increased dramatically, completely removing the need for a cache layer between the configuration system and ORY Hydra.
4. It is now possible to load several config files using the `--config` flag.
5. Configuration values are now sent to the tracer (e.g. Jaeger) if tracing is enabled.
Please be aware that deprecated configuration flags have finally been removed with this change. It is also possible that ORY Hydra might complain about an invalid configuration, because the validation process has improved significantly.
This patch deprecates the previous migration system (sql-migrate) in favor of gobuffalo/fizz. No functional changes have been made.
BREAKING CHANGES: Please run `hydra migrate sql` before applying this release.
This patch enables developers to whitelist insecure redirect URLs while using flag `--dangerous-force-http`.
Closes#1021
Signed-off-by: aeneasr <aeneas@ory.sh>
This patch significantly refactors internal configuration and service management with the goal of making configuration changes possible without service restarts. This patch prepares the possibility to configure ORY Hydra from a remote source (etcd, consul) and watch for changes. This patch also introduces the possibility to configure ORY Hydra from a configuration file on top of environment variables.
The following issues have been fixed as well:
- Key rotation of the system secret is now much simpler (closes#1316)
- Database connectivity parameters such as max_conns no longer cause issues with older postgres versions (closes#1327)
- Non-existing routes now return a JSON error instead of `text/plain` when `application/json` was requested (clsoes #1244)
- We now push tags latest, X, X.Y, X.Y.Z to docker hub (closes#1289)
- The quickstart guide no longer builds the source code but instead pulls latest tag (closes#1309)
- We moved to goreleaser and godownloader for release management (closes#1107)
- The quickstart Docker Compose files are now reusable (closes#1196)
The following issues are also resolved:
- Closes#1121
Signed-off-by: aeneasr <aeneas@ory.sh>
This patch adds the ability to whitelist and request an audience
when performing any OAuth 2.0 Flow. The audience is useful in multi-
tenant environments where access tokens should be restricted to certain
resources.
Closes#883Closes#1144
Signed-off-by: arekkas <aeneas@ory.am>
This patch resolves an issue which made it impossible to rotate secrets because an un-hashed version was used.
Closes#1026
Signed-off-by: arekkas <aeneas@ory.am>
This patch makes significant changes to the consent flow. First,
the consent flow is being renamed to "User Login and Consent Flow"
and is split into two redirection flows, the "User Login Redirection Flow"
and the "User Consent Flow".
Conceptually, not a lot has changed but the APIs have been cleaned up
and the new flow is a huge step towards OpenID Connect Certification.
Besides easier implementation on the (previously known as) consent app,
this patch introduces a new set of features which lets ORY Hydra
detect previous logins and previously accepted consent requests. In turn,
the user does not need to login or consent on every OAuth2 Authorize Code
Flow.
This patch additionally lays the foundation for revoking tokens per
user or per user and client.
Awesome.
Closes#771Closes#772
We have learned a lot over the last year in terms of how ORY Hydra is being used. Initially, we wanted to avoid the problems facing popular databases like MongoDB or others, which did not include authentication for their management APIs.
For this reason, the Warden API was born and primarily used internally and exposed via HTTP. We learned that access control policies are well received, but also add additional complexity to understanding the software. While we firmly believe that these policies implement best practices for access control in complex systems, we do understand that they add a barrier to getting started with ORY Hydra.
For this reason we are planning on moving the Warden API from this project to ORY Oathkeeper or potentially it's own server. We would add a migration path for existing policy definitions to the new service. The default docker image would combine the services in such a way, that ORY Hydra is protected. We would additionally have an (insecure) docker image without authentication which can be used for testing.
This also opens up the possibility of having more access control mechanisms than access control policies. For example, we can add ACL and RBAC and other mechanisms too.
First I think it makes good sense to move this functionality into a separate service and remove the warden calls internally completely. The reason being that not everyone wants to rely on Hydra's access control. Sometimes it's enough to use a gateway in front and require e.g. an API key for management or whatever. New adopters are always baffled by complexity involved with policies and scopes. Removing that from the core could really help. The user survey has also shown that this stuff is quite complex to grasp.
The idea is to have a separate service which is basically ladon as a HTTP API. I think it makes sense to add some functionality to resolve access tokens so it would basically be very similar to the current warden API - probably even equal. There would definitely be some backup mode where hydra's database tables and migrations are used as to make migration as easy as possible.
Then, we would ship docker images and example set ups where different configurations are shown. One of the configurations would be the current one, so basically what we have now in hydra but with the three services combined in one image.
Closes#807
Arne Luenser
hackerman
Kevin Goslar
Grant Zvolsky
aeneasr
Patrik
David
Sawada Shota
prateek1192
arekkas
Aeneas