Activities of "franciscosl"

[maliming] said: hi

Can you share the debug logs of 44393 website?

Thanks

If you wish, I can give you access to the source code where I am implementing it, so you can run the application yourself and see what happens. Please contact me by email, francisco.sierra@semicrol.com

Hi,

I have uploaded the log to the repository. You can find it here https://github.com/franciscosl-fnet/abp-app-domain-based/blob/main/Logs20251217.txt

I followed those steps and fixed the error. Ultimately, it was because one of the methods that configures the application was overridden in a module, which was our fault.

Now I am getting a different error when making the request: https://localhost:44393/connect/token

When I take it to the production application, I am getting an error in this call: https://{0}.localhost:44393/.well-known/openid-configuration

The ports are different because it is another solution. What could be the reason for this?

Thank you. I am currently migrating the code to my production application, so I haven't been able to test it yet.

Reviewing the Nuget dependencies that I add to my application, I see that the Nuget Owl.TokenWildcardIssuerValidator is added, which comes from your personal repository,

Shouldn't this code be inside the abp code?

Now it works, I can access the new tenant via URL, but when I do so, the website is marked as unsafe.

Now I need to transfer it to my production application. Could you explain how you solved it and how everything works so that I can understand what I need to do, rather than just copying and pasting?

Thank you very much!

I get the following error:

error:invalid_request error_description:The specified 'redirect_uri' is not valid for this client application. error_uri:https://documentation.openiddict.com/errors/ID2043 culture:es ui-culture:es

I tried with a new database, and I get the same error. In both cases, I ran dbmigrator.

[maliming] said: hi

Reproducible repository: 👉 https://github.com/franciscosl-fnet/abp-app-domain-based

Can you share the steps?

I will check it

Thanks.

Hi, sorry, I thought that the problem description already explained how to reproduce it.

1. Start the host (DbMigrator previously runned)
2. Start Blazor
3. Create a new tenant from the host
4. Log out
5. Use the URL format described in the ticket to access the newly created tenant (using the local URLs)

Unfortunately, the proposed solution does not work for us. We have tested it both in our application and in a clean ABP application, and the behavior is the same.

To make this reproducible, I created a clean ABP 9.1.3 solution (Blazor Interactive – WebAssembly only) and applied the suggested changes.

Reproducible repository: 👉 https://github.com/franciscosl-fnet/abp-app-domain-based

In this sample:

• The tenant name is correctly extracted from the subdomain.
• However, the tenant context is not applied correctly, and the application does not work as expected.
• Same behavior in our real project and in this clean sample.

This suggests the issue is not project-specific. Any guidance after reviewing the repo would be appreciated.

Description

Hello ABP Team,

We are trying to implement tenant resolution by subdomain following the official ABP documentation, but the described approach does not work as expected, even in a clean ABP solution created from the templates.

We have followed the documentation step by step, specifically the section:

https://abp.io/docs/latest/framework/architecture/multi-tenancy#domainsubdomain-tenant-resolver

However, the tenant is not resolved correctly from the subdomain, and the application does not behave as expected.

Environment

• ABP Framework: 9.1.3

• UI: Blazor Interactive (WebAssembly only)

• Multi-tenancy: enabled

• Reproduced both in:

  • Existing project
  • Clean ABP solution generated from scratch

URL structure / scenario

Our application is deployed with environment-based subdomains:

• QA: https://app-qa.example.com
• Preproduction: https://app-pre.example.com
• Production: https://app.example.com

Expected tenant URLs would be, for example:

• https://tenant1.app-qa.example.com
• https://tenant2.app-pre.example.com
• https://tenant3.app.example.com

The base subdomain (app, app-qa, app-pre) represents the application, not a tenant.

What we have tried

1. Built-in Domain/Subdomain Tenant Resolver

• Configured exactly as described in the documentation.
• The tenant is not resolved, or the resolver is not triggered as expected.

2. Custom Tenant Resolver

• Implemented a custom ITenantResolveContributor to handle our URL logic.
• The resolver correctly extracts the tenant name from the URL/subdomain.
• The extracted tenant value is available inside the resolver.

However:

• Even though the tenant name is extracted correctly, the application does not work properly.
• The tenant context does not seem to be applied correctly across the request lifecycle.
• Authentication, login, and general request handling break or behave inconsistently.

This suggests the issue is not only related to parsing the URL, but to how the resolved tenant is applied internally by ABP, possibly in a Blazor Interactive WebAssembly scenario.

Expected behavior

• The tenant should be resolved automatically from the subdomain.
• The resolved tenant should be applied correctly to the request context.
• The application should work normally once the tenant is resolved.
• The login process should be able to use the resolved tenant.

Actual behavior

• Built-in resolver does not work as documented.
• Custom resolver extracts the tenant correctly, but the application does not function correctly.
• Same behavior in a clean ABP 9.1.3 Blazor Interactive WebAssembly solution.

Questions

1. Is the Domain/Subdomain Tenant Resolver fully supported in ABP 9.1.3 with Blazor Interactive (WebAssembly only)?

2. Is there any additional configuration, middleware order, or Blazor-specific requirement missing from the documentation?

3. Are there known limitations or issues when:

   • Using environment-based subdomains
   • Using Blazor Interactive WebAssembly

4. Is there a recommended or official approach for resolving tenants by subdomain in this setup?

Any clarification, guidance, or updated example would be greatly appreciated.

Thank you in advance.