Invalid Password after upgrading to CB v4.6

After upgrading to coucbhase 4.6 from 4.5.0 I have started receiving the following InvalidPasswordException. I’ve never had bucket passwords before only password to login to couchbase Admin console. The admin console credentials are the same as what i used in 4.5 although i dont think they were never used before. is this something new in 4.6? this is for local development so i would rather not have a password on buckets if possible. Using java client 2.2.1 Passwords for bucket “myBucketName” do not match.
at$ ~[java-client-2.2.1.jar:na]
at$ ~[java-client-2.2.1.jar:na]
at rx.internal.operators.OperatorOnErrorResumeNextViaFunction$4.onError( ~[rxjava-1.2.4.jar:1.2.4]
at rx.internal.operators.OnSubscribeMap$MapSubscriber.onError( ~[rxjava-1.2.4.jar:1.2.4]
at rx.observers.Subscribers$5.onError( ~[rxjava-1.2.4.jar:1.2.4]
at rx.internal.operators.OperatorObserveOn$ObserveOnSubscriber.checkTerminated( ~[rxjava-1.2.4.jar:1.2.4]
at rx.internal.operators.OperatorObserveOn$ ~[rxjava-1.2.4.jar:1.2.4]
at ~[rxjava-1.2.4.jar:1.2.4]
at java.util.concurrent.Executors$ ~[na:1.8.0_91]
at ~[na:1.8.0_91]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201( ~[na:1.8.0_91]
at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.runWorker( ~[na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor$ ~[na:1.8.0_91]
at ~[na:1.8.0_91]

User error. After killing my database I didn’t recreate the needed buckets. Wouldn’t have been helpful to have a more accurate exception which conveys the Bucket doesn’t exist.

Glad you’ve resolved it @mlblount45.

Regarding conveying that the bucket doesn’t exist, you’ll be glad to know we have some enhancements already being implemented to address this. I had originally proposed some improved error handling and between @trond and @mnunberg, we’ve expanded that into improved error handling in a number of situations. It’s still in development, but some details are in sdk-rfc 13.

In the future, this will be much more obvious since we’ll separate authentication from resource access. It’s somewhat necessarily vague at the moment, as from a security perspective the cluster doesn’t give the client info about why something failed, just that it did fail. If it gave info that a bucket existed, an attacker can then probe further to try to access the bucket.

1 Like

sounds good thanks @ingenthr