Hey,

Not sure if that's the right category, but here goes.

I want to implement a plugin which makes it so the email addresses of registered users are stored hashed for privacy reasons.

I think I can use action:user.email.confirmed to overwrite the email with its hashed version.
I want to still support password reset and to that end I want to use the hashed provided email to get the uid of the user.

Would it be possible to add a hook for filtering the email provided to getUidByEmail here?

Additionally, in order to use the non-hashed email as the address, it would also require passing the user provided email in params here.

Wdyt?

See here for more details.

Thanks!

Thanks!

I guess I can hook to action:user.email.confirmed for reading the existing email and then replacing it with a hashed version.

However, password reset wouldn't work since it wouldn't find the uid for the (non hashed) email address provided (here).

We can add a hook for preprocessing the email before looking for the uid, but that won't be enough since later the email is sent according to the email field in the db (i.e. not the email provided by the user when asking to reset).

One possible solution is:

1. Add a hook for preprocessing the email used for getting the uid.
2. Pass the provided email in params to emailer.send (here) like it's done for welcome and email verification.
3. And here instead of checking that for the template check if params.email is defined.

Does that make sense?

@pitaj Yes, this is one downside of this approach.

Users with unconfirmed email will not be able to post, so at least there won't be posts associated with the unhashed email, but this is not ideal.

@pitaj I was thinking to compare the hash of the provided email to the stored hashed emails in the db.

Hey,

For privacy reasons, I want to only store the hashed-salted version of a user's email (in favor of restoring the user's password for example).

It seems one way to go about this is to hook to action:user.email.confirmed and there generate a salt, created hashed email, store hashed email and salt and remove the non-hashed email from the db.

Then I would also need to also hook somewhere in the forgot email logic.
This would also require disabling email editing for the user of course.

The downsides of the above are:

1. The email is kept in the db during confirmation stage.
2. Its a bit wasteful to write the non hashed email and then delete it and write the hashed one.

I'm new to NodeBB (and web development in general), and would appreciate any pointers.

Thanks!

@baris @baris Thanks guys. It's working well.

@baris That was fast Thanks!

I'll check it out and update.

Actually even if I add an empty template, by the time the hook for checking the domain of the email triggers, the email interstitial would already update the non-validated email in the database and send a confirmation email ...

Any suggestions?

@baris IIUC the function registered to filter:register.interstitial adds objects to data.interstitial with template, data and callback.

It seems callback is optional, but template isn't.
I tried using a callback to verify the email to throw an error when it fails, but looks like I have to specify a template (which I don't need).

I guess I can try to add an empty template, but I'm wondering if there's a better way.

@baris Thanks for the quick response!

Not in front of a computer right now, but AFAICT this plugin hooks to the filter:register.check which fires after username and password are provided, but before email is provided (which happens later via interstitials).
Maybe things changed since it was written?

What am I missing?