You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if multitenancy is enabled ,with or without authentication enabled, the default tenant can be used. It's possible to make requests straight to /apis/registry/v2 and it just works, while at the same time it's possible to do it providing the tenantId /t/{tenantId}/apis/registry/v2
I was considering if we should disallow the direct access to the API when multitenancy is enabled... in the case when authentication is enabled is not a big deal because the authentication should fail... but still I thought this idea is worth sharing.
I don't think this is high priority
The text was updated successfully, but these errors were encountered:
I noticed this recently too and it was on my list to open an issue for it. So this is great.
I think we should disable direct access to everything under /apis/* when running in MT mode. Only access via /t/{tenantId} should be allowed. However, I think that should be controlled via application.properties so that we can continue to support a deployment architecture where the tenantId is provided some way other than /t/{tenantId} (e.g. provided as a Request header from some sort of router in front of the app).
so then the ideal solution I think it would be to have a property to enable/disable such check, and to implement the check in RegistryApplicationServletFilter the check will reject the request if no tenant information is found. Currently the tenantId lookup is delegated to TenantIdResolver which already allows for passing the tenantId in a header.
Currently if multitenancy is enabled ,with or without authentication enabled, the default tenant can be used. It's possible to make requests straight to
/apis/registry/v2
and it just works, while at the same time it's possible to do it providing the tenantId/t/{tenantId}/apis/registry/v2
I was considering if we should disallow the direct access to the API when multitenancy is enabled... in the case when authentication is enabled is not a big deal because the authentication should fail... but still I thought this idea is worth sharing.
I don't think this is high priority
The text was updated successfully, but these errors were encountered: