Member Access

Logging in with an email code

A visitor asks for a login code by entering their email address in the login form. If the address is admitted by the allowlist, an eight-digit code arrives by mail. The code is valid for ten minutes and works once. Entering it logs the visitor in, and the first login also creates their account: the username is their email address, and they are placed in the reader group. A login is remembered for about a month, so members are not sent to their inbox on every visit.

A member never has a password: setting one is refused, and so is having a temporary one mailed by a password reset. A code also never opens an account that was created some other way, so staff accounts cannot be entered through the code login at all.

Members can read and nothing else

Members are placed in a dedicated reader group, and loading the extension revokes from that group everything that would let a member change the wiki or see behind the scenes: editing, commenting, moving, uploading, sending email through the wiki, and reading or changing their own private information and preferences. Your staff accounts are ordinary MediaWiki accounts and keep working exactly as before. Page histories and recent changes therefore only ever name staff, since members cannot appear in them.

Groups and the allowlist

An allowlist entry is a single address or a whole domain, written as @example.com, and belongs to exactly one group. Groups are how you keep the roster organized: one per client, per course, per chapter, whatever fits your organization. The member roster records each member's address, group, creation, last login and whether they are active, with totals overall and per group, and is available through the management API.

The allowlist is consulted again at every login, so removing an entry ends access the next time the member tries to get in.

Deactivating a member

Deactivating a member blocks their account sitewide, at once, and indefinitely. The block is an ordinary MediaWiki block, so it appears in the block log and can be lifted by hand. Reactivating restores access and leaves the account otherwise as it was. A deactivated member asking for a login code gets no mail, and the same on-screen answer as an address that was never admitted.

Single sign-on

Logins through PluggableAuth, so through your identity provider, are held to the same allowlist: the address the provider returns has to match an entry, or the login is refused. A first login that matches is provisioned exactly like a code login. Accounts that are not members are exempt, so staff signing in through the identity provider are unaffected.

Nothing gives the member list away

Who your members are can itself be sensitive information, so the extension is built to not leak it. Requesting a login code answers the same for every address, whether it is on the allowlist or not, and so does requesting a password reset. The account listings in the API are closed to members, and the two logs that record members, the new user log and the block log, are restricted to staff who manage members.

Login codes are stored hashed and are burned after five wrong entries. Code requests are rate limited per email address and per client IP, and every issue, success, failure and rate-limit hit is written to an audit log, with the email address hashed.

The management API

Groups, allowlist entries and the roster are managed over a REST API under /rest.php/member-access/v0/. Every endpoint requires the memberaccess-manage right, which sysops and bureaucrats have by default, and writes require the wiki's CSRF token.

Failures answer with a stable errorCode next to a human-readable message. The API reference lists all endpoints and error codes in detail.

Member Access works without configuration: loading the extension is the switch that turns members-only access on.

Making the wiki private

Member Access decides who can log in, not who can read. On a standard MediaWiki anyone can read every page, so a members-only wiki pairs the extension with the usual private-wiki setting in LocalSettings.php:

$wgGroupPermissions['*']['read'] = false;

Logged-in users, members included, can then read, while anonymous visitors are left with the login page. See Preventing access for the full picture. The extension also turns on MediaWiki's setting that makes a block disable logging in, so a deactivated member is kept out of a private wiki entirely rather than merely blocked from editing.

What loading the extension changes

Beyond the reader-group restrictions described above, loading the extension:

• restricts the new user log and the block log to staff who manage members, unless your wiki already restricted them;
• lets accounts create themselves at first login, since that is how members come to exist;
• makes @ usable in usernames, so that accounts named after email addresses work throughout MediaWiki;
• sets how long a remembered login lasts to thirty days, for everyone on the wiki, not only for members.

The README documents the full list of changes.

Settings

Everything has a sensible default and can be tuned: the name of the reader group, how long a code stays valid and how often one may be requested per address and per IP, the address codes are sent from, which account-listing API modules are closed to members, and how long a remembered login lasts. The configuration reference lists every variable with its type and default.

Logging and storage

Route the log channel to keep the audit trail:

$wgDebugLogGroups['MemberAccess'] = '/path/to/memberaccess.log';

Issued codes and rate-limit counters are held in MediaWiki's main object stash, which is database-backed by default. Point $wgMainStash at Redis or Valkey to keep them out of the database.