Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-7831

Add server accepts incorrect password for uninitialized node

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0, 2.0.1, 2.1.0
    • Fix Version/s: bug-backlog
    • Component/s: RESTful-APIs, UI
    • Security Level: Public
    • Labels:
      None
    • Triage:
      Untriaged
    • Is this a Regression?:
      Yes

      Description

      If I click add server from the server-nodes tab in the UI to add a new server, it ignores the password I added if I tried to add an unitialized node to the cluster.

      If the password doesn't match whats set for the node it should give me an error message telling me that the password is incorrect.

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

        Activity

        Hide
        daschl Michael Nitschinger added a comment -

        Yes I think we go in the right direction now!

        Regarding your comment: but isn't it the case that we don't refuse the password in a no-password scenario when the password is passed in? Thats what confuses me in this case.

        Show
        daschl Michael Nitschinger added a comment - Yes I think we go in the right direction now! Regarding your comment: but isn't it the case that we don't refuse the password in a no-password scenario when the password is passed in? Thats what confuses me in this case.
        Hide
        siri Sriram Melkote added a comment -

        It seems to me that the cleanest solution would be this flow:

        (a) On entering the page, IP address field is enabled; Username/Password and Submit are disabled
        (b) User puts in IP address (or name) of the node and clicks on a validate button
        (c) We make a AJAX call to see if the node is already initialized
        (c) If yes, username/password fields become enabled (otherwise, they remain disabled)
        (d) Submit button becomes enabled

        This will ensure that the user is asked for a username/password only when it is necessary. And when asked, it is always used.

        Show
        siri Sriram Melkote added a comment - It seems to me that the cleanest solution would be this flow: (a) On entering the page, IP address field is enabled; Username/Password and Submit are disabled (b) User puts in IP address (or name) of the node and clicks on a validate button (c) We make a AJAX call to see if the node is already initialized (c) If yes, username/password fields become enabled (otherwise, they remain disabled) (d) Submit button becomes enabled This will ensure that the user is asked for a username/password only when it is necessary. And when asked, it is always used.
        Hide
        alkondratenko Aleksey Kondratenko (Inactive) added a comment -

        I was thinking about something like that too. But only very briefly.

        I still believe accepting empty password is not by itself a problem. Real confusion is that fresh people are trying to enter password when there's no reason to enter password.

        I'm specifically referring to fresh people because people like me or Trond are not fresh and are "tainted" by older experience where UI always demanded non-empty password even when target node did not have any. That was indeed stupid and very confusing. But that wrong behavior is gone.

        So before doing anything I'd really like to understand why this confusion happens. And from Michael's words it appears that people are confusing our credentials fields as credentials to assign, not as credentials to try during join.

        I want to make sure we're fixing real issue, not merely symptom (which again by itself I'm pretty sure is not at all a problem).

        Show
        alkondratenko Aleksey Kondratenko (Inactive) added a comment - I was thinking about something like that too. But only very briefly. I still believe accepting empty password is not by itself a problem. Real confusion is that fresh people are trying to enter password when there's no reason to enter password. I'm specifically referring to fresh people because people like me or Trond are not fresh and are "tainted" by older experience where UI always demanded non-empty password even when target node did not have any. That was indeed stupid and very confusing. But that wrong behavior is gone . So before doing anything I'd really like to understand why this confusion happens. And from Michael's words it appears that people are confusing our credentials fields as credentials to assign , not as credentials to try during join . I want to make sure we're fixing real issue, not merely symptom (which again by itself I'm pretty sure is not at all a problem).
        Hide
        daschl Michael Nitschinger added a comment -

        Alk, yes, this but also allowing to enter a pass when it actually has none.

        From what sriram is proposing, to me that sounds very good and intuitive!

        Show
        daschl Michael Nitschinger added a comment - Alk, yes, this but also allowing to enter a pass when it actually has none. From what sriram is proposing, to me that sounds very good and intuitive!
        Hide
        alkondratenko Aleksey Kondratenko (Inactive) added a comment -

        Doing extra work for nothing doesn't sound like good idea to me.

        Passing to Anil and whatever he says we'll do.

        Show
        alkondratenko Aleksey Kondratenko (Inactive) added a comment - Doing extra work for nothing doesn't sound like good idea to me. Passing to Anil and whatever he says we'll do.

          People

          • Assignee:
            pavel Pavel Blagodov
            Reporter:
            trond Trond Norbye
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:

              Gerrit Reviews

              There are no open Gerrit changes