[buddypress-trac] [BuddyPress Trac] #8139: Network Invitations and Membership Requests
noreply at wordpress.org
Mon Oct 21 17:01:36 UTC 2019
#8139: Network Invitations and Membership Requests
Reporter: dcavins | Owner: (none)
Type: enhancement | Status: assigned
Priority: normal | Milestone: 6.0.0
Component: Registration | Version: 5.0.0
Severity: normal | Resolution:
Comment (by boonebgorges):
Thank you for beginning the discussion about this, @dcavins ! I agree that
the account registration process is a pain point for many BP
installations. Spam is sometimes a problem, though there are others:
limited customizability (such as multi-step registration), the difficulty
of integrating with SSO (those tools often auto-provision accounts in a
way that bypasses BP's profile fields), the lack of a built-in invitation
system (see Invite Anyone), etc.
For a bit of context, the current registration flow is:
a. User visits the BP register page
b. User enters WP account info (username, password, email) and BP profile
data, as well as blog info if enabled
c. A new entry is created in the `signups` table, which includes user-
provided data as well as a confirmation code
d. An email is sent to the user to confirm their registration. This is the
main anti-spam and anti-impersonation prevention measure. The email
contains a confirmation link, built using the confirmation code.
e. User clicks through and confirms registration
f. The entry in the `signups` table is converted to a WP user, a site is
created if relevant. These steps are handled by WP.
g. BP saves any xprofile data stored with the signup
Your proposal suggests taking some of the existing flow that's handled by
and/or closely mirrors WPMS (such as the `signups` table for DB storage
and the WP-native user creation in f) and putting it into BP.
I have a couple broad questions and concerns about this proposal.
First, by doing ourselves what WP currently does (and has always done), we
risk compatibility breaks of various sorts. For example, plugins that
modify the WP user registration process, and as such automatically work
with WP, may not work in the same way. The same can be said for site-
specific customizations. Related, it seems bad for us to add a bunch of
infrastructure to BP - like confirmation codes and `meta` - that duplicate
what already exists in `wp_signups`, if for no other reason than that we
don't need the maintenance overhead.
Second, I don't really see how the proposed changes help to mitigate spam
registrations. The current system means that the majority of successful
spam accounts are generated by real people (automated turk, etc) than by
bots. Moving the confirmation email step earlier in the process won't
I love the idea of having an account invitation system, but it seems to me
we could simplify it by using the `wp_signups` tools that already exist.
So, a BP invite could trigger the creation of a `signup`, but we wouldn't
allow WP/BP to send a confirmation email. Instead, we'd send our own
invitation email, and the "accept" link would be something like:
`/register/?key=12345`. When we detect `key=12345` on the register page,
we check for a matching `signup`, and perhaps pre-fill some of the info,
like `email`. Then, we allow the user to walk through the existing
registration system, including the confirmation step. (We might need some
mechanism to allow someone from manually entering the confirmation code
into /activate/ without going through registration, but this seems fairly
If we really want to help prevent spam signups, I think there are other
things we could focus on, which are independent of the invitation system.
BP could ship with things like honeypots; the option for admins to confirm
pending registrations; improved integration with third-party services
(Akismet?) for pre-screening of invitations; etc.
But I do really like the idea that having out-of-the-box site invitations
would allow admins to configure their site in order to limit registration
in various ways. As we build, we should think about how and whether this
system can be leveraged by people trying to customize registration in yet
other ways - I'm thinking especially about institutional SSO (ldap,
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8139#comment:5>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac