What it is
A members area is a part of a website that only certain people can open. Everybody can see that the content exists — a page keeps its title, its date and its description — but the content itself is sent only to someone signed in as a member.
It runs on this website. Some pages here are reserved; a member signs in and reads them, and everybody else sees that they exist and cannot open them. The post about it covers the same ground for a reader who has not met one before.
It is not an app and it is not a separate service with its own login screen and its own monthly bill. It is the same website, with some of it reserved.
What a member sees
A reserved page keeps its place. It sits on the blog with everything else, its title and description public, marked with a lock.
Opening it without being a member shows the title, the date and the description, and then a card in place of the text saying the page is for members, with a button through to the sign-in page. Nothing else about the page changes.
Signing in changes three things. The reserved pages open like any other page. The header shows the member’s name and offers a way out again. And an account page says who they are signed in as and when the session runs out.
How signing in works
A member types the email address they are registered with, and a link arrives. Clicking it signs them in. There is no password to choose and nothing to install.
The link is valid for fifteen minutes. The session it opens lasts one day, held in a cookie the browser will not hand to any script on the page. After that, another link.
There is no signup form. An address that is not on the member list gets no link, however many times it is typed into the form — and the form says the same thing either way, so it cannot be used to find out who the members are.
No database — the member list is a file
A member is a line in src/config/members.config.ts: an email address and a name. Somebody asks for access, the line is added, and the next deploy lets them in. The record of who had access, and when, is the repository’s history.
The session is the same idea. There is no session table; the cookie carries who the member is, signed so it cannot be edited, and it expires on its own. Nothing about who is a member or who is signed in is stored in a database, because there is no database.
That has a consequence worth stating: a cookie already issued cannot be withdrawn before it expires. Removing someone from the list stops them signing in again, and the one-day session is what limits the gap. Rotating the signing secret ends every session at once, which is the lever for a lost device.
The configuration also carries tiers, for a site where different members should see different things. This one has none, so every member sees the same pages.
Built to be safe
The reserved text is never put into the page for someone who is not entitled to it. It is not hidden with CSS, greyed out or blurred — it is absent. Those pages are marked private and not to be stored, so nothing between the server and the reader keeps a copy.
They stay out of the RSS feed, out of the sitemap and out of the site’s own search, so the text cannot be reached by a route around the front door.
The sign-in link is signed with a server-side secret; change one character and it stops verifying. Asking for a link is rate limited, so the form cannot be used to fire mail at an address over and over.
The whole feature runs only when its signing secret is set. Without it no member routes are built at all and every reserved page is hidden — the failure a members area cannot afford is serving reserved content by accident, and an unconfigured site cannot, because the pages are not there.
What it took to build on a static site
Nearly every page of this website is built once, at deploy time, and served as a file. That is what makes it fast, and it is the reason a members area is harder here than on a site that renders each page on request: the code that would check who you are runs while the site is being built, long before anybody visits.
So the reserved pages are the only ones that are not built in advance. Each gets a route of its own, rendered when it is asked for, at the same address it would have had anyway. The other posts stay static and untouched. A reader cannot tell which is which from the address bar, and the site keeps its speed everywhere it matters.
Which websites need one
Clubs and associations, where members have things to read that the public does not — minutes, forms, a schedule.
Courses and schools, where the material belongs to the people who signed up for it.
Bloggers and tutorial writers who keep some of what they write for readers who ask.
The common thread is a group who all see the same content, and an owner who knows who is in that group.
A members area is also how paid content usually works: a site charging for a course or a set of guides takes the payment first and adds the buyer to the list afterwards. Deciding who may read is the part a members area does; taking the money is a separate piece of work and is not in this one.
Why I built this, and why I built the client portal
I am interested in this kind of solution on an Astro website — for the businesses and clubs and other organisations that need one. A business needs the client portal. A club needs the members area. It is interesting how it works, and it has to be safe.
The two answer opposite halves of one question. A client portal gives each person their own: their projects, what the work is waiting on from them, their invoices. Two clients signing in see two different sets of pages. A members area gives every member the same: one set of reserved content that all of them read. Which one a website needs comes down to whether the people signing in are looking at the same thing or at different things. Both are written up as posts — the members area and the client portal.
I built both of them on this website, to make them work and to test them. Building for yourself is the best way, because you can test it all the time — on the site you use every day, where you would notice the morning it broke.
The Members Area is one of three projects that grew out of Hans Martens Dev — alongside Astro Rocket and the Client Portal.