Add access tokens

[gikaragia]

Closes https://github.com/Automattic/wpjm-addons/issues/161, https://github.com/Automattic/wpjm-addons/issues/160

This meant to be be an initial approach to get some early feedback. Main points:

• The tokens support expiry. I think that we should use this for guest accounts.
• The code will be in WPJM core to be able to be used by all plugins.
• The current implementation is meant to be a replacement for the unsusbscribe links. The next iteration will save data in post meta for guest accounts.
• I based my solution in an existing approach that we had in alerts for unsusbscribe links. I think that this approach is a bit more secure as:
  • It doesn't use DES
  • It stores only hashed values.
• If we agree on the approach I will also request a review from our security team.
• I am thinking that we should replace these methods with this class. We could potentially use both methods for some time to not break backward compatibility.

Changes Proposed in this Pull Request

• Adds a token class which can be used to create and verify tokens.
• It's possible for tokens to have an expiry date.

Testing Instructions

• Just check the approach and make sure that the tests pass.

---

Plugin build for 622323363e98e89303675956a6524c01f640887b
📦 Download plugin zip
▶️ Open in playground

[gikaragia]

Sorry for clicking 'request for review' @yscik this isn't ready yet. I'll notify you when it is.

[gikaragia]

Hey @yscik this should be ready to review again. I discussed a bit with @alexsanford and he came up with a much better idea. With usage of WP's already provided secret keys and the wp_nonce methods we don't really need to store anothing to provide tokens. So with this approach, we do something similar with what WP does for nonces and expiries.

As a next step I will look into migrating alerts into using this token class. This should be ready for review now.

[gikaragia]

Thank you for looking into this @alexsanford, good points!

If the server-side secret key ever needs to be rotated, all existing tokens will be invalidated. This is also true of nonces and session tokens, I believe.

We could potentially store the token somewhere but I am thinking that if the key is compromised our tokens should be expired anyway.

not have any link with a valid token

As we know how often these emails are sent we can adjust the expiry accordingly. We also have a flow to send another email if the token is expired or if the user just visits the alert management screen so I think we should be ok.