Self-Registration
Self-registration lets somebody create an account without an administrator.
Where to find it
Architect Panel → Security:
- Disabled User Accounts — accounts closed administratively
- Blocked User Accounts — accounts banned after failed sign-ins
- Permissions — what a group grants
Architect Panel → Security:
- User Verification — proving something before granting more
Architect Panel → Configuration:
- Site Settings — registration settings
The only question that really matters
Not whether people may register, but what a brand-new account can reach.
Self-registration is safe exactly to the extent that a new account reaches nothing sensitive. If registering grants access to real data, then anybody in the world has that access — and no amount of care in the form changes it.
Check it by registering
Create an account through the actual form and look at what it can see — menus, datastores, browse views, the API. Reasoning from the group configuration is unreliable, because access accumulates from several places.
Pay particular attention to the All Users group: anything granted there reaches every account including new ones, and it does not appear in your default group configuration at all.
Registration proves control of an address
Nothing more. Not who somebody is, not that they work where they claim, not that they are entitled to anything.
Verification is the upgrade path
The pattern that works: let anybody register into a minimal group, and require verification to gain more. That keeps the door open without the door granting anything, and every member of the verified group got there by passing a check.
It is also far less work than approving people by hand, and it scales.
Expect junk
A public registration form attracts automated sign-ups. With minimal default access that is an annoyance; with real access it is an incident. Rate limiting and account banning apply, and neither is a substitute for the accounts reaching nothing.
Give self-registered accounts a lifecycle
Nobody owns their leaver process, so they accumulate indefinitely. Decide what happens to an account unused for two years — because "nothing" is a decision you will have made by default.
Both models can coexist
Staff created by an administrator, customers registering themselves, with different default groups. That is usually the honest arrangement.
Worked example
A portal lets anybody register, granting only their own profile and public content. Verifying an employer domain awards the partner group. A test registration before launch found an All Users grant on a supplier datastore left over from a project, which was moved to a specific group.
Recommendations
- Decide what a new account reaches before opening registration.
- Register one and look rather than assuming.
- Verify to upgrade instead of approving by hand.
- Audit the All Users group.