Put a login wall
on any page
Decide which pages need an account, who gets through, and how people sign in. No separate membership app, no plugin, and no second login system to keep in sync.
Three access levels, and public is the default
Visibility becomes a property of the page. Every page starts public, and stays public until you change it — turning members on does not gate anything you did not gate yourself.
Public
defaultAnyone can read it. This is where every page starts, and where it stays unless you say otherwise.
Signed in
accountA member has to be signed in. Who they are does not matter yet — only that they are somebody.
In a group
restrictedOnly members of the groups you name. Everyone else sees the login wall instead of the content.
The check runs before the page does
Access is decided at the edge, in the same worker that serves your site, before the page is rendered. There is no database round-trip in the request path, so a gated page is as fast as a public one. The member's session is a signed token in a cookie; the worker verifies the signature against a rotating key set it keeps in cache.
// runs on the edge, before render
const token = cookies.get('spideriq_member_jwt');
const claims = await verify(token, jwks);
// { project_id, member_id, groups[] }
if (claims.project_id !== site.project_id)
return loginWall;
if (page.access === 'group' &&
!page.groups.some(g => claims.groups.includes(g)))
return loginWall;
return render(page);Four ways in, and none of them is another password to invent
Members can use an email and password, a magic link, or a one-time code sent to their inbox. Or you connect an identity provider and they sign in with an account they already have. The sign-in layer runs on Better Auth, an open-source authentication library.
Built in
no setupEmail and password, magic link, or a one-time code. Nothing to configure — these work the moment you turn members on.
Your provider
SSORegister an identity provider for your project and members sign in through it. Google is available at the platform level; OIDC and SAML providers are configured per project.
New members can be invite-only, which is the default, or provisioned automatically on first sign-in with a role and groups you choose in advance.
A group can be a list, or a rule
Groups are how you say which members get through. A group can be a fixed list of people you maintain, or a condition that decides membership when the check runs — so access follows what is true about someone rather than a list somebody has to remember to update.
A named list
manualYou add and remove people yourself. Good for a small cohort, a client, or a launch group.
A rule
dynamicMembership is evaluated from what is true about the member, so the group keeps itself current.
Restrict the posts a page can read, not just the page
Gating a page is not enough on its own — a component on a public page can still fetch content you meant to keep back. Data restrictions close that gap for your blog posts: you write a rule that says a group may see posts carrying certain tags, and the rule is applied when the page fetches them.
The rule is deny by default. Once posts have any restriction, nothing is visible except what a rule allows, and a member sees the union of what all their groups allow.
group "members"
source "posts"
field "tag"
allow ["members-only", "archive"]
// a visitor with no group sees neither tag
// a member in two groups sees the union of bothThis is version one and it is deliberately narrow: it filters posts by tag. It is not a general record-level filter across every kind of content yet.
Your members are yours
A member of your site is stored separately from the people who log in to SpiderPublish™ to build it. Signing up as a member of your site never creates a dashboard account, never joins your workspace, and never appears in your team list.
Bound to one site
isolatedA member session is issued for one project and rejected on any other, so one site's members can never read another's.
Short sessions
15 minA member's token lives at most fifteen minutes before it is refreshed, so removing someone takes effect within one token lifetime.
Drive it from your own code
Members, groups, page access, data restrictions and SSO settings all sit behind a REST API, and every one of those endpoints accepts a project token as well as a dashboard session. So the screens are a convenience, not the only way in — you can read and manage members from a script, a back-office job, or an agent.
curl "https://spideriq.ai/api/v1/dashboard/members" \
-H "Authorization: Bearer $PROJECT_TOKEN"
# 200 — the same list the dashboard shows youTo be straight about the edges: there is no members command in the CLI and no members tool in the MCP server today. The REST API is the agent surface for this feature, and it is a real one.