What a members area 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 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.
The one I built 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.
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 a way to sign out. And an account page says who they are signed in as, when their session runs out, and lets them sign out everywhere at once.
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 and one click. The session it opens lasts one day, and after that they ask for another link.
There is no signup form. Nobody adds themselves — you add a member, and there is no form for anyone else to find.
Where the member list lives
A member is a line in a file in the website’s own code: an email address and a name. Somebody asks for access, the line is added, and the next deploy lets them in. There is no database of members to look after, and no store of anybody’s details to break into.
While a member is signed in, the site keeps a note that their session is open. It is filed under a scrambled form of their address rather than the address itself, and it holds nothing else — so what the site keeps while somebody is reading says neither who they are nor that they are a member.
The list also carries tiers, for a site where different members should see different things. This one has none, so every member sees the same pages.
Why it is safe
No passwords. There is no password anywhere in it. Nothing to guess, nothing to steal, nothing reused from another site that got broken into.
The sign-in link works once. Fifteen minutes, one click, and then it is dead — even in somebody else’s hands.
A reserved page is not a page with its text hidden. The text is never put into the page for someone who is not entitled to it. It is not greyed out and not blurred; it is absent.
Access can be ended at any moment. A member who loses a laptop can sign out everywhere at once. When you take someone off the list, they are out at their next page load rather than whenever their session would have run out.
The sign-in page gives nothing away. An address that is not on the list gets the same answer as one that is, so the form cannot be used to find out who your members are. Asking for a link is rate limited as well, so it cannot be used to fire mail at somebody’s inbox.
Reserved pages stay out of the feed, the sitemap and the site’s own search. There is no way to the text except by signing in.
Nothing in between keeps a copy. Those pages are marked private and not to be stored, so no cache between the server and the reader holds one to hand to somebody else.
The members area only runs when its secret is set. Without it the member pages are not built and every reserved page stays hidden, so a site that is not configured has nothing to serve by accident.
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.
Ask me, and it is yours
The members area is free to use. It runs here so I can test it, and it is built from Astro Rocket’s own components — so a website running the theme already has everything it needs.
Ask me for it and I will give it to you. You install it and build your own website — that part stays with you, and I advise and help where you get stuck.
Questions are welcome, including the one about whether a members area is the right thing for you at all.
Why I built this, and why I built the client portal
I’m 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.
So I built both. This one gives every member the same: one set of reserved pages that all of them read, with nobody having records of their own. A client portal gives each person their own — one client’s projects and one client’s invoices, and the next client signing in sees a different set of pages. Which one a website needs comes down to whether the people signing in are looking at the same thing or at different things.
I built 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.
Also worth reading
Members areas on an Astro website — what one is, and which websites need one.
Client Portal — for a business whose clients each need their own.
Hans Martens Dev — the website this members area was built on.