Feature Request: "Public Membership" Mode (Open Registration, Custom Login UI, and Role-Based Routing)

[JackCalihan]

Hi EmDash team! First, I really appreciate the architecture of the CMS—the D1/R2 integration and native passkey support are fantastic.

However, in building a site that offers gated/paid content to the public, I've run into some significant architectural friction. Currently, EmDash's authentication and routing seem heavily optimized for an "Editorial Team" model (where all users are known staff or contributors). When trying to adapt this to a "Public Subscription" model, a few security and UX vulnerabilities emerge.

I'd love to propose a "Membership Mode" configuration to address the following pain points:

1. Open Registration vs. Domain-Restricted Signup

Currently, selfSignup requires whitelisting specific email domains. There is no native way to allow open, public registration without building a custom native plugin to manually inject users into the users table.

• Proposal: Add a globalSelfSignup: true (or domains: ["*"]) option to the auth config, allowing any email address to register and automatically assigning them a defined defaultRole (e.g., subscriber).

2. Simpler Registration Flow (Unified Magic Links)

The current public signup flow feels fragmented. Using the requestSignup endpoint sends an email, but clicking that email link hits the verify endpoint and simply returns a JSON object instead of actively logging the user in and setting their session cookie. To get a seamless "enter email -> click link -> logged in" flow, I currently have to bypass the signup API, pre-register the user in the DB manually, and trigger the magic-link/send API instead.

• Proposal: Unify the Magic Link and Signup flows. If a user enters an email that doesn't exist, the system should ideally be able to auto-provision them as a Subscriber and send a standard Magic Link that logs them in with one click. See TacoBell.com!

3. Role-Based Dashboard Blocking

Right now, any authenticated user can technically hit the /_emdash/admin routes. While permissions prevent them from doing much, exposing the backend dashboard URL to public subscribers is an unnecessary security surface (similar to the classic WordPress /wp-admin vulnerability). Most wordpress sites have hacky solutions to prevent users from accessing the admin area but many vulnerabilities are left open.

• Proposal: Add a loginRedirect or role-based routing setting. If a user authenticates with a role below Contributor (Level 20), they should be strictly routed to the site root (/) or a custom profile page, and any attempt to access /_emdash/admin/* should return a hard 403 Forbidden.

4. Custom Login URL & Branded UI

Currently, the login page is hardcoded to /_emdash/admin/login and uses the default EmDash branding. For a public-facing subscription site, it's vital to maintain brand trust during authentication.

• Proposal: Allow configuration of the login path (e.g., loginPath: '/login'). Additionally, allow basic UI customization for the native login screen—most importantly, the ability to pull in the configured Site Logo (from emdash:logo settings) instead of the default EmDash logo.

Implementing these features would make EmDash an absolute powerhouse not just for team blogs, but for indie hackers, newsletters, and subscription platforms (competing with setups like Ghost or WordPress + MemberPress).

Would love to hear your thoughts on this!

[ascorbic]

I like this idea. We are working on pluggable auth in #398 which could work alongside this. I would like to dig in deeper to the ideas though. Right now there isn't any expectation that user accounts will be used for anything except for the admin dashboard. I am in two minds about whether mixing these concepts makes sense tbh.

[JackCalihan]

Hi Matt, thanks so much for taking the time to reply and share your thoughts! I completely understand your hesitation about mixing these concepts. Keeping the core CMS lean, focused, and strictly secure is exactly why EmDash is such a breath of fresh air.

I’ve been looking closely at the new Pluggable Auth system in #398, and I have to say, it is brilliantly executed. Seeing how elegantly it handles canSelfSignup and assigns default roles (like Subscriber) actually made me realize that this pluggable architecture might perfectly solve the friction I was running into, without muddying the core.

My main thought process comes from watching how the WordPress ecosystem evolved. When developers inevitably started building e-commerce (WooCommerce), forums (bbPress), or membership sites, they were forced to build incredibly hacky, insecure workarounds to give front-end users accounts while desperately trying to block them from the /wp-admin dashboard.

Because EmDash is so powerful, developers are absolutely going to build these types of sites with it. My fear is that if basic, local email/magic-link registration isn't supported natively alongside the new OAuth providers in #398, it will encourage developers to build those same insecure, third-party workarounds again.

If a native EmailAuthProvider (or just allowing the existing Magic Link system to auto-provision Subscribers) was built-in, the security auditing for front-end registration would remain under the watchful eye of the core community, keeping the whole ecosystem drastically more secure.

This also seems to tie in beautifully with the vision laid out in the recent blog post. If EmDash natively supports x402 so creators can charge for content, those creators will ultimately need a secure, standardized way to authenticate their buyers on the front end.

If the new Pluggable Auth system could simply pair open registration with a strict loginRedirect (so Level 10 Subscribers are pushed back to the front-end and never even see the dashboard), it would empower creators to build secure paywalls while keeping the admin area perfectly isolated.

I’d love to hear your thoughts on whether leveraging the momentum of #398 to handle this feels like a cleaner path forward. Thanks again to you and the team for the incredible work on this project!

[vikramrojo]

+1 to all of this from a slightly different angle — I'm building a paid-fiction reader on top of EmDash where the host app layers its own per-story entitlement (Stripe Connect direct charge → Purchase row keyed by story + email/userId). Point 3 in particular bit me: the documented Subscriber semantics ("read published content, no draft access") are correct, but they become a leaky abstraction the moment the host introduces gated content. An authenticated Subscriber can hit any published story page directly and EmDash will happily serve it, so the paywall has to be re-enforced in the render layer — which works, but means "Subscriber" is quietly doing two contradictory jobs: "free reader who logged in" and "reader who paid for X." Would love a config knob to mark the Subscriber role as host-managed (EmDash treats them as authenticated identities, host opts in to which collections that role can read) — that'd let multiple entitlement models layer cleanly without each shipping as a custom plugin.

[minemeraj]

This is exactly what the emdash-better-auth plugin was built for — the "public membership" model rather than the editorial-team one.

Out of the box it gives you:

• Open public registration — any email can self-register with email/password (or Google/GitHub), assigned the subscriber role automatically. No domain allowlist.
• Prebuilt, self-styled auth UI — sign-in / sign-up / password reset / email verification pages, so you don't have to build the login UX yourself. It also cross-links to EmDash's passkey admin login, so staff and public users coexist.
• Unique usernames (as of v0.2.0) — public users get a required, unique handle to show on comments/bylines instead of their email; the plugin enforces uniqueness. Email stays private, used only for recovery.
• Real EmDash users — signups land in the users table as subscriber, so they flow straight into the existing comment endpoint, RBAC, and admin tooling.

So the open-registration + login-UX pieces of this request are available today as a plugin — no need to hand-inject users into the DB. Repo + docs: https://github.com/theweekendprojects/emdash-better-auth · npm emdash-better-auth.

Sharing in case it helps anyone building a subscription/membership site on EmDash.