- Home
- Skills
- Diverta
- Kuroco Skills
- Frontend Integration
frontend-integration_skill
1
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill diverta/kuroco-skills --skill frontend-integration- metadata.json104 B
- SKILL.md9.3 KB
Overview
This skill describes integration patterns for connecting Kuroco Headless CMS with front-end frameworks like Nuxt (Nuxt2/Nuxt3) and Next.js (Pages/App Router). It covers environment setup, CORS and cookie authentication requirements, common composables/lib helpers, and practical patterns for SSG/SSR, routing, and authentication flows. The guidance focuses on secure cookie-based auth, static generation tips, and safe rendering of CMS HTML content.
How this skill works
The skill inspects common integration needs: API base configuration, CORS and cookie settings, and client helpers to call Kuroco APIs with credentials included. It shows standard composable/lib examples for fetching data (useKurocoApi, apiGet), auth flows (login, logout, checkAuth, signup), and framework-specific patterns for Nuxt and Next.js SSG/SSR. It also highlights deployment considerations for KurocoPages and security practices like HTML sanitization and same-site domain setup.
When to use it
- When building a Nuxt 3 or Nuxt 2 frontend that consumes Kuroco content or member APIs.
- When integrating Next.js (App Router or Pages Router) with Kuroco for SSR or SSG pages.
- When implementing member auth (login, logout, signup) with cookie-based authentication.
- When preparing SSG/SSR strategies and deciding where to call Kuroco APIs (build vs runtime).
- When deploying frontends to KurocoPages or hosting where rewrite settings are needed.
Best practices
- Enable cookie auth in Kuroco and set frontend and API on sibling subdomains to avoid third-party cookie issues.
- Set CORS_ALLOW_CREDENTIALS to true and allow only trusted origins and methods in CORS settings.
- Use credentials: 'include' for member endpoints and server-side fetching (no-store for privacy when needed).
- Sanitize CMS HTML with a library like DOMPurify before using v-html or dangerouslySetInnerHTML.
- Choose SSG for marketing pages and SSR or runtime fetches for personalized/member pages to ensure auth state accuracy.
Example use cases
- Nuxt 3 site: use a composable (useKurocoApi) with $fetch and credentials to render news list and dynamic [slug] pages with SSG.
- Next.js App Router: create lib/api.ts that calls Kuroco with credentials and use server components or no-store fetches for profile pages.
- Member flows: implement login/logout/signup endpoints that call Kuroco APIs and persist session via cookies for subsequent profile checks.
- SSG + authenticated pages: generate static public pages at build time and fetch member-specific data client-side after checkAuth.
- KurocoPages deployment: add rewrite config and connect GitHub repo to host SPA assets while proxying API calls to the Kuroco API domain.
FAQ
Host the frontend and API under the same parent domain (e.g., www.example.com and api.example.com) and enable cookie auth to avoid third-party cookie blocking.
Should I use SSG or SSR for member-only pages?
Use SSR or client-side runtime fetches for member-only pages to ensure correct auth-dependent content; reserve SSG for public content that doesn't change per user.