Update portal to allow specifying custom uri_prefix at runtime

[max-k]

To deploy harbor and notary using the same hostname, I need to be able to use custom paths. Unfortunately, it's impossible yet mainly because the Angular app cannot be configured at runtime before it's first api call.

This issue is related to the following Pull Request : https://github.com/goharbor/harbor-helm/pull/143

Ideally, I wish to able to set or query param, a cookie or an environment variable to make Angular application to use an URI prefix for all of its API calls.

It seems that the first problem is that, in src/app/app-config.service.ts, systemInfoEndpoint, the API endpoint used to get Harbor configuration is hardcoded.

Also I have now easy way to transmit params to the Angular application at runtime (eg. systemInfoEndpoint URL).

Even if I was able to transmit a parameter to customize this URL, there is no way to easily set uri_prefix globally. We have to redefine all endpoints URLs.

In a try to fix this issue rfom the outside, without touching to the Angular app, Iadd additional annotations to the ingress configuration:

nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/add-base-url: "true"

It works properly for the HTML part of the app but unfortunately not for API calls.

Maybe it is more a feature request than an issue.

Thank you for your help.

[reasonerjt]

@max-k With initial thinking, I believe it's possible to allow user to set prefix, but we need to balance the complexity in configuration, we don't want to add to many settings that may confuse users until we have to.

Could you let us know the motivation of this requirement?

Do you want same or different prefix for registry and notary and Harbor API? I believe docker client will only communicate with /v2/ api, not /prefix/v2.

In addition, I recall there used to be a bug in notary to support prefix in its service and I submitted a patch. We'll also need to double check whether it's included in the latest build of notary.

[max-k]

Hi @reasonerjt, Thank you for your quick answer.

There is a lot of use-cases where this feature could be interesting.

• A/B testing on the same domaine name.
• Infra where we deploy a service for a customer using sub-domains and a wildcard ssl certificate. Here we can only use one level of subdomains so all our URLs have to be accessible using the same subdomain.

It could maybe be sufficient if you remove this line so we could enforce it using, for example, an annotation, in nginx ingress (in the context of kubernetes/harbor-helm).

Because, yet, if we add the annotation specified in the first, it results in two different base headers.

Thank you very much.

[ghost]

Hi @max-k – can you please clarify this bit:

Infra where we deploy a service for a customer using sub-domains and a wildcard ssl certificate. Here we can only use one level of subdomains so all our URLs have to be accessible using the same subdomain.

Is the idea here that you'd have separate instances of Harbor running on different subdomains? (sorry, haven't had my second cup of coffee yet so I'm likely misunderstanding something)

[solidDoWant]

I'm not OP but I can speak to their issue as their setup is a semi-common practice. Consider a SaaS company with domain "company.com" and services "custom-service" and "harbor" that they provide to customers "customer-a" and "customer-b". These services are provided to customers as 'single tenant' services, where multiple clients don't share the same instance of the service. The company provides access to all a given customer's services at "customer-a.company.com" or "customer-b.company.com". So if customer-a has both services custom-service and harbor, they are available at "custom-service.customer-a.company.com" and "harbor.customer-a.company.com".

This works great until the company or customer wants to use HTTPS and therefor SSL/TLS certificates. The problem is that certificate authorities only provide one 'tier' of wildcards on the common name of certificates, i.e. ".company.com". They won't sell you a certificate for "..company.com". As a result, the company is forced to purchase wildcard certificates for every customer. This has several downsides including cost and maintenance complexity. At first glance, Digicert charges $788 per year for wildcard certificates (i.e. .customer-1.company.com). When you scale up to a thousand customers, this becomes very expensive and difficult to manage.

One of the solutions to this issue is to put the services custom-service and harbor behind a reverse proxy. The reverse proxy (i.e. nginx, haproxy, traefik) matches incoming requests and routes them to a specific backend service, as well as handles SSL/TLS termination. The company may point all customer domains ("customer-a.company.com", "customer-b.company.com") to the reverse proxy, and then route HTTP requests to a specific backend service based upon the host header (domain name associated with request) and path prefix (i.e. /custom-service or /harbor). This results in a request for "https://customer-a.company.com/harbor" to be sent to a specific internally hosted harbor instance.

The downside of this approach is that most of the time the service needs to support a URL "base prefix". The internally hosted harbor instance won't see requests coming in for "https://customer-a.company.com/someHarborPage.html". Instead, it will see requests coming in for "https://customer-a.company.com/harbor/someHarborPage.html". As a result, the service controllers may not know what function to map the request to/where to route the request. By adding a setting for a URL base prefix all of these problems are solved.

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.