A while ago I implemented the missing newsletter subscribe controller. Quite interesting that no-one noticed the absence so far

One thing that is still missing is support for unsubscribing directly via a GET parameter. First, I thought this wasn’t necessary as it is rather simple to just login and use the account option to unsubscribe.

However, I suspect that th main reason is to allow unsubscribe links in (newsletter) emails, so people can unsubscribe right away.

To mitigate this, there is a new setting to allow anonymous unsubscribe. What happens is that the unsubscribe view will either refer the user to the account area, or, if configured, show an unsubscribe form.

The only issue I do have with this is that it allows anyone to (potentially) unsubscribe other email addresses (leaving, for a moment,  aside the issues around having proper opt-in and opt-out).

What I would like to see is a system of one way hashes that can be retrieved via a service class and attached to URLs. They would then be used to verify the email address.

Additional *features* could be that they could expire to make abuse even less liklely.
Another idea would be that they are *bound* to a resource (read: a string). In the newsletter context this would be an email, but this could also be an order number, an account id, etc.

So, for example, an infividual hash would be valid only if it gets validated together with the resource it is bound to. Here, the unsubscribe controller would have both the email address and the token in the URL, so could both use to verify that the token is valid.

Once the unsubscribe is done, the token is invalidated and can never be used again.

To avoid having to add all this to core, I could imagine a plugin that could offer this sort of service. Code that wants to use it (potentially) could use some sort of generic service lookup to find out if the serivice exists. If not available, there should be fallback options about whether or not this is still ok.

The lookup could be a public version of ZMObject::singleton($name); perhaps in ZMRuntime.

Comments, suggestions or any reaction whatsoever appreciated…