You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
This is a more complex issue to be discussed. We soon need a users table with things like
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:
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.
The text was updated successfully, but these errors were encountered: