Version: ABP 9.2.0, using Angular UI and AuthServer.
What could be causing this problem?
4 Answer(s)
-
0
In ABP Angular UI, multi-tenancy is enforced by sending the selected tenant's ID as the __tenant header on each request. If users can log in without selecting a tenant and receive all permissions, it usually means the tenant resolution is not working as intended.
Common causes:
- The tenant resolver is not configured or is misconfigured on the AuthServer or API Host. This allows users to authenticate as the host (no tenant) and gain host-level permissions.
- The Angular UI is not sending the __tenant header, or the backend is not reading it.
- The login page or authentication flow does not require tenant selection, so users are authenticated as the host by default.
Solution steps:
- Ensure that the tenant resolver is properly configured in your AuthServer and API Host. For example:
Configure<AbpTenantResolveOptions>(options => { options.AddDomainTenantResolver("{0}.yourdomain.com"); options.AddHeaderTenantResolver(); options.AddCookieTenantResolver(); options.AddQueryStringTenantResolver(); });
- Verify that the Angular application is sending the __tenant header on all requests, especially during login.
- If you want to force tenant selection, remove or hide the "host" login option from the UI, and ensure the backend does not allow host logins for regular users.
- Review your permissions and roles to ensure host-level permissions are not granted to tenant users.
If you have custom login logic, make sure it resolves the tenant before authenticating the user.
Sources:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
hi
Can you explain it in more detail?
What is the username? password?
Maybe the host has the same user with the same password.
You can check it in the host user page.
Thanks.
-
0
I’m very sorry—I thought it was a serious issue, so I submitted the report immediately. However, our developer later explained that they manually modified the database user data, which caused the problem. We’ve now confirmed that it was due to human error and a data-related issue. I sincerely apologize for this.
-
0
ok, : )