This could be solved by using the URL as a payload, and including a signature made up of part of the URL and a site secret.
i.e. /c/features/unsubscribe/<user>/<sig>/ then the topic/category and user can be checked against the generated signature.
Where the signature can be sha(concat(<name>,<category/topic>,<secret>))
This removes the need to store any state server side, additionally an expiry and/or nonce could be encoded.
I agree this is true. But I would question how much of an issue what would be. As long as the emails aren’t made public (i.e. raw email view for email responses) then it’s unlikely that anyone would ever be able to get hold of the URL signature.
I don’t think forwarding emails to other people is a very common thing, especially on public forums where you can just send a link to the thread.
I’m hoping that others in the community could help us gauge how much of an issue this might be.
I could be that when you unsubscribe using the email link, you get sent a message saying that you have unsubscribed. But I feel like this is adding a lot of complexity for little benefit.
If I’m not mistake, the SSO nonce is stored in the DB with an expiry. Could that be used to keep these params stored in Discourse? then it can redirect as appropriate when the user is returned (using the nonce as a session token or similar).