-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
|
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? |
Yes, better set the default visibility to false. |
/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
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.
I think the integration is done. Further adjustment should be their own issue. |
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:
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?
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)
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)
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)
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
The text was updated successfully, but these errors were encountered: