Closed pkalita-lbl closed 2 months ago
It should also make it clear that they should handle those tokens securely as if they are passwords and provide details on how to use the refresh token to obtain new access tokens and use access tokens to make API requests.
I think this is key. We should probably even make the user take extra clicks to expose the token.
I don't know if that's required by ORCID's standards.
I'm a bit rusty on the ORCID standards for member apps, so we'd need to brush up on those, but I think we'd be in the clear.
We should probably even make the user take extra clicks to expose the token.
I like that idea.
ORCID standards for member apps
And if they just require a link to the user's ORCID profile somewhere it could be on the /user
page itself.
For context, this was mentioned in the first paragraph of the Future Work section of https://github.com/microbiomedata/nmdc-server/pull/1257.
I propose we add a
/user
frontend route. This route should only be available for logged-in users. It should have a section for basic user info that displays what we store in theuser_logins
table -- their name, ORCID iD, and admin status.It should also have a section for API tokens that allows the user to copy their current refresh or access token to their clipboard and display the expiration time of those tokens. It should also make it clear that they should handle those tokens securely as if they are passwords and provide details on how to use the refresh token to obtain new access tokens and use access tokens to make API requests.
Currently the user's name in the navigation header is linked to their ORCID profile. I don't know if that's required by ORCID's standards. If not we could consider making that a link to the
/user
route instead.In the future we could consider expanding this page to collect user information that ORCID doesn't provide.