Ensure Objects API and ObjectTypes API work behind a gateway (eg. the 'OPENZAAK_DOMAIN' pattern), with optionally a subpath

[alextreme]

With Open Zaak we have the OPENZAAK_DOMAIN envvar which functions as a 'forced' X-Forwarded-For setting to switch the install do a different domain name.

This is being used by more gemeentes to make use of components behind an API gateway. The problem (without changes) is that URLs used by a component is then the internal URL instead of the API gateway URL (eg: using 'https://api.amsterdam.nl/zgw/objects' instead of 'https://objects.amsterdam.nl')

Nore that it's about more than the domain name, an API gateway often differentiates between backend APIs using a subpath. So in the example above, /zgw/objects would point to our Objects API, while /zgw/openzaak would point to Open Zaak.

Ensure that OIDC and references to other components works as expected (note open-zaak/open-zaak#1585 and open-zaak/open-zaak#1592 ). Also ensure the admin still works using the internal domain name ( open-zaak/open-zaak#1561 )

OZ implementation: open-zaak/open-zaak#1020

Needed/Expected for Amsterdam (APIM) and Rotterdam (HIP)

Components

• Open Zaak
• Open Notifications
• Objects API
• Objecttypes
• Open Klant
• Referentielijsten

[joeribekker]

Blocked by #1585

[joeribekker]

Discussed in Weekly: We're not going to use the OPENZAAK_DOMAIN pattern but instead the X_FORWARDED_HOST solution.

[alextreme]

Depends on open-zaak/open-zaak#1629 (if that issue is completed, this one should be done too)

[alextreme]

Discussed, can be closed after the subpath and xforwardedfor settings are included into OAF, in that case no further steps are necessary for the Objects API

[stevenbal]

open-zaak/open-zaak#1629 was completed, so all of the components now have X_FORWARDED_HOST, this will be visible in each project's docs once open-zaak/open-zaak#1649 is done