Prior to this commit, individual providers did not handle
redirect-uri. They would set the field to `Nothing` and then
this library would build a callback using the app's url-renderer.
This means that apps had to use approot static, because such
redirect-uri's have to be absolute.
This minor change just respects any redirect-uri a provider has
set already. That mean that apps that must use a relative
approot can now use our library as long as they use a provider that
handles redirect-uri for them (ensuring it's absolute by whatever
means it can) ahead of our own callback construction.
The only breaking change seems to be the error type, which we were
already wrapping in `CPP` and our own `Errors` synonym for 2.7. All this
change does is add a 2.9 case and move some thing around so it's
syntactically nicer.
This is the same as the `AzureAD` plugin except:
1. It uses tenant-specific `microsoftonline.com` v2 OAuth2 endpoints
(hence the name), which means accepting a new Tenant Id argument
2. It uses a space instead of `,` as the scopes separator
Users of multi-tenant apps can provide a Tenant Id of `"common"`. I'm
also not certain if the space-vs-comma scopes separator represents a bug
in the `AzureAD` plugin, or just a difference in the actual v2 APIs.
This inherits the behavior of using email address as the `credIdent`
although this is definitely an `id` field in the User Response. I'm not
sure if there are trade-offs one way or another. Using `id` could mean
transparently handling Azure users changing their email, but I suspect
your identity is implicitly tied to email within Azure anyway, so that
would not be a case we'll ever see.
In the future, we can deprecate the `AzureAD` plugin and suggest users
migrate to this one.
LTS-19 and GHC-9.2 is coming. Adding this to ensure we can compile,
which seems to be the case.
We are only disabled in Stackage because hoauth2 is not ready, for which
I've opened: https://github.com/freizl/hoauth2/issues/142
This required a lot of CPP refactoring and extension. I plan to shift
our lower bound and target only the newer hoauth2 soon, but I'd like to
get out a compatible version first, which this aims to do.
The comments in Compat.hs try to explain the gymnastics we have to
endure to get there. I'm sorry, it's not ideal.
This supports the lowest LTS we test with. This was working before
because the bound was only set on publish and not in source, with it in
source it needs to work for all our tested LTSs.
It seems future resolvers will actually use a lower version of this
package (0.6.4.x) than current LTS (0.6.5.x) for some reason, so using
--pvp-bounds=lower on release is too restrictive for (e.g.) nightly.
Our latest version (0.7.0.0) has had this bound relaxed by revision.
This commit just aligns main and need not be released.
