Roles and security

The rule

An invitation can only ever grant a low-privilege, subscriber-like role. No role that can edit or publish content, and no role that can manage any part of the site, is offered in the selector or applied when an account is created.

Of the roles a standard WordPress install ships with, only Subscriber qualifies. Contributor, Author, Editor and Administrator are all excluded.

How a role qualifies

It is not a fixed list of names. Every role registered on your site is examined for the capabilities it actually holds, and it is excluded if it has any of these:

Administrator is excluded outright regardless.

Because the test is capability-based, it works properly with roles nobody at WordPress has ever heard of. A membership plugin's Member role, an LMS's Student, WooCommerce's Customer, or a client-area role you built yourself will all appear in the selector automatically, as long as they are read-level. You do not have to register anything with the plugin.

My role is not in the list

Then it holds at least one of the capabilities above. That is the whole explanation, and it is nearly always right: roles named things like Shop manager or Team member usually turn out to have edit_posts or upload_files attached.

You have two honest options.

1. Invite them low, then promote them. Send the invitation as Subscriber. Once they have registered and you can see the account is theirs, change their role under Users in the usual way. This is the intended route, and it takes about four seconds per person.
2. Give the role fewer capabilities. If a membership role has upload_files that nothing actually uses, removing it with a role editor plugin makes the role invitable. Only do this if you understand what else relies on it.

There is deliberately no override setting. A switch labelled "let invitations grant any role" would be turned on by somebody in a hurry, and the whole protection would be worth nothing from then on.

The check runs twice

Once when the selector is drawn, so you cannot pick a role that is not allowed, and again at the exact moment the account is created.

The second check is the one that matters. It means a record that has been tampered with, or a role that was fine when the invitation was sent but has since been given new capabilities by a plugin update, cannot produce an over-privileged account. When the stored role no longer qualifies, the account falls back to your default role, and if that no longer qualifies either, to Subscriber. It never fails open.

What the invitation link can and cannot carry

Editing the URL cannot change the role, because the role is not in the URL. Changing the email in the URL simply stops it matching the record and the link fails. The code is compared using a timing-safe comparison.

The other guarantees

• Single use. A link is consumed the moment an account is created from it, and a used link can never be reopened from the admin screen.
• It expires. 1 to 365 days, 14 by default.
• The email address is fixed. The account is created with the address on the invitation, whatever the browser sends back, so the read-only field on the form is a convenience rather than the protection.
• No account, no registration. With the page guard on, someone who reaches the registration page without a valid link sees a notice instead of a form.
• Already registered means already registered. The plugin refuses to invite an address that already has an account, and a valid link for an address that has since gained an account shows "please log in" rather than failing obscurely.

Next

Using another registration plugin covers running Bang! Invites alongside a form you already have.