Library Kata "User login"

Develop a library that can be used to manage user logins to websites.

The contract for the library's services should look like this:

interface IRegistration {
	void Register(string email, string password, string nickname);
	void Confirm(string registration number);
}

interface IRegistration {
	string Login(string login_name, string password);
	bool Ist_Anmeldung_gültig(string token);

	void Reset_password_request(string email);
	void Password_reset(string email);
}

interface IVermanagement {
	User Current_User(string token);

	void Rename(string userId, string email, string nickname);
	void Change_password(string userId, string password);
	void Delete(string userId, string password);
}

class User {
	string Id;
	string Email;
	string Nickname;
	DateTime Registration date;
	DateTime LastRegistration;
	DateTime LastUpdate;
}

New users register yourself first. You must enter at least your e-mail address. If no password has been chosen, the registration will generate one that the user can change later.

Anyone who registers will receive a registration email with a confirmation link containing a registration number. Only once the registration has been confirmed with this number is the user permanently in the system (User Confirmed is then true).

The Registration is carried out with an email address or nickname and password after confirmation. If it is successful, it returns a token. This can later be presented again and again as required to check whether requests from a client are valid. For this purpose, the token should be designed in such a way that clients cannot forge it. For the rest of the world, the token is opaque.

If you have forgotten your password, you can request a reset. A message will then be sent to the email address containing a link that can be used to request a new password. If you click on the link, a password will be generated and sent to the email address you requested.

Users can edit their Change login data. They access it via their token, which they receive when they log in. The user data is then identified via an internal ID; users are therefore entities whose data can be changed except for the ID.

Data

How the user data is stored should not be prescribed. In any case, however, passwords must not be stored in plain text in the user database.

Unconfirmed registrations should be given an expiry date and then automatically deleted.

The library must be configured with a few details, e.g.

  • Connection data for the user database
  • SMTP server and account
  • URLs for pages referred to in emails

How the configuration data is saved is also not specified.

en_USEnglish