Azure / azure-cosmos-dotnet-v3

.NET SDK for Azure Cosmos DB for the core SQL API
MIT License
743 stars 496 forks source link

Emulator not using Generated Key and only shows default key #863

Closed pseudoramble closed 5 years ago

pseudoramble commented 5 years ago

I just want to start by saying thanks for the effort and work you all do. It's highly appreciated! I think I'm just missing a step in the setup honestly, but I don't see a good place to chat and ask for help. So I'm starting here.

Describe the bug When starting up the Cosmos DB Emulator following these instructions (https://docs.microsoft.com/en-us/azure/cosmos-db/local-emulator) it seems like the key I've specified is not being used as I would expect. I believe this is the case because the Primary Key in the connection strings is not matching what is in the key file.

I am attempting to set this up via the Mongo connection for now until we're ready to test/convert to the official Cosmos connection and drivers. When I attempt to connect to it using the Mongo CLI or through the C# Mongo Driver, I receive an unable to authenticate error.

To Reproduce

  1. Set up a Windows machine and install the latest Cosmos DB emulator.
  2. Stop the Cosmos DB emulator and ensure no instances are running via the task manager.
  3. Delete any old Cosmo DB emulator data from the local data directory.
  4. Generate a new key by running Microsoft.Azure.Cosmos.Emulator.exe \GenKey=somefile.txt
  5. Start up Cosmos DB by running Microsoft.Azure.Cosmos.Emulator.exe /EnableMongoDbEndpoint /AllowNetworkAccess /KeyFile=somefile.txt. Alternatively you can pass /Key={contents-from-somefile.txt} and see the same issue. EDIT: I accidentally wrote \ instead of / but I have been using / in the actual commands. Fixed that.
  6. Wait for the UI to appear.

Expected behavior The Primary Key field and connection strings contain the new key. These values can be used to connect to the Cosmos DB emulator instance.

Actual behavior The Primary Key field and connection strings contain the default key. Both the values listed in these fields and simply hard-coding the key as it should be into the connection strings results in an authentication failure.

Environment summary SDK Version: Currently using Mongo Driver to begin testing and migrating over to the Cosmos SDK instead. Emulator version: 2.5.6.0 OS Version (e.g. Windows, Linux, MacOSX): Windows 10 VM guest running via VirtualBox on an OS X Mojave host

Additional context The errors listed below are running from the host system which is OS X Mojave.

I have a Windows 10 VM running via Virtual Box. I have ensured that I can make it through any firewalls by disabling them or otherwise. I was having issues with the SSL certs, but I fixed this by telling Mongo to ignore any SSL validations and setting up the C# Mongo Driver to bypass SSL certificate checks as it's suggested:

settings.SslSettings = new SslSettings()
{
    ...
    ServerCertificateValidationCallback = (req, cert, chain, err) => true,
};

The top of the stack trace I'm getting is this:

MongoDB.Driver.MongoAuthenticationException: Unable to authenticate using sasl protocol mechanism SCRAM-SHA-1. ---> MongoDB.Driver.MongoCommandException: Command saslContinue failed: Authentication Failed. ConnectionId 1bf1db2c-8887-4a90-992a-feb927befb42 ActivityId: ce5a1b65-0000-0000-0000-000000000000.

And when trying it through the Mongo CLI:

[js] Error: Authentication Failed. ConnectionId a62618cd-0c17-4d53-ab75-dd69feb83863 ActivityId: dc407edc-0000-0000-0000-000000000000 :

I've also tried to do the same thing with the default key and see the same issue.

j82w commented 5 years ago

@milismsft can you take a look?

j82w commented 5 years ago

@pseudoramble I just did a quick test with using a custom key, and I think I figured out your issue. You need to use / on the settings not \. Try setting the DisableRateLimiting to verify the setting are getting applied.

CosmosDB.Emulator.exe /DisableRateLimiting /EnableMongoDbEndpoint /AllowNetworkAccess /Key="MySuperSecretKey" There does seem to be a bug in the data explorer. It always shows the default key even though I can connect to it with the key specified in the override.

pseudoramble commented 5 years ago

Ah shoot. I made a mistake in my description write-up. I am using / and not \. Sorry about that.

To verify I did try adding in /DisableRateLimiting and it does appear that setting took effect as far as I can see.

pseudoramble commented 5 years ago

@j82w - One thing I did notice is that you have the secret key quoted in the argument. That's one thing I am not doing. Does it need to be? I tried it out and didn't make any change but it's good to know anyway.

j82w commented 5 years ago

As long as the key doesn't have any spaces then the quotes should be optional. The fact that both the default key and new key aren't working means that it's likely something else. Did you update the connection string to include ssl?

pseudoramble commented 5 years ago

Yes. The connection string I have ismongodb://192.168.99.100:{KeyWithoutCurlyBraces}@192.168.99.100:10255/admin?ssl=true

j82w commented 5 years ago

Does it work if you use the default key for everything?

pseudoramble commented 5 years ago

It just dawned on me what the issue is. I was supplying the wrong username, of course! 🤦‍♂

The connection string was originally mongodb://192.168.99.100:{KeyWithoutCurlyBraces}@192.168.99.100:10255/admin?ssl=true. That's saying the username is 192.168.99.100 and the password is whatever the key is. I switched the connection string to mongodb://localhost:{KeyWithoutCurlyBraces}@192.168.99.100:10255/admin?ssl=true and everything starts running just fine.

The answer here is that to login you need to use the right credentials. So that's an a boring end to this thread.

It does lead me to a few other questions:

pseudoramble commented 5 years ago

I suppose also the key not showing up in the UI is problematic. The generated key I've specified appears to work just fine but it's confusing since it's not in the connection string fields.

Is the emulator also open sourced yet? I would be glad to try and see if I can fix the issue and open a PR for it.

milismsft commented 5 years ago

@pseudoramble The UI shows the default key more or less as an example of how the connection string is built. We cannot show the private key because the Data Explore page does not have any authentication and it is accessible from any web client that knows the computer name or the IP of it; showing the user's private key if one set, it will defeat the whole purpose of securing the connection to the public emulator instance. I do agree that we should make it more clear in the current Web page that the key value and the connection strings reflect the default key and not the one set by the user. We will try to change that in a future release of the emulator.

Regarding the initial issue which I could not reproduce but it sounds like you were able to figure out on your own, yes in addition to the key and disabling the SSL and allowing the invalid certificate (unless you can export than import the certificate generated from the emulator's host), you also need to specify the user as "localhost". Here's my full Mongo CLI command I use to connect to the emulator's endpoint using the default key: ' mongo.exe 127.0.0.1:10250 -u localhost -p C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw== --ssl --sslAllowInvalidCertificates '

pseudoramble commented 5 years ago

Those reasons make sense to me. Thanks for clarifying!