Activities of "rcalv002"

Hello. Your feedback please

Hello, your feedback please.

Hello, Negative, the issue is at the moment of generating migration it includes in the up code a table that was already in previous migration up code. The issue is not at the moment of applying migration as far as I can see.

Thanks for your response, any chance you could indicate where to add this code?

Here's the call to wellknown

No, azure only lets you configure redirect that are https:// in application we set env variable App:SelfUrl to https://

but it seems well-known endpoint might still be returning the http value and so microsoft says invalid redirect.

the system has been running for a long time behind proxy well, we are just now adding microsoft login.

Is the scenario clear now?

I have removed the dynamic section and can see it present. Attempting to login with the microsoft acc in the production deployment generates an invalid uri error, because the auth server returns http instead of https which is not allow. We had something similar in the past with identity server and implemented a workaround for it, here https://abp.io/support/questions/3706/Identity-server-production-deployment-with-angular. However this didnt work on iddict, We attempted to fix this with the following but it doesnt work: the value for app:selfurl is the https address in the docker container, the service is still behind nginx proxy so those configs have not changed.

public override void PreConfigureServices(ServiceConfigurationContext context)
{
    var hostingEnvironment = context.Services.GetHostingEnvironment();
    var configuration = context.Services.GetConfiguration();

    ...

    PreConfigure<OpenIddictBuilder>(builder =>
    {
        builder.AddValidation(options =>
        {
            options.AddAudiences("CloudTools");
            options.UseLocalServer();
            options.UseAspNetCore();
            options.SetIssuer(configuration["App:SelfUrl"]);
        });
    });

   ...
}

Sign in Sorry, but we’re having trouble signing you in.

AADSTS50011: The redirect URI 'http://mydomain.com/signin-microsoft' specified in the request does not match the redirect URIs configured for the application 'myappid'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

If we login with regular auth, and then go to settings -> external providers we can then enable a checkbox for microsoft and type in the id and secret again at which point it works. but it seems this should be automatic because its configured in code?

We don't want a user to login, as our addon will run for many users and all of the communication that addon initiates with the abp backend, should be for the same tenant (but not specific to the user). Our addon will be used by many tenants in the same environment, the tenant's configuration details would be saved in the db the addon connects to (separate from abp) and retrieved on addon startup to make api calls to abp backend using the dynamic proxy application services. Could you help us with a poc for this?

hi

Both Dynamic C# API Client Proxies and Static C# API Client Proxies can be used.

https://abp.io/support/questions/1727/How-to-build-winform-application-client-for-Dynamic-C-API-Client-Proxies

@mali, I think the question focuses most on the appropriate way to use the same and ensure the client is communicating with the correct tenant.

the service is one saas, and each customer will receive the client application, they will have to plug in some configuration values like the application id/ secret etc. And how to make sure their client only communicates with their tenant data?