-
Notifications
You must be signed in to change notification settings - Fork 866
Consider having the UserValidator ensure that SecurityStamp != null #1016
Comments
SecurityStamps should never be null for a store that supports user security stamp. |
Except it was, in this case (using the default EF Core store). It's also worth mentioning that there's nothing that prevents setting |
Typically this usage is updated by the manager, I mean sure you can set it to null directly but things will blow up. We could consider adding validation in the default user validator for this since this does seem to trip more than a few people up. |
@shima20's case is obviously an atypical case, as he somehow managed to get a null security stamp. FWIW, I don't think the principal factory should shock on null values. It should be a bit smarter and ignore null claim values. |
Not for something like this, the security stamp is critical well for 'security' :) Its a major error if its null... similar to having no user id/name etc, its the user validators job to make sure the user is in a good state |
Critical seems a bit excessive (it's only used for cookies/tokens invalidation), but okay. As long as there's a check somewhere that prevents this illegal case, I'm fine 😄 |
When I called
var principal = await _signInManager.CreateUserPrincipalAsync(user);
, I was receiving an ArgumentNullException and had no idea what the issue was. Kevin from Openiddict told me to register UserClaimsPrincipalFactory to step in and see what field was null. This led me to find that my SecurityStamp was null and therefore caused the exception. Is this a bug?The text was updated successfully, but these errors were encountered: