Open lorenzleutgeb opened 8 years ago
This got even trickier with invitations:
class Invitation {
@Id
private String token;
@NotNull
private String email;
@ManyToOne(optional = false)
private Challenge challenge;
}
Invitations are lacking fields to store the first name and last name of a user, so the design in the first post cannot be modeled.
We once decided to not create a User
right after invitation, but this would be beneficial:
Invitation
could be a regular access token that relates to the User
.User.(first|last)Name
right away.GithubService
), we can do that right after the invitation e-mail was sent out. This way we do not delay the initial request when the user navigates to the token URL.User
is "active" by checking for logins (User.lastLogin
) and collect garbage.
We currently have a handful of onboarding scenarios:
Registration:
Challenge invitation:
At all times, we want to have accurate and consistent data in our database, which is a pain right now, as we'd probably see NULLs for nickname and password. Therefore I propose to reconsider the concept of a "User" as such, and define a more decoupled way of storing user data.
For example, we could represent an object that associates with forms of authentication (tokens, passwords, 2FA secrets) and identifiers (real name, nickname, e-mail address), and only establish a relation once we have that information.