-
Notifications
You must be signed in to change notification settings - Fork 430
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cosmos EF Core component ignore emulator certificate #2322
Comments
cc @JamesNK |
That setting is removed in #2008 Although I'm not sure if AddCosmosDbContext builds the right connection string to ignore the cert. |
@JamesNK it looks like it doesn't use the right connection string - I'm getting errors. |
That change is for preview 4. It isn't publicly released. Are you using preview 3 or a nightly build? |
Preview 3 - to allow easier checks for my technical reviewers And this is an exception I see with the emulator:
|
@christiannagel I am getting the same. The only workaround I have found is when setting up my DB context is to do as the documentation says as so:
Doing the above still gives me SSL errors, so in my Web project for my Aspire app I have had to:
Obviously this is not ideal, but for testing it does allow me to at least make a connection to the Cosmos Emulator. |
@JamesNK I missed updating one of the packages with this project. The @JamesLMiller - thanks for the workaround. I'm not changing the DbContext as I'm usingt a NuGet package that's also used with Cosmos running in Azure: https://www.nuget.org/packages/CNinnovation.Codebreaker.Cosmos/, but managed to use your workaround with the DI container configuration ignoring the Cosmos component in the debug case: #if DEBUG
builder.Services.AddDbContext<IGamesRepository, GamesCosmosContext>(options =>
{
options.UseCosmos("AccountEndpoint = https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==", "codebreaker",
cosmosOptions => {
cosmosOptions.HttpClientFactory(() => new HttpClient(new HttpClientHandler()
{
ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
}));
cosmosOptions.ConnectionMode(ConnectionMode.Gateway);
});
});
#else
builder.AddCosmosDbContext<GamesCosmosContext>("codebreaker", "codebreaker",
configureDbContextOptions: static options =>
{
options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
});
builder.Services.AddScoped<IGamesRepository, DataContextProxy<GamesCosmosContext>>();
#endif Looking forward to updating this with preview 4. |
I was using preview 3 and I had the same issue - but I tested the latest code from Also, seems the package used by preview 3 have the issue Azure/azure-cosmos-dotnet-v3#4315. Now their latest non-preview release (which contains the fix) is the same one already being used by Aspire. Just posting it here for correlation, since the issue experimented by you @christiannagel may be related to that, although already fixed by Aspire. |
I'm going to close this as fixed with preview4. If the problem still exists in the preview4 builds, please re-open. |
One thing that I noted in some of my testing for my app, is that if I give the emulator time to fully start up (sometimes almost a whole minute) I will not get the SSL errors when connecting. If I don't give it time to connect, and try to use the my database context to call "EnsureCreated" I will still get the SSL issues. |
I see similar problems with the cosmos emulator |
@davidfowl are you seeing this on the main branch? |
@christiannagel for preview 3 you will need to set the ignore flag for the certificate. But you still may see SSL errors. This is due to the time it takes for the emulator to start up. Even if the emulator output is saying it has started all the partitions it can still take some time for it to become responsive to some requests. Try letting it run for about 40-60 seconds and see whether it starts being responsive. Could you let us know either way on this? |
... if you are using preview 4 bits from |
Reopening for now since this is still an active conversation and we just need to verify that it is actually working (if we wait long enough). |
I've also seen SSL errors when the emulator is starting up. However, the problem isn't caused by an invalid certificate. It's caused by the emulator returning a bad response as it starts. Ignoring invalid certificate won't fix it. |
When waiting I do not get SSL errors. The other issue that I am noting is that I have no way (that I know of) beyond a GET request to check the status of the emulator. This seems like overkill. With Aspire, I would assume the startup and connection would be handled when adding these components by my AppHost, and I just "use" them. I can write retry logic if I have health status information about the emulator, to wait for startup to complete, but I don't see anything in the docs about that. It is a little cumbersome to have to wait for 60 (sometimes more) seconds, to do local testing on cosmos changes. Its a first world problem I know, but just making a note of it. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
When using
AddAzureCosmosDB
the emulator certificate can be ignored as implemented with #1668I try to use the EF Core version
AddCosmosDbContext
. With this it looks like this option to ignore the emulator certificate is not available.The text was updated successfully, but these errors were encountered: