Support even simpler, insecure, authentification.

[Kuinox]

Customer want an insecure logging with only an username and a list of allowed username.
I think we should support this sort of authentification:

• It would allow us to not reimplement it every time.
• Could make it more secure than the naive implementation (like rate limiting to make bruteforcing harder)
• It also allow us to upgrade easily to a real, and secure, auth system

[olivier-spinelli]

IMO there is a rather simple solution: use the regular CK.DB.UserPassword and such users have the "no-pwd" password. The front hides the password textbox and sends "no-pwd" to the back.

The idea is that the login will challenge the password AND the user name: only "registered users" will be allowed (no typos are possible in the user name).

To "soft delete" a user (more precisely to revoke its login), it's enough to set a new Guid as its password. Its authentication will automatically fail.

Note that there may be users with "no-pwd-1", "no-pwd-2": this supports the case where multiple "kind of users" must log:

• The front displays a select box with the "Kind" (or tabs or whatever)
• Each "kind" is associated to a different password.

This is a Front issue actually. One need the hiding of the password textbox and admin screens to manage them.

One last idea: if, for some users, authentication becomes required:

• Set him a real password (and communicate it).
• Let him enter its user name as usual and attempt to login with "no-pwd".
• This will fail: simply display the password textbox.
• Cherry on the cake: on failure, before displaying the password textbox lookup for the user name and only if it exists, display the password textbox.

This really seems to be all about Front development...

[olivier-spinelli]

There may be a DB package: a simple table "CK.tPseudoUser" (or GuestUser?) with the UserId and the "password" that tracks these users. There's no need to add any field in tUser.
One may create a Group "PseudoUsers" that is synchronized with this table so that Acl can easily deny any pseudo users like these.