[buddypress-trac] [BuddyPress Trac] #8448: Add new table to store nonmember opt-outs.

[buddypress-trac]

#8448: Add new table to store nonmember opt-outs.
------------------------------------+---------------------
 Reporter:  dcavins                 |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  8.0.0
Component:  Core                    |     Version:  7.2.0
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+---------------------

Comment (by boonebgorges):

 Thanks, @dcavins ! General approach looks good.

 It looks like `'order_by'` is not properly sanitized against SQLi. We
 either need to check against a list of allowed values (column names should
 make this fairly easy) or run through a SQL-escaping function.

 For the record, Invite Anyone uses a different approach. Each row in the
 invitation table has an 'invitee_email' column and an 'opt_out' column.
 When someone opts out of notifications, *all* rows matching the email in
 question are flagged as 'opt_out=1'. Then, when deciding whether to send
 future notifications, IA checks to see whether there are any rows in the
 invitations table `WHERE invitee_email = %s and opt_out = 1`. One fewer
 database table, but it also makes the tables and the logic a bit more
 confusing. So your approach looks good.

 Regarding @imath's suggestion: if the emails are encoded, it's no longer
 useful to have an admin panel. And this means there's no obvious way to
 "undo" or delete an opt-out, at least not as pictured. As I think about
 it, it seems that GDPR concerns, and a more general gut feeling about
 privacy, suggest that we might not the kind of admin panel you've built.
 Users do not choose to receive invitations, and if a recipient chooses to
 opt out of future notifications, it's reasonable to assume that they also
 don't want the site admin to be able to see their email address.

 We would then need a different kind of "undo" or "delete" mechanism.
 Something like: you manually enter an email address, and let the system
 hash it and compare against stored values, just like we do with passwords.
 @imath Did you build anything similar for Réception?

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