Activities of "gterdem"

Well, it is not ASPNET_ENVIRONMENT, it is the DOTNET_ENVIRONMENT. If you are trying to debug in Development environment, you need to override the AbpLicenseCode key with your license key value.

You can also pass AbpLicenseCode dotnet environment with your license. Although you shouldn't have license error on production environment. Just before the license error, application should be logging the environment. Can you double check that aswell?

Try using FROM mcr.microsoft.com/dotnet/aspnet:7.0 for your DbMigrator Dockerfile if you are using slim version or any other.

Hi,

The lastest I see is you get IDX20803: Unable to obtain configuration from .. which seems related to Swagger login. We have made enhancements and fixed on version 7.4. Which version of is your application?

What is your request to which server? What error do you receive exactly?

When deploying on K8s, you may get errors related to Issuer validation. The swagger client uses browser to redirect to authserver (that uses the real DNS) to start the signin process and uses the internal k8s service name to validate the token. This may cause HttpApi.Host application errors related to ValidIssuer.

You can add the k8s service as issuer aswell to prevent this problem by updating the JWT authentication:

context.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
    options.Authority = configuration["AuthServer:Authority"];
    options.RequireHttpsMetadata = Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]);
    options.Audience = "MyAbpApp";
    options.TokenValidationParameters = new TokenValidationParameters()
    {
        ValidIssuers = new []{"https://myauthserver.com","http://authserver-k8s-service-name"} // -> This line
    };
});

I have removed your link. Please don't share the commercial templates in public repositories. Set your repository to private and add @maliming as collaborator.

The login process does not use the gateway. AuthServer directly uses the IdentityService database to check the credentials for client authentication and the user authentication afterwards.

Since this is a custom solution, I'll try to check it remotely.

You can check the docs at https://docs.abp.io/en/commercial/latest/startup-templates/microservice/applications#public-application-landing-page

You can create new microservice template and examine the public-web application. AuthServer configuration details are in the docs.

Galip, biz problemimizi hallettik. Projede 'AbpPaymentStripeHttpApiModule' modulunu kullanıyorduk. 7.3.2 upgrade sonrası paketler restore olmadı. 'AbpPaymentStripeHttpApiModule' modulunu projeden kaldırdık. Restore oldu. Bu modüle bakmalısınız.

I had to dig to find the problem, yes it is related to Payment Module. The related changes are documented here: https://docs.abp.io/en/commercial/latest/migration-guides/v5_2#payment-module
Saas and Payment modules are no longer coupled. But if you want to use it together please check this docs aswell: https://docs.abp.io/en/commercial/latest/migration-guides/v5_3#saas-payment-module-dependency-improvements

TLDR: Remove the Volo.Payment.Stripe.HttpApi dependency and make the related configuration to use with SaasModule:

Configure<AbpSaasPaymentOptions>(options =>  
{  
    options.IsPaymentSupported = true;  
});  

haklısın. bizim hatamız. teşekkürler.

Hayır lütfen hata falan yok :) Bir çok kişi aynı sorunu yaşıyor ve gözden kaçıyorsa biz daha dikkat çekici yazmalıyız migration dokümanını.

@Sergei, If your problem is resolved you can close the issue. Let me know if the problem persists.

There is no sample about it but we are working on it.

For specifically between v5 and v7, no you can't use it. Module will be targeting .net5 etc while running application is targeting .net7.

And it is not related to ABP. As an example from a nuget package, here is the Automapper v8.0.0 depends on .NetStandart 2.0 while version 12.0.0 depends on .NetStandart 2.1.