Uploaded image for project: 'Couchbase Go SDK'
  1. Couchbase Go SDK
  2. GOCBC-272

Found http prefix in gocb dynamic authenticator

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Critical
    • Resolution: Won't Fix
    • None
    • 1.3.4
    • library
    • 1

    Description

      Regarding the Credentials method that gets called by gocb,

      func (dynAuth *DynamicAuthenticator) Credentials(req gocb.AuthCredsRequest) ([]gocb.UserPassPair, error)

      the req.Endpoint sometimes has http prefix and sometimes it doesn't - 

      For example,

      req.Endpoint is sometimes  http://172.23.104.46:8091, sometimes it's 172.23.104.46:11210.

      Please remove the http prefix to maintain uniformity.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            brett19 Brett Lawson added a comment - - edited

            Hey Gautham Banasandra,
            After evaluating this a bit, I think that the current behaviour is actually correct.  The endpoint does include the scheme when performing http requests.  I suggest you run something like the following to strip the scheme away if your authentication system (ie: cbauth) does not want it.

            func stripScheme(endpoint string) string {
                return strings.TrimPrefix(strings.TrimPrefix(endpoint, "http://"), "https://")
            }
            

            Cheers, Brett

            brett19 Brett Lawson added a comment - - edited Hey Gautham Banasandra , After evaluating this a bit, I think that the current behaviour is actually correct.  The endpoint does include the scheme when performing http requests.  I suggest you run something like the following to strip the scheme away if your authentication system (ie: cbauth) does not want it. func stripScheme(endpoint string) string {     return strings.TrimPrefix(strings.TrimPrefix(endpoint, "http://" ), "https://" ) } Cheers, Brett

            In bug description, another issue that wasn't highlighted was: Endpoint that was passed to eventing http://172.23.104.46:8091 is referring to MgmtService and not DataService i.e. ideally 11210/12000 or similar port is expected. LCB seems to be following this as well.

            asingh Abhishek Singh (Inactive) added a comment - In bug description, another issue that wasn't highlighted was: Endpoint that was passed to eventing http://172.23.104.46:8091 is referring to MgmtService and not DataService i.e. ideally 11210/12000 or similar port is expected. LCB seems to be following this as well.
            brett19 Brett Lawson added a comment -

            Hey Abhishek Singh,
            I'm not sure I am understanding what you are referring to.  In some cases (especially when there are authentication issues), the SDK will attempt to fetch a configuration over the management service (:8091) as opposed to via the CCCP mechanism in memcached (:11210).  This is why you are seeing requests to the management service.  In order for the SDK to behave correctly, it is expected that credentials can still be provided.
            Cheers, Brett

            brett19 Brett Lawson added a comment - Hey Abhishek Singh , I'm not sure I am understanding what you are referring to.  In some cases (especially when there are authentication issues), the SDK will attempt to fetch a configuration over the management service (:8091) as opposed to via the CCCP mechanism in memcached (:11210).  This is why you are seeing requests to the management service.  In order for the SDK to behave correctly, it is expected that credentials can still be provided. Cheers, Brett

            Sorry I wasn't clear earlier, hope I'm successful this time.

            I believe the expectation is req.Endpoint that comes as part of below callback is always host:port combination mapping to a KV node:

            func (dynAuth *DynamicAuthenticator) Credentials(req gocb.AuthCredsRequest) ([]gocb.UserPassPair, error)
            

            In some scenarios, we got valid kv host:port like below from req.Endpoint

            2018-02-27T03:00:53.600-08:00 [Info] UTIL Authenticating endpoint: <ud>10.111.170.103:11210</ud> bucket: metadata
            

            But in some, we have seen below req.Endpoint being sent to callback which isn't mapping to KV host:port. Instead references ns_server endpoint and has http prefix.

            2018-02-25T03:39:49.991-08:00 [Info] UTIL Authenticating endpoint: <ud>http://172.23.104.46:8091</ud> bucket: metadata
            

            Ideally we would expect consistency from GoCB i.e. req.Endpoint should always map to a KV host:port,we could trim http prefixes but certainly don't want Eventing to figure out what port is KV running on, when supplied req.Endpoint is http://172.23.104.46:8091(as we need to replace 8091 with kv port).

            asingh Abhishek Singh (Inactive) added a comment - Sorry I wasn't clear earlier, hope I'm successful this time. I believe the expectation is req.Endpoint that comes as part of below callback is always host:port combination mapping to a KV node: func (dynAuth *DynamicAuthenticator) Credentials(req gocb.AuthCredsRequest) ([]gocb.UserPassPair, error) In some scenarios, we got valid kv host:port like below from req.Endpoint 2018-02-27T03:00:53.600-08:00 [Info] UTIL Authenticating endpoint: <ud>10.111.170.103:11210</ud> bucket: metadata But in some, we have seen below req.Endpoint being sent to callback which isn't mapping to KV host:port. Instead references ns_server endpoint and has http prefix. 2018-02-25T03:39:49.991-08:00 [Info] UTIL Authenticating endpoint: <ud>http://172.23.104.46:8091</ud> bucket: metadata Ideally we would expect consistency from GoCB i.e. req.Endpoint should always map to a KV host:port,we could trim http prefixes but certainly don't want Eventing to figure out what port is KV running on, when supplied req.Endpoint is http://172.23.104.46:8091(as we need to replace 8091 with kv port).
            brett19 Brett Lawson added a comment -

            Hey Abhishek Singh,
            I don't believe that this is the intended behaviour though.  When you get an endpoint of http://X:8091, it indicates that the SDK IS trying to contact the servers management port (and not KV).  It wouldn't make a lot of sense for us to arbitrarily fake the endpoint.  The request that its trying to perform that it needs credentials for has nothing to do with memcached and port 11210.
            Cheers, Brett

            brett19 Brett Lawson added a comment - Hey Abhishek Singh , I don't believe that this is the intended behaviour though.  When you get an endpoint of http://X:8091,  it indicates that the SDK IS trying to contact the servers management port (and not KV).  It wouldn't make a lot of sense for us to arbitrarily fake the endpoint.  The request that its trying to perform that it needs credentials for has nothing to do with memcached and port 11210. Cheers, Brett

            Ok thanks Brett, I just confirmed from cbauth authors that it would work for both cases. Earlier I thought only first would work

            cbauth.GetMemcachedServiceAuth("172.16.12.49:11210")
            cbauth.GetMemcachedServiceAuth("172.16.12.49:8091")
            

            asingh Abhishek Singh (Inactive) added a comment - - edited Ok thanks Brett, I just confirmed from cbauth authors that it would work for both cases. Earlier I thought only first would work cbauth.GetMemcachedServiceAuth("172.16.12.49:11210") cbauth.GetMemcachedServiceAuth("172.16.12.49:8091")

            People

              brett19 Brett Lawson
              Gautham.Banasandra Gautham Banasandra (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty