our packages-lock.json did contain something wrong when it was generated before commercial packages were available. No we got those packages and performance problem is gone. Thank you.
Still no commercial packages. Am I missing something or are they still not yet available.
I noticed that 8.1.2 is published. Should there be commercial nuget packages already available because for some reason nuget install fails?
We cannot git revert to 8.0 because your tool not support to update to spesific version. We decide to put update task on hold untill you release new version. We don't know how to fix that 8.0.5 login page problem so we wait.
I have several different commits. And I updated straight away from 7.4 to 8.1 with that abp update command because I cannot spesify version as you know. So I don't know how 8.0 and 8.1 versions of AuthServer are different.
DependencyResolutionException: None of the constructors found on type 'Volo.Abp.Account.Public.Web.ExternalProviders.AccountExternalProviderOptionsManager`1[Microsoft.AspNetCore.Authentication.Google.GoogleOptions]' can be invoked with the available services and parameters:
Cannot resolve parameter 'Volo.Abp.Account.ExternalProviders.IAccountExternalProviderAppService accountExternalProviderAppService' of constructor 'Void .ctor(Microsoft.Extensions.Options.IOptionsFactory`1[Microsoft.AspNetCore.Authentication.Google.GoogleOptions], Volo.Abp.Account.ExternalProviders.IAccountExternalProviderAppService, Volo.Abp.Security.Encryption.IStringEncryptionService, Volo.Abp.MultiTenancy.ITenantConfigurationProvider, System.Collections.Generic.IEnumerable`1[Volo.Abp.Account.Public.Web.ExternalProviders.IPostConfigureAccountExternalProviderOptions`1[Microsoft.AspNetCore.Authentication.Google.GoogleOptions]])'.
Stack trace:
See https://autofac.rtfd.io/help/no-constructors-bindable for more info.
at Autofac.Core.Activators.Reflection.ReflectionActivator.<>c__DisplayClass14_0.<UseSingleConstructorActivation>b__0(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Middleware.DelegateMiddleware.Execute(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Pipeline.ResolvePipelineBuilder.<>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext context)
at Autofac.Core.Resolving.Middleware.DisposalTrackingMiddleware.Execute(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Pipeline.ResolvePipelineBuilder.<>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext context)
at Autofac.Builder.RegistrationBuilder`3.<>c__DisplayClass41_0.<PropertiesAutowired>b__0(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Middleware.DelegateMiddleware.Execute(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Pipeline.ResolvePipelineBuilder.<>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext context)
at Autofac.Builder.RegistrationBuilder`3.<>c__DisplayClass39_0.<OnActivated>b__0(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Middleware.CoreEventMiddleware.Execute(ResolveRequestContext context, Action`1 next)
at Autofac.Core.Resolving.Pipeline.ResolvePipelineBuilder.<>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext context)
at Autofac.Core.Resolving.Middleware.ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action`1 next)
I was upgrading our project from 7.4 to 8.1.0 but after we notice that there were severe EF performance problem I tried to update to 8.1.1 but still performance problem. After that I tried to downgrade to 8.0.5 but then I got this error message. 8.0.5 downgrade fixed our performance problem but login page is not working. If you don't have any problem with 8.0.5 then is there any other options than to start update process all over again from 7.4 to 8.0 or wait until 8.1.2 is published and hopefully performance problem is gone. I was thinking is there some changes in 8.1 AuthServer version which might not work with 8.0 version. I think abp update command change AuthServer code when I updated to 8.1 version.
Ok. Thanks anyway.
Is it OK to clean it away in our own code? https://scm-test.lw.app/? code=0m3Bw75YTPhX5MPp2lmcGhiU4igYl1YMRWDbD0QIEMA& state=dmxqdENEanJ1ZWFseU5sTGZjRXZpZklDYnQ5Ni5Cemg3dFBWcC1vN3Bja2V5& iss=https%3A%2F%2Fauth.scm-test.lw.app%2F
These are what AuthServer returns in callback call. Code and state are removed from url by your code or open iddicts but iss stays.
Is it normal/correct that after login there is iss url parameter like this: https://scm-test.lw.app/app/?iss=https:%2F%2Fauth.scm-test.lw.app%2F ?
Actually I forget that there was override for AuthServer:Authority parameter at Host App Service Configuration and it was https://app-scm-auth-test-qa-001.ase-sharedeawgeacbyumuk-qa-001.appserviceenvironment.net/ because that way communication goes directly to auth server inside Azure that why we cannot use public address(https://auth.scm-test.lw.app) because it is IP restricted. After I added that setIssuer to AuthServer code it started to work. At AuthServer AuthServer:Authority parameter value is https://auth.scm-test.lw.app/. So now it started to work. So there was no need for that Configure part. SetIssuer was all I needed.
builder.Configure(c =>
{
c.TokenValidationParameters.ValidIssuers = new List<string>()
{
configuration["AuthServer:Authority"]!,
"https://app-scm-auth-test-qa-001.ase-sharedeawgeacbyumuk-qa-001.appserviceenvironment.net/"
};
});
Thanks.