Skip to content
New issue

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

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

Already on GitHub? # to your account

Integrate login-server/client into Cocoda #273

Closed
stefandesu opened this issue Feb 28, 2019 · 4 comments
Closed

Integrate login-server/client into Cocoda #273

stefandesu opened this issue Feb 28, 2019 · 4 comments
Labels
feature Additional functionality question Further discussion needed
Milestone

Comments

@stefandesu
Copy link
Member

Continuation of #15.

login-server and login-client are almost ready to be integrated into Cocoda. There are a few remaining questions regarding this integration though:

  1. As I understand, we want to give the user a choice which URI to use when creating mappings. By default, it should probably be the login-server URI, but one could decide to use their ORCID iD or GitHub account instead. Is that correct?

  2. Should there still be a custom URI field when a user is not logged in, e.g. to be written into local mappings? (probably yes)

  3. Related to 2: Should there be an option to rewrite all local mappings with a new creator after logging into an account? (could just be integrated into the "Rewrite creator for all local mappings" button)

  4. Should there be an option for a logged in (and therefore authorized) user to remain anonymous by not providing a URI? (I'd say no, but not sure about this)

  5. Should all previously used login code (with credentials) be removed? (I'd say yes because it's harder to maintain, but we could keep supporting both types of authentication for backwards compatibility)

There will be probably even more questions after starting to integrate it into Cocoda.

@nichtich

@stefandesu stefandesu added feature Additional functionality question Further discussion needed labels Feb 28, 2019
@stefandesu stefandesu added this to the 0.8.0 milestone Feb 28, 2019
@nichtich
Copy link
Member

  1. Yes, user should be able to switch his identity URI selected from the URIs provided by login-server. I'm not sure which URI to use as "default". We better include a modal or text at the settings form with brief description of consequences:

Which identity should be stored with your mappings and annotations?

  • a third-party identity makes your contribution visibly connected to a public user profile
  • an internal identity URI provides some degree of anonymity
  1. Yes but only for local content when not logged in. This could be called "fallback identity"? There may be mismatch if user locally saves mappings both logged in and logged out, but that's what the function"
    "Rewrite creator for all local mappings" is for.

  2. Yes, there is one function "Rewrite creator for all local mappings". We might add warnings, hints or an option to always rewrite creator after login so users find this function.

  3. No, the jskos-server URI provides some anonymity.

  4. Yes! Code must be eliminated! Resistance is futile!

@stefandesu
Copy link
Member Author

4. No, the jskos-server URI provides some anonymity.

That would only be the case if we decide to not show information publicly in login-server (see gbv/#-server#15). So I guess we've decided?

@nichtich
Copy link
Member

Yes, better set the default visibility to false.

stefandesu added a commit to gbv/#-server that referenced this issue Feb 28, 2019
/users now returns an error 403 (either remove it or keep it with access limited to admins).
/users/:id now returns an error 403 if the accessed user is a different user from the one logged in.

gbv/cocoda#273
stefandesu added a commit that referenced this issue Mar 4, 2019
Note: This is not yet integrated in jskos-server, so saving mappings won't work yet. Also, some more adjustment to the interface and the text is needed.
stefandesu added a commit that referenced this issue Mar 7, 2019
@stefandesu
Copy link
Member Author

I think the integration is done. Further adjustment should be their own issue.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
feature Additional functionality question Further discussion needed
Projects
None yet
Development

No branches or pull requests

2 participants