Skip to content

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

Closed
christiannagel opened this issue Feb 20, 2024 · 17 comments
Closed

Cosmos EF Core component ignore emulator certificate #2322

christiannagel opened this issue Feb 20, 2024 · 17 comments
Assignees
Labels
area-integrations Issues pertaining to Aspire Integrations packages

Comments

@christiannagel
Copy link

When using AddAzureCosmosDB the emulator certificate can be ignored as implemented with #1668

I try to use the EF Core version AddCosmosDbContext. With this it looks like this option to ignore the emulator certificate is not available.

@davidfowl
Copy link
Member

cc @JamesNK

@JamesNK
Copy link
Member

JamesNK commented Feb 21, 2024

That setting is removed in #2008

Although I'm not sure if AddCosmosDbContext builds the right connection string to ignore the cert.

@christiannagel
Copy link
Author

@JamesNK it looks like it doesn't use the right connection string - I'm getting errors.

@JamesNK
Copy link
Member

JamesNK commented Feb 21, 2024

That change is for preview 4. It isn't publicly released.

Are you using preview 3 or a nightly build?

@christiannagel
Copy link
Author

christiannagel commented Feb 21, 2024

Preview 3 - to allow easier checks for my technical reviewers

And this is an exception I see with the emulator:

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
       ---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
         at System.Net.Security.SslStream.ReceiveHandshakeFrameAsync[TIOAdapter](CancellationToken cancellationToken)
         at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
         at System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean isAsync, CancellationToken cancellationToken)
         at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
         --- End of inner exception stack trace ---

@JamesLMiller
Copy link

@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:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseCosmos("AccountEndpoint = https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==", "cosmos",
        x => {
            x.HttpClientFactory(() => new HttpClient(new HttpClientHandler()
            {
                ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
            }));
            x.ConnectionMode(Microsoft.Azure.Cosmos.ConnectionMode.Gateway);
        });
}

Doing the above still gives me SSL errors, so in my Web project for my Aspire app I have had to:


ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

Obviously this is not ideal, but for testing it does allow me to at least make a connection to the Cosmos Emulator.

@christiannagel
Copy link
Author

@JamesNK I missed updating one of the packages with this project. The IgnoreEmulatorCertificate option indeed is available with preview 3. However, it still throws with the same error.

@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.

@allantargino
Copy link

I was using preview 3 and I had the same issue - but I tested the latest code from main using the playground and I didn't have any problems.

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.

@eerhardt
Copy link
Member

I'm going to close this as fixed with preview4. If the problem still exists in the preview4 builds, please re-open.

@JamesLMiller
Copy link

@JamesNK I missed updating one of the packages with this project. The IgnoreEmulatorCertificate option indeed is available with preview 3. However, it still throws with the same error.

@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.

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.

@davidfowl
Copy link
Member

I see similar problems with the cosmos emulator

@mitchdenny
Copy link
Member

@davidfowl are you seeing this on the main branch?

@mitchdenny
Copy link
Member

@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?

@mitchdenny
Copy link
Member

... if you are using preview 4 bits from main you don't need to set the ignore flag because the updated Cosmos client honours a setting on the connection string.

@mitchdenny mitchdenny reopened this Feb 26, 2024
@mitchdenny mitchdenny added this to the preview 4 (Mar) milestone Feb 26, 2024
@mitchdenny mitchdenny self-assigned this Feb 26, 2024
@mitchdenny
Copy link
Member

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).

@JamesNK
Copy link
Member

JamesNK commented Feb 27, 2024

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.

@JamesLMiller
Copy link

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.

@dotnet dotnet locked and limited conversation to collaborators Feb 29, 2024
@davidfowl davidfowl converted this issue into discussion #2535 Feb 29, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
area-integrations Issues pertaining to Aspire Integrations packages
Projects
None yet
Development

No branches or pull requests

7 participants