Activities of "maliming"

Great

Hi,

The symptom you described (landing page clean, dashboard/other pages show the footer, then landing also shows after) means the Server has the token but the WASM doesn't.

You added the token to appsettings.secrets.json in the .Blazor project. That file only exists on the server file system:

• Server prerender of the landing page: configuration["BlazoriseProductToken"] returns the real token → no footer.
• WASM client (when a page goes interactive, or you navigate to Dashboard / admin pages): the same lookup returns null because the browser cannot read your server's secrets file → Blazorise treats it as unlicensed → footer.

Fix in the .Blazor.Client project — pick one:

Option 1: hard-code in the WASM module (simpler)

In MethodInsight.Blazor.Client/MethodInsightBlazorClientModule.cs:

private void ConfigureBlazorise(ServiceConfigurationContext context)
{
    context.Services
        .AddBlazorise(options =>
        {
            options.ProductToken = "your-product-token-here";
        })
        .AddBootstrap5Providers()
        .AddFontAwesomeIcons();
}

Option 2: add to the WASM project's wwwroot appsettings

Create/edit MethodInsight.Blazor.Client/wwwroot/appsettings.json:

{
  "BlazoriseProductToken": "your-product-token-here"
}

Blazor WASM loads this file via HttpClient at startup into IConfiguration, so your existing configuration["BlazoriseProductToken"] lookup will work without code changes.

Note: the WASM token has to live in the client-side bundle / static assets either way — Blazorise verifies the license inside the browser. Both options expose the token equally; Option 1 just has less ceremony.

After the change, clean bin/ and obj/ in .Blazor.Client, rebuild, hard-reload the browser.

Thanks

hi

Have you changed the license key to Product Token in both the server and wasm projects?

Please share your Product Token to liming.ma@volosoft.com

Thanks.

hi

We’ll look into this issue. Thanks for your feedback.

Hi,

That's the second layer of the Switch Tenant flow. Your log line is the giveaway:

[ERR] Invalid RedirectUrl: https://localhost:44337/Account/Challenge, Use AppUrlProvider to configure it!

After SwitchTenantLogin.OnPostAsync signs the user into the new tenant, it calls RedirectSafelyAsync(ReturnUrl, ...), which only allows return URLs whose origin is in AppUrlOptions.RedirectAllowedUrls. Your Blazor host https://localhost:44337 isn't in that list on the AuthServer side, so the redirect falls back to ~/ — the AuthServer home page, which is what you're seeing.

The template wires the list from App:RedirectAllowedUrls in appsettings.json:

// TestApp.AuthServer/<AuthServerModule>.cs
Configure<AppUrlOptions>(options =>
{
    options.Applications["MVC"].RootUrl = configuration["App:SelfUrl"];
    options.RedirectAllowedUrls.AddRange(
        configuration["App:RedirectAllowedUrls"]?.Split(',') ?? Array.Empty<string>());
});

Fix

In your AuthServer project's appsettings.json, add your Blazor host URL to App:RedirectAllowedUrls:

{
  "App": {
    "SelfUrl": "https://localhost:44335",
    "RedirectAllowedUrls": "https://localhost:44337,...your existing entries..."
  }
}

Then restart the AuthServer. After the switch completes, the AuthServer will redirect back to https://localhost:44337/Account/Challenge and re-establish the Blazor session under the new tenant.

While you're there, make sure the same Blazor URL is also in App:CorsOrigins (usually already added by the template). If you have other UI hosts pointing at this AuthServer, add their origins too — the check uses StartsWith, so a single entry like https://localhost:44337 covers any path under that origin.

Thanks

: )

I will update the faq text.

Thanks.

hi

You should use the Product Token instead of License key

Thanks

Hi,

Two separate issues — let me address each.

Issue 1: Switch Tenant returns 405

The SwitchTenant modal in the Blazor Server / WebApp project posts to a relative path /Account/SwitchTenantLogin, which means the form is submitted to the Blazor host itself (port 44337 in your case). But the SwitchTenantLogin Razor Page is only registered on the AuthServer (the Volo.Abp.Account.Pro.Public.Web module), so the Blazor host has no handler and returns 405.

The Blazor SwitchTenantModal already supports an absolute URL — it just needs AbpAccountSwitchTenantOptions.LoginUrl to be configured. The default app template doesn't wire this up (it does wire AbpAccountLinkUserOptions.LoginUrl right above, which is why Link Account works but Switch Tenant doesn't).

Add this in your *BlazorModule.cs (or *BlazorServerModule.cs) ConfigureServices, next to the existing AbpAccountLinkUserOptions block:

using Volo.Abp.Account.SwitchTenant;

Configure<AbpAccountSwitchTenantOptions>(options =>
{
    options.LoginUrl = configuration["AuthServer:Authority"];
});

Make sure your OIDC config has options.SaveTokens = true (the default template already has it), otherwise the access_token can't be attached to the form action.

We'll fix the template to include this by default.

Issue 2: Seeding default users to every new tenant under Shared Accounts

The old approach (IDataSeedContributor seeds an admin/support/ops user into every new tenant) doesn't translate to Shared mode, and not just mechanically — it's incompatible with the design.

Under Shared mode, an email/username pair identifies one person for the whole system. That person can belong to many tenants, but two different people can't share an email. In AbpUsers they show up as a host root row (TenantId = null) plus one tenant-shadow row per tenant they belong to — all those rows are the same identity. There's no such thing as "tenant A's support user" and "tenant B's support user" as two separate accounts; there is one support@yourcompany.com person, and tenants either have an association with that person or they don't.

That's the reason SaaS removed the auto-create-admin behavior. TenantAppService.CreateAsync now publishes InviteUserToTenantRequestedEto { DirectlyAddToTenant = false }, which emails the admin and waits for them to opt in. Joining a tenant is the user's choice, not the system's. The invitation record is the audit trail of that choice.

So the right pattern in Shared mode is:

1. Create the support@yourcompany.com / ops@yourcompany.com users once in the host (a host-only IDataSeedContributor that calls IdentityUserManager.CreateAsync(...) with TenantId = null is fine, or let them self-register). This produces the single host root per identity that the model expects.
2. Each tenant gets these users via the normal invitation flow — either you (the host admin) invite them from the SaaS host page after creating the tenant, or your operations workflow does it. The user accepts the invitation, and the tenant-shadow record gets created.

If you bulk-create tenants and find clicking Invite for each one tedious, the realistic answer is to script the host-side action — call SaaS's InviteUserAsync (or publish InviteUserToTenantRequestedEto) right after your tenant-creation script for each default email. The user still opts in via the email; you've just automated the host-side invitation send, not the user's consent.

I don't recommend writing a TenantCreatedEto handler that programmatically auto-accepts invitations on behalf of these users. The primitives to do it exist (UserInvitationManager.CreateAsync + UserSharingManager.AcceptInviteAsync is what UserSharingManager.AddPendingUserToTenantAsync uses internally for the DirectlyAddToTenant = true self-registration path), but applying them to a fixed default-user list means you're forging consent for every new tenant — which defeats the user-sovereignty guarantee the invitation flow was added to provide, and leaves no audit story when one of those users later changes role or leaves.

I verified Issue 1 end-to-end on a fresh tiered Blazor Server template (ABP 10.3.0, Shared mode): the 405 disappears after wiring AbpAccountSwitchTenantOptions.LoginUrl.

Thanks

ok, I will check it. Thanks.

Hi,

To save you the time of preparing a full demo project, could you instead email us your Blazorise product token directly? We'll plug it into a fresh Blazor Web App + Tiered solution on our side and see if the footer still shows up there. That should quickly tell us whether the issue is with the token itself or with something specific to your project setup.

Please send it to: liming.ma@volosoft.com

If there is any problem, we will contact Blazorise technical support directly.

Thanks