Currently, all domain-level code ensures that tokens are stored with both a UserID and AthleteID. However, the database layer would store a token without a UserID, if it were asked to. This must be allowed currently because some tokens still exist from before user authentication was implemented, and so there is no associated user. Once this is no longer the case and all current tokens have a UserID, the data layer should enforce the existence of a UserID as an added protection against corrupt data.
In practice, changing this assertion to check that the statement throws and then ensuringthe test passes is what is required for this issue:
|
await tryMissingUser.Should().NotThrowAsync(); |
Also see
|
public bool IsValid() |
|
{ |
|
// todo: check UserID as well. Right now, existing tokens in prod don't have a user ID. |
|
// because they were created before authentication was implemented. |
|
return AthleteID != 0; // && !string.IsNullOrWhiteSpace(UserID); |
|
} |
Currently, all domain-level code ensures that tokens are stored with both a UserID and AthleteID. However, the database layer would store a token without a UserID, if it were asked to. This must be allowed currently because some tokens still exist from before user authentication was implemented, and so there is no associated user. Once this is no longer the case and all current tokens have a UserID, the data layer should enforce the existence of a UserID as an added protection against corrupt data.
In practice, changing this assertion to check that the statement throws and then ensuringthe test passes is what is required for this issue:
equipper/CosmosStorageTest/TokenStorageTests.cs
Line 97 in 5495553
Also see
equipper/Api/AthleteTokens.cs
Lines 15 to 20 in 5495553