CMS Kit Pro + Multi‑Tenancy: public access per tenant (blogs, pages, newsletter) without login #10172

2 Answer(s)

• 

  0

  AI-Bot created yesterday

  Support Team ABP Agent

  1. Solution

  • Architecture to meet your requirements

    • Keep a single Public Website (MVC) application and make it multi-tenant aware. Serve tenant-specific CMS content by resolving the current tenant per request (no login required for viewing public content).
    • Use ABP’s tenant resolution to select the tenant by domain/subdomain or a route/query parameter:
      • Preferred: Map each tenant to its own domain or subdomain (e.g., tenant1.example.com, tenant2.example.com). This lets the same public site serve different content based on the resolved tenant.
      • Alternative: Use query string or a path segment for tenant resolution in development or if domains are not available.
    • CMS Kit Pro data is tenant-isolated (standard ABP multi-tenancy). Each tenant manages its own Pages, Blogs, Menus, etc., and the public endpoints read from the current tenant’s database/context.

  • Steps

    1. Enable CMS Kit Pro and features
       • Ensure CMS Kit Pro is installed with the Public Website option and enable the features you need using Global Features in your Domain.Shared project:

  GlobalFeatureManager.Instance.Modules.CmsKit(cmsKit =>
         {
             cmsKit.EnableAll(); // or enable specific CmsKit features
         });
  
         GlobalFeatureManager.Instance.Modules.CmsKitPro(cmsKitPro =>
         {
             cmsKitPro.EnableAll(); // or enable specific Pro features like Newsletter, Contact Form, URL Forwarding, Poll, etc.
         });
  

   - Add EF Core migration and update the database after enabling features.
  

  2. Configure tenant resolution for the Public Website

     • Configure domain/subdomain-based tenant resolution so that the current tenant is determined from host name. In your Web module, configure AbpAspNetCoreMultiTenancyOptions by adding a domain tenant mapping or by enabling the built-in DomainTenantResolveContributor. For subdomains, you typically deploy DNS and reverse proxy to forward subdomains to your public site; ABP will resolve the tenant from the host header.
     • Once configured, each request to tenant1.example.com resolves CurrentTenant = tenant1; tenant2.example.com resolves tenant2. No code changes are needed in CMS Kit controllers; they operate in the current tenant scope automatically.

  3. Anonymous/public access

     • CMS Kit’s public pages (dynamic pages under slug routes, blogs, etc.) are designed to be publicly viewable. The out-of-the-box Public Website application already exposes CMS content without requiring authentication.
     • For Newsletter (Pro), the subscribe endpoint is designed for public use. Keep it available to anonymous users so visitors can subscribe without logging in.
     • If you add any custom pages or controllers around CMS content, ensure they allow anonymous access:

  [AllowAnonymous]
         public class MyPublicController : AbpController
         {
             // read-only endpoints rendering tenant-specific content
         }
  

  4. One public site vs per-tenant sites

     • You do not need a separate web host per tenant. A single Public Website application can serve all tenants as long as tenant resolution is configured (recommended: subdomain per tenant). This is the common/recommended pattern.
     • If you have strict branding or runtime customization that is hard to toggle per request, a per-tenant host is possible but not required in most cases.

  5. Features per tenant

     • You can enable/disable CMS Kit features per Edition/Tenant using the Feature Management UI. That lets you offer, for example, Pages and Blogs to all tenants while enabling Newsletter only for specific editions.

  • Practical notes
    • Public Website + CMS Kit Pro is already multi-tenant-ready in ABP Commercial templates. Create the solution with “Public website” option. The CMS menu (admin side) appears in the main app (Admin UI). Tenants manage their own content there; public readers consume it on the Public Website domain.
    • For domain mapping beyond basic defaults, implement or configure a Tenant Resolve Contributor that maps hostnames to tenant names if your naming doesn’t match.

  2. Sources

  • CMS Kit Pro (overview and features)
    • https://abp.io/docs/commercial/8.1/modules/cms-kit
  • Multi-Tenancy (ABP)
    • https://abp.io/docs/2.1/Multi-Tenancy
  • ABP Multi-Tenancy (latest architecture overview)
    • https://abp.io/docs/latest/framework/architecture/multi-tenancy
  • CMS Kit Pro module docs (install/public website note)
    • https://abp.io/docs/latest/modules/cms-kit-pro/
  • CMS Kit intro and public website usage (community article)
    • https://abp.io/community/articles/tiwvceqd
  • ABP Samples – CMS Kit Demo (public site sample)
    • https://abp.io/docs/latest/samples/

  ---

  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.

  Save Cancel
• 

  0

  maliming created yesterday

  Support Team Fullstack Developer

  hi

  1.What is the recommended way to implement this scenario with CMS Kit Pro in a multi‑tenant application?

  You can create the new project with CMSkit options or add the CMSkit module to your current project.

  Then everything will work.

  2.Is there any built‑in feature or recommended pattern for exposing tenant‑specific CMS content (pages newsletter subscription, FAQ, etc.)

  You can manage CMSkit in the backend app and view it on the public website.

  Log in as the host and tenant admin user to manage different data.

  3.Publicly without requiring authentication?

  Some of the CMSkit components don't require authentication. Eg, FAQ Blog posts, but the comment will request an authenticated user.

  In short, the backend and public website with CMSkit built in can already achieve the functionality you mentioned. You can create one and give it a try.

  Thanks.

  Save Cancel