This had occurred in a solution we upgraded from rc.3 to the final release build. When we created a new project, the issue is not there. We have tracked down and resolved the issue in our existing project. Thanks!
I would be Ok with an option to enable/disable AuditLogActionInfo entirely. I have yet to find a use-case where we use the data in this table. So far, the AuditLogInfo and Entity*ChangeInfo tables have provided all the data we need.
This is not the answer to the question I asked. The logging I am asking about is in the AbpAuditLogActions table, it is not the entity logs.
According to your documentation https://docs.abp.io/en/abp/latest/Audit-Logging, the audit logging should be turned off for Get requests by default. I enable it using the property IsEnabledForGetRequests if I want to turn it on. I have not set that property, yet I am seeing audit log records for Get requests in the AbpAuditLogActions table.
I would agree except that I undid all my changes and ran this multiple times and it was the same on all attempts. That does not make sense that a network related issue would occur in the same place on each attempt.
After upgrading the CLI to rc.3, I get this error during the update command for the project.
[08:29:25 WRN] 1. HTTP request attempt failed to https://api.nuget.org/v3-flatcontainer/volo.abp.aspnetcore.mvc.ui.theme.leptonx/index.json with an error: 404-Not Found. Waiting 2 secs for the next try... [08:29:27 WRN] 2. HTTP request attempt failed to https://api.nuget.org/v3-flatcontainer/volo.abp.aspnetcore.mvc.ui.theme.leptonx/index.json with an error: 404-Not Found. Waiting 4 secs for the next try... [08:29:31 WRN] 3. HTTP request attempt failed to https://api.nuget.org/v3-flatcontainer/volo.abp.aspnetcore.mvc.ui.theme.leptonx/index.json with an error: 404-Not Found. Waiting 7 secs for the next try... [08:29:39 INF] Updating package "Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX" from v1.0.0-rc.3 to v1.0.0-rc.4.
It looks like the fourth attempt was different in some way and worked. But the first 3 attempts for this package failed.
I was able to resolve the issue for Azure App Service with the following code:
Added to PreConfigureServices in *HttpApiHostModule
#if RELEASE
PreConfigure<AbpOpenIddictAspNetCoreOptions>(options => options.AddDevelopmentEncryptionAndSigningCertificate = false);
string encryptionThumbprint = "******************";
string signingThumbprint = "**************";
var encryptionCertificate = GetX509Certificate2(encryptionThumbprint);
var signingCertificate = GetX509Certificate2(signingThumbprint);
PreConfigure<OpenIddictServerBuilder>(builder =>
{
builder.AddEncryptionCertificate(encryptionCertificate);
builder.AddSigningCertificate(signingCertificate);
});
#endif
helper method referenced above
private X509Certificate2 GetX509Certificate2(string thumbprint)
{
bool validOnly = false;
using var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
var collection = store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, validOnly);
var certificate = collection.OfType<X509Certificate2>().FirstOrDefault();
store.Close();
return certificate ?? throw new Exception($"Cannot find certificate with thumbprint {thumbprint}");
}
The self-signed certificates were generated based on the documentation available on https://documentation.openiddict.com/configuration/encryption-and-signing-credentials.html.
The certificates must be generated with a password instead of the empty password in the example in order for you to upload the PFX file to the Azure App Service.
You must also set the configuration setting for WEBSITE_LOAD_CERTIFICATES on the Azure App Service to either be * to load all certificates or have a comma separated list of certificates you want loaded.
I found this in the OpenIddict documentation. https://documentation.openiddict.com/configuration/encryption-and-signing-credentials.html. This should be included in the deployment documentation for the new version and referenced in the release notes.
@liangshiwei I am not following your answer. The default code provided in the template application exhibited the problem described above in my initial post. Are you saying that the initial application has a problem or the changes I highlighted are a problem. Please note, it was not working until I made the changes I highlighted. It is working as expected after those changes.
As a follow up, I made a couple of changes to the Swagger application configuration and it now works. I am not sure why this change removed the windows authentication prompt, but the result now matches the user experience we had with identity server.
I changed the client type to confidential and added a configuration variable to set the secret. With this in place, things now work just like they did in 5.x for me.