User management

[nichtich]

This is a more complex issue to be discussed. We soon need a users table with things like

• user name
• user homepage
• user identity URIs (one to start with, multiple later e.g. to both ORCID and Wikimedia)
• user rights

The users table is public and accessible via its own endpoint. One could infer its information from mappings and annotations anyway.

Admin (#39) is not a kind of user but an additional method to interact with the database.

user rights

I any case we don't want to store passwords and user rights should not be too complex. For instance two boolean status:

• editor (can create/edit its own mappings if editing is enabled and identity is confirmed)
• reviewer (can create/edit its own annotations if editing is enabled and identity is confirmed)

The server can be configured which status new users should have by default.

We don't want complex roles and rights such as who-is-allowed-to-add-or-annotate-which-kind-of-mappings. This must be solved by having multiple instances of jskos-server.

private user information

This should not be stored in the database for security and privacy reasons (use in-memory and/or flat-file store instead). Backup is not needed.

• private settings - a simple key-value store with optional schema to be used to store cocoda settings. User should be able to purge this
• access tokens to confirm identity via an identity provider

[stefandesu]

I agree that it's better to not store user data. Instead, we could add an option to Cocoda to import/export settings so that a user can synchronize two of their devices manually if needed.

[nichtich]

With https://github.com/gbv/cocoda-userdb the user management will not be part of jskos-server but it needs to be connected with jskos-server.

[stefandesu]

Closed in favor of #44.