From 62714ecc994a114efaad07fd6fc1c469735b8031 Mon Sep 17 00:00:00 2001 From: Shay Rojansky Date: Sat, 29 Jun 2024 11:32:46 +0200 Subject: [PATCH] Typo --- conceptual/Npgsql/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conceptual/Npgsql/security.md b/conceptual/Npgsql/security.md index cdd8276e..7277ecee 100644 --- a/conceptual/Npgsql/security.md +++ b/conceptual/Npgsql/security.md @@ -18,7 +18,7 @@ dataSourceBuilder.UsePasswordProvider( await using var dataSource = dataSourceBuilder.Build(); ``` -Every time a new physical connection needs to be opened to PostgreSQL, either the synchronous `passwordProvider` or the asynchronous `passwordProviderAsync` will be called (depending whether you used `Open()` or `OpenAsync()`). Since modern .NET applications are encouraged to always use synchronous I/O, it's good practice to simply throw in the synchronous password provider, as above. +Every time a new physical connection needs to be opened to PostgreSQL, either the synchronous `passwordProvider` or the asynchronous `passwordProviderAsync` will be called (depending whether you used `Open()` or `OpenAsync()`). Since modern .NET applications are encouraged to always use asynchronous I/O, it's good practice to simply throw in the synchronous password provider, as above. Note that since the password provider is invoked *every* time a physical connection is opened, it shouldn't take too long; typically, this would call into a cloud provider API (e.g. Azure Managed Identity), which itself implements a caching mechanism. However, if no such caching is done and the code could take a while, you can instead instruct Npgsql to cache the auth token for a given amount of time: