| Safe Haskell | None |
|---|---|
| Language | GHC2021 |
Test.Spar.MultiIngressIdp
Synopsis
- ernieZHost :: String
- bertZHost :: String
- kermitZHost :: String
- makeSpDomainConfig :: String -> Value
- testMultiIngressIdpSimpleCase :: HasCallStack => App ()
- testUnconfiguredDomain :: HasCallStack => App ()
- testMultiIngressAtMostOneIdPPerDomain :: HasCallStack => App ()
- testNonMultiIngressSetupsCanHaveMoreIdPsPerDomain :: HasCallStack => App ()
- testMultiIngressIdPIssuerDifferentDomains :: HasCallStack => App ()
Documentation
ernieZHost :: String Source #
kermitZHost :: String Source #
makeSpDomainConfig :: String -> Value Source #
Create a MultiIngressDomainConfig JSON object with the given zhost
testMultiIngressIdpSimpleCase :: HasCallStack => App () Source #
testUnconfiguredDomain :: HasCallStack => App () Source #
testMultiIngressIdPIssuerDifferentDomains :: HasCallStack => App () Source #
The validateNewIdP rules for IdP creation apply to multi-ingress setups as
well. Depending on the IdP API version, IdP issuers have to be either unique
per backend (V1) or per team (V2).
Note: In multi-ingress setups, one might wonder why the same IdP metadata / issuer cannot be used for the same team across multiple domains. Supporting this would require redesigning spar's database schema (e.g., there would be a race condition on the `spar.issuer_idp_v2` table). Furthermore, IdP configs are strongly URL-related on IdP-side: issuers correspond to e.g. Keycloak realms, which have a specific return-URL. Given the limited practical benefit, this complexity is not justified for now.