2

This article and this StackOverflow answer say that the DataProtectorTokenProvider needs to be a static class so that it can recognise tokens generated by itself earlier. I found the same behaviour that it doesn't work when it's instantiated again for verifying the token.

I believe this is not an optimal solution for distributed environments, e.g. Azure. If the token is generated by an instance which is deallocated afterwards and another instance has to deal with the token verification then it will fail, and there is no guarantee it will ever succeed.

Is there a boilerplate implementation to make it stateless, e.g. store the token in Redis Cache or SQL?

Community
  • 1
  • 1
Adam Szabo
  • 11,302
  • 18
  • 64
  • 100
  • 1
    Static instance is a hack and indeed does not always work. I'll be interested to see if there are better solutions – trailmax May 05 '16 at 09:41
  • Have you seen this discussion: http://aspnetidentity.codeplex.com/workitem/2439 ? Identity authors approved of the static reference. But I still don't like it, still a hack. – trailmax May 05 '16 at 09:50
  • I got around the issue by saving it in the database. I use a subclass of `UserManager` where I override `GeneratePasswordResetToken` and `ResetPasswordAsync` to store/read the generated token from the DB. So the incoming token is not verified by `DataProtectorTokenProvider`, only compared with the value in the DB. If I won't receive a better answer I will post it. – Adam Szabo May 05 '16 at 13:49
  • Issue with this - approach is that you need to remember to kill this stored token after a period of time, even if it was not used for password reset. Time of issue plus active period will work. And also when you change `SecurityStamp` on user record, stored token needs to be removed. – trailmax May 05 '16 at 22:39

0 Answers0