Couchbase console UI - web app configuration

Hi,

Where can I find the default web app configuration for couchbase console UI.

Thanks.

@Noorkumar Can you please take a look here https://docs.couchbase.com/server/current/manage/manage-security/manage-console-access.html ?

@raju Thank you for the reply.
https://couchbase-ui-{dns name}/clusterId --> this is our url to access the couchbase UI.
for example https://couchbase-ui-app.example.com/abc123
It is not working after we added the cluster Id in the path, before adding the cluster id in the path the url was like https://couchbase-ui-app.example.com and it was working fine.
After path based changes we are not able to access the console UI, it shows blank scree and will not ask for credentials to login.
Is there anything which restrict the path variable to access the console UI

Hi @Noorkumar:
Standard port for the Couchbase HTTPS UI is 18091 - so given that things work when you access https://couchbase-ui-app.example.com, this must mean that you access Couchbase Server through a web proxy that maps the root path (/) to whatever host the server is actually running on, say database-host:18091. If you try to access /abc123 that will map to database-host:18091/abc123 - which will not work as this is not a valid path.

You’ll need to work with whomever has configured the web proxy to map /abc123 -> database-host:18091. Once you have the web proxy in front of Couchbase Server configured this way, it should work.

-dave

Hi @davef Thank you for the support.
Below is the my ingress resource which maps console UI. I try changing the port to 18091 also it didn’t work, I also tried to access the http instead of https but still won’t work. if I remove the path from ingress resource and access
https://couchbase-ui-app.example.com works fine.

spec:
rules:

All the API’s will work fine, like I can post the data with https://couchbase-ui-app.example.com/abc123, I can access the buckets, /pools etc all API’s works fine. I am not able access the console UI only.

HI @Noorkumar - are you running Couchbase Server in Kubernetes deployed with the Couchbase Operator, by chance?

Hi @davef
Yes, We have deployed the Couchbase server in Kubernetes with the Couchbase operator .

Hi @Noorkumar

For most deployments it is highly recommended that one of the supported methods for connecting to Couchbase are used as documented here:

There is a possibility that the Ingress controller will work with the Couchbase Operator, but getting it to work with a rewrite rule may take some additional research into the service itself. If you’re looking for a starting point with ingress, the following should work.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/affinity: cookie
    nginx.ingress.kubernetes.io/affinity-mode: persistent
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          serviceName: example-couchbase-cluster
          servicePort: 8091

Hi @davef @tommie
We are trying to access the UI from https://couchbase-ui-app.example.com/abc123 and cluster id changes for everytime when we create the instance. when I try to access the above url, the page loads but it will prompt for the login and when I look network tab it is excluding the cluster id i.e, abc123 from some API’s like
https://couchbase-ui-app.example.com/pools rather it should have been https://couchbase-ui-app.example.com/abc123/pools
My problem is same as the below.
Config setting for UI base path?

Thanks for your help.

The content shouldn’t need a base path due to relative addressing of HTTP content. However there are number of bugs I can see. First up the HTTP redirect doesn’t work because it doesn’t know about the prefix (mod_rewrite has stripped it). Even then when I manually set the path to /kung-fu-panda/ui/index.html (random prefix… it’s Monday morning), it still doesn’t work, but does look a lot better in the Firefox console.

Unless Dave knows better, and he usually does, my suggestion is to use the hostname to perform multiplexing e.g. cluster-a.domain.com and cluster-b.domain.com, then the proxy should inject X-Forwarded-Host, X-Forwarded-Proto etc. and things will work as you expect. Host based routing (SNI too) is always a better option than doing path based routing, in my opinion. It’s an option to consider if path based routing doesn’t work for you.

Hi @simon.murray Thanks for your reply.
We need to have fixed domain server certificates and cluster are created dynamically that is the reason we are going for path based routing.

Any suggestion to solve the issue will be helpful.

There’s nothing I can personally think of that would allow path routing to work. Someone else may have a suggestion.

I don’t know if this is possible, but you can still use host based routing – with static certificates more importantly – if you get a wildcard issued e.g. *.domain.com, that would work for all the examples in my previous message. They can be wonderfully cheap too.