A members area is a part of a website that only certain people can open. They sign in, and content that stays closed to everybody else opens for them.
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.
This one runs here, on hansmartens.dev, and has its own page in the portfolio. It is the second of two projects I built to answer the same kind of question: how do you give a small group access to part of a website, without turning that website into an application with a database behind it.
What a locked post looks like
A page in a members area keeps its place. It stays on the blog alongside everything else, and its title, its date and its description stay visible to everybody. A small lock marks it.
Opening it is where the difference shows. The title is there, the date is there, the description is there — and where the post should be there is a short card instead, saying that this one is for members, with a button that leads to the sign-in page. That page asks for an email address and sends a link. Nothing else on the page changes.
The title and description staying public is the point rather than an oversight. Somebody has to be able to see that something exists, and roughly what it is, before they can decide they want to ask for it.
What is missing is the post itself. Not hidden with CSS, not greyed out, not blurred — the text is never put into the page at all unless the person asking is entitled to it. It also stays out of the RSS feed, out of the sitemap, and out of the site’s own search.
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 a day, held in a cookie that the browser will not hand to any script on the page. After that, another link.
There is no signup form. A member is a line in a configuration file — an email address and a name — so somebody asks for access, I add them, and the next deploy lets them in. That is deliberate: the kinds of websites this suits already know who their members are.
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 it is not in what I built here.
How it differs from a client portal
The client portal is the other project, and it answers the opposite half of the same question. It has its own page in the portfolio too.
A client portal gives each person their own. A client signs in and sees their projects, what has happened lately, what the work is waiting on from them, and their invoices — read live from the bookkeeping, so no figure is copied anywhere or kept up to date by hand. Two clients signing in see two different sets of pages. It suits a business with clients: agencies, studios, photographers, architects, accountants.
A members area gives everyone the same. There is one set of hidden content and every member sees all of it. Nobody has their own records, because there are none to have.
Which one a website needs comes down to whether the people signing in are looking at the same thing or at different things.
Why it is safe
Neither project has a password in it, and that is what makes them safer rather than weaker. There is no password to reuse on another site, to be phished out of somebody, to be guessed, or to appear in a breach that had nothing to do with this website. There is none for me to store and none for anyone to reset.
What arrives instead is a cryptographically signed link. Change one character of it and it stops verifying, so it cannot be edited or forged. Clicking it sets a cookie signed the same way, which JavaScript on the page cannot read and which is only sent over HTTPS.
The sign-in page gives nothing away. An address belonging to nobody gets the same answer as one belonging to a member, in the same words, so the form cannot be used to work out who a website’s members or clients are.
A locked post is not a post with its text hidden from view. The text is not in the page at all unless the person asking is entitled to it. Those pages are marked private and not to be stored, so nothing between my server and the reader keeps a copy to hand to somebody else.
And there is no database, so there is no store of anybody’s data to break into. The member list is a file in a private repository; the client portal reads the bookkeeping, which was already the record.
Why it runs on my own website
To find out whether it works. Building something and putting it on a site nobody uses proves less than running it where I would notice the day it broke. So it is here, on the site you are reading, and I sign in to it the same way anyone else would.
That is also the part that surprised me. Making a members area work is straightforward. Making one that works correctly, every time, and gives nothing away when it fails is a much more interesting problem than I expected it to be.