[buddypress-trac] [BuddyPress Trac] #8139: Network Invitations and Membership Requests

[buddypress-trac]

#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:
 Keywords:                |
--------------------------+-----------------------

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
 affect that.

 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
 minor.)

 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,
 shibboleth, etc).

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8139#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac