Run any Skill in Manus with one click

blocks-frontend-local-https

Stars0

Forks3

UpdatedJuly 14, 2026 at 19:06

Run a frontend React app locally over HTTPS on its real project domain, using a locally-generated SSL certificate — required so SELISE Blocks SSO/OIDC login works, because the auth callback sets a Secure, domain-scoped session cookie that the browser rejects on plain http://localhost. The skill: discovers the project's domain from /os/v4/Project/Gets (projects[].applications[].domain, filtered by environment) or asks the user, adds a hosts entry mapping that domain to 127.0.0.1, generates a self-signed local cert for it with openssl (and trusts it), configures the dev server (Vite/CRA/Next) to serve https on that domain + port, and runs it at https://your.domain.com:PORT. Use whenever the user needs to run/test a Blocks app locally over HTTPS, fix 'SSO cookie not set / session lost on localhost', set up a local dev cert, serve a custom domain locally, or make the OIDC redirect work in local dev. A real/owned domain name is required to issue the cert — you cannot make one without a domain.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

SELISEdigitalplatforms

SELISEdigitalplatforms/blocks-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

4 files

SKILL.md

readonly

name

blocks-frontend-local-https

description

Blocks Frontend — Local HTTPS on the Project Domain

Blocks SSO/OIDC (blocks-iam-sso-oidc-implementation) finishes by having /iam/v4/idp/callback set a Secure, domain-scoped session cookie. Browsers refuse to store that cookie on http://localhost, and they scope it to the project's cookie domain — so to test login locally the app must run on HTTPS at the project's real domain, not localhost. This skill makes that work: generate a trusted local cert for the domain, point the domain at your machine, and serve the dev server over HTTPS on it.

Pure local tooling — the only Blocks API call is the optional Project/Gets lookup to discover the domain.

The domain is the crux

You need a domain name to issue the certificate against and to run on — localhost won't do, because the cookie is scoped to the project's domain. Resolve the domain before generating the cert, in this order (never guess one):

From Project/Gets first — response is an array of tenant-groups; each has a projects array. Pick the project (and environment — ask if more than one applies). The applicationDomain lives in projects[].applications[].domain (often https://dfsgso.slsblx.com), not on the project object directly. One application → use its domain; multiple → ask the user which to pick. Strip https:// for the hostname used in hosts/cert/dev-server.
Only if none is found, ask the user. It must match the OIDC redirectUri origin, or login still fails.

You are not taking the real domain over the internet — you map it to 127.0.0.1 in your hosts file, so https://myapp.seliseblocks.com:5173 resolves to your local dev server while every other machine still reaches the real site.

Steps → flows/setup-local-https.md

Determine the domain (Project/Gets or ask).
Add a hosts entry: 127.0.0.1 <domain>.
Generate a self-signed cert for <domain> with openssl, and trust it so the browser stops warning.
Configure the dev server to serve HTTPS on <domain>:<port> with that cert — references/vite-config.md.
Run → open https://<domain>:<port>.
Use that exact origin as the OIDC redirectUri everywhere.

Tool: openssl

Use openssl (preinstalled on macOS/Linux, and in Git Bash on Windows) to issue a self-signed certificate for the domain. It's self-signed, so the browser shows a one-time "not private" warning until you either click through it (fine for local dev) or trust the cert in the OS store to make the warning disappear — both covered in flows/setup-local-https.md step 3. Include the exact domain in the cert's subjectAltName, or the browser rejects it even over HTTPS.

Gotchas

Domain must match the cookie/redirect config. A cert for the wrong domain runs HTTPS fine but SSO still fails — the cookie won't be scoped to where you're browsing. Match cookieDomain / the registered redirectUri.
Point the API base URL at the same registrable domain, or the session cookie won't store. The same same-site rule that forces HTTPS-on-the-real-domain locally also governs which API host the app calls: the Blocks session cookie is only kept when API requests go to a host under the app's registrable domain. Default https://api.seliseblocks.com is right only for *.seliseblocks.com apps; on a custom domain set VITE_BLOCKS_API_URL=https://blocksapi.<your-registrable-domain> (app abc.slsblx.com → https://blocksapi.slsblx.com; app xyz.blx10.com → https://blocksapi.blx10.com). Ask the user which base URL to use. See blocks-iam-sso-oidc-implementation.
Hosts entry is required — without 127.0.0.1 <domain>, the browser resolves the real public IP instead of your dev server.
The domain must be in the cert's subjectAltName (SAN) — a matching CN alone isn't enough for modern browsers.
Port is part of the origin, not the cookie domain — https://myapp.seliseblocks.com:5173 shares the cookie domain myapp.seliseblocks.com, so Secure cookies set for that domain apply. Register the port-bearing origin as the redirectUri.
Certs are per-machine, never committed — add the cert directory to .gitignore.
Restart the browser after trusting the cert so the new trust is picked up.

More from this repository

same repository

blocks-onboarding

SELISEdigitalplatforms/blocks-skills

Onboard a user into SELISE Blocks before any other Blocks skill can run — detect their current state and get them to a working setup: no Blocks account yet (guide signup at https://os.seliseblocks.com), account but no project (ask what they want to build and create the project via API — suggest a dev-only default), project but no credentials file (have the user create the `.env`), or everything present (verify and hand off). Also covers adding more environments (test/stg/uat/prod/…) to an existing project and deleting environments, via API. Use whenever a user is new to Blocks, asks how to get started / sign up / create a project / add or remove an environment, or when a prerequisite fails in another skill — missing `.env` or `BLOCKS_USERNAME`, `auth-login` returns 401/invalid credentials, or `Project/Gets` returns no projects. Only SIGNUP is portal-only (browser, not API); project and environment management is scriptable. Run the preflight here whenever the user's account/project state is unknown.

2026-07-140

blocks-data-gateway-configuration

SELISEdigitalplatforms/blocks-skills

Configure the data model of a SELISE Blocks project through the data service REST admin API (`https://api.seliseblocks.com/data/v4`): create and edit schemas/collections, add or remove properties/fields, add field validation rules (incl. the AI regex assistant), set schema/field access levels and data-access policies, and RELOAD so changes go live in the runtime gateway. Also covers mock/sample data inventory + deletion and schema-exchange (export/import a data model between projects). Use whenever the user wants to define, edit, secure, validate, reload, copy, or reset the DATA MODEL of a Blocks project — 'add a field to my schema', 'make this collection public', 'validate the email field', 'reload the schema', 'clone my schemas to staging', 'wipe the demo data'. This is the admin/portal side; for running GraphQL create/read/update/delete against the resulting schemas use blocks-data-gateway-crud, and for file/DMS storage use blocks-data-storage.

2026-07-140

blocks-data-gateway-crud

SELISEdigitalplatforms/blocks-skills

Implement GraphQL create/read/update/delete against a SELISE Blocks project's runtime data gateway (`POST https://api.seliseblocks.com/data/v4/gateway`). Covers discovering a schema's auto-generated operation names, writing the query (`get<Collection>` with where/paging/order), insert/update/delete mutations (and insertMany/updateMany/deleteMany), the result + ActionResponse shapes, and wiring it all into a frontend (React 19 / TanStack Query hooks). Use whenever the user wants to READ or WRITE actual data/records through a Blocks schema from an app or script — 'fetch products from my Blocks collection', 'insert a record via the gateway', 'write the update mutation', 'CRUD hooks for my schema', 'why does getOrders not exist on Query'. The schema must already be created + reloaded via blocks-data-gateway-configuration; for file storage use blocks-data-storage.

2026-07-140

blocks-data-storage

SELISEdigitalplatforms/blocks-skills

Store and serve files on a SELISE Blocks project via the data service's DMS (document management system) — the `/data/v4/Files/*` API. Covers the pre-signed-URL upload (get upload URL → PUT the file binary to storage, with the Azure `x-ms-blob-type` header when needed → get download URL), downloading/listing files, folders (create/list/delete), tags/metadata/versions, and deleting files. Use whenever the user wants to upload, download, browse, organize, or delete FILES/attachments/documents/images on Blocks — 'upload a PDF and get a link', 'attach an image to a record', 'let users download this file', 'create a folder and list its contents', 'get a presigned upload URL'. This is separate from the data model: to define schemas use blocks-data-gateway-configuration, and to CRUD records use blocks-data-gateway-crud (store a file here, keep its fileId in a schema field there).

2026-07-140

blocks-iam-sso-oidc-configuration

SELISEdigitalplatforms/blocks-skills

Configure SSO / OIDC login for a SELISE Blocks project via the IAM admin API (`https://api.seliseblocks.com/iam/v4`): ensure a `blocks-oidc` identity provider exists, creating the OIDC client (`/oidc-clients`) and the identity provider (`/auth/identity-providers`) if they don't. Use whenever the user wants to SET UP / enable / configure single sign-on, OIDC, or an identity provider for their Blocks app — 'enable SSO for my project', 'configure OIDC login', 'register an OIDC client', 'add a blocks-oidc identity provider', 'set up authorization-code login on Blocks'. This is the admin/portal side and requires impersonating into the project first; once configured, wire the login into the app with blocks-iam-sso-oidc-implementation. If the app invites users via the portal or API, also wire an optional /activate page (blocks-iam-account) — not required for SSO login itself.

2026-07-140

blocks-iam-sso-oidc-implementation

SELISEdigitalplatforms/blocks-skills

Implement SELISE Blocks SSO / OIDC login in a frontend codebase — the authorization-code flow via `/iam/v4/idp/initiate` → redirect to `iam.seliseblocks.com` → `/iam/v4/idp/callback` (which sets the session cookie). Already-activated users log in through this flow directly. Optionally wire `/activate` (blocks-iam-account) only when the app invites inactive users via the portal or API who must activate before their first login. Also covers renewing the browser session via `POST /iam/v4/oidc/token`. Use whenever the user wants to ADD login/sign-in to a Blocks app, wire up SSO/OIDC on the client, build a login button, handle the OIDC redirect/callback, implement account activation for invited users, or keep the session alive after SSO. Do NOT implement username/password login directly — Blocks login goes through this hosted authorization-code flow. The project's OIDC provider must already be configured (blocks-iam-sso-oidc-configuration); this skill is the app-side wiring.

2026-07-140