Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User management #40

Closed
nichtich opened this issue Feb 1, 2019 · 3 comments
Closed

User management #40

nichtich opened this issue Feb 1, 2019 · 3 comments
Labels
feature Additional functionality question Further information is requested

Comments

@nichtich
Copy link
Member

nichtich commented Feb 1, 2019

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
@nichtich nichtich added the feature Additional functionality label Feb 1, 2019
@nichtich nichtich mentioned this issue Feb 1, 2019
@stefandesu
Copy link
Member

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 nichtich added the question Further information is requested label Feb 7, 2019
@nichtich
Copy link
Member Author

nichtich commented Feb 7, 2019

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
Copy link
Member

Closed in favor of #44.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Additional functionality question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants