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

Nickakhmetov/HMP-152 protocols fix #3165

Merged
merged 19 commits into from
Jul 21, 2023

Conversation

NickAkhmetov
Copy link
Collaborator

@NickAkhmetov NickAkhmetov commented Jul 11, 2023

  • Added handling for multiple protocols links in one field
  • Added logic for trimming/fixing the protocols links has been edited to handle all of the cases in protocols.io failure on some Donor pages #2925 except for the typo case where commas took the place of periods
  • Added specs for the trimming logic
  • Added client authentication to Protocols.io requests
  • Targeted the v4 API protocol API instead of the legacy v3 API (takes care of HMP-254)

@NickAkhmetov
Copy link
Collaborator Author

NickAkhmetov commented Jul 12, 2023

After taking some time to review the documentation for the protocols.io authorization, I can summarize it:

  • I have obtained a client ID, client secret, and client access token
    • The ID is safe to expose publicly
    • The client secret is not safe to expose publicly
    • The client access token is probably best not to expose publicly but would be visible in user-space if we made client-side requests with it
      • i.e. if the associated account has any private protocols shared with it, they are visible to requests made with this key.
  • We can make requests with either
    • with the client access token
      • Allows access to all publicly visible protocols and the protocols associated with the given account, as mentioned above, but does not provide access to private protocols
      • We would likely want to forward these requests through our back-end to avoid sending the client access token down in session information
    • with an OAuth key generated via an authorization link
      • User clicks the link, authenticates with protocols.io account, and gets redirected to a URL we specify with the auth code/scope in URL parameters
      • This allows the user to access any private protocols that are shared with them
      • This key is valid for up to a year
      • This requires us to pass the client secret so we'll need to make a python handler for this similar to the login handler

For a first pass, we can try just using the client auth key; we can build out OAuth support in a future iteration.

Base automatically changed from nickakhmetov/hmp-144-react-18-upgrade to main July 12, 2023 16:08
Logic for trimming/revising the links works
Corresponding specs are failing (`Cannot read properties of null (reading 'useMemo'`)
Also need to set up protocols API auth flow
@NickAkhmetov NickAkhmetov force-pushed the nickakhmetov/hmp-152-protocols-fix branch from 3ac9107 to aab15dd Compare July 12, 2023 16:09
@NickAkhmetov
Copy link
Collaborator Author

Rebased following the squash-merge of the base branch.

@NickAkhmetov
Copy link
Collaborator Author

Donor fde7ac63c666fdaebe21e187293a8685 on prod has multiple protocol links, which we can now properly display:

image

@NickAkhmetov NickAkhmetov marked this pull request as ready for review July 18, 2023 15:48
@NickAkhmetov NickAkhmetov requested review from lchoy, kevinyooky and john-conroy and removed request for kevinyooky July 18, 2023 15:48
@NickAkhmetov
Copy link
Collaborator Author

Zhou added the client ID entries to the various environments; once I fix the specs here this should be all set

john-conroy
john-conroy previously approved these changes Jul 21, 2023
Copy link
Collaborator

@john-conroy john-conroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I made a few comments that you can take or leave.

CHANGELOG-fix-protocol-links.md Outdated Show resolved Hide resolved
context/app/static/js/components/Providers.jsx Outdated Show resolved Hide resolved
Comment on lines 15 to 20
<SectionItem label="Error loading protocol info">
This protocol may be private or otherwise inaccessible.
</SectionItem>;
}
if (loading || !data) {
<SectionItem label="Loading protocol info">Please wait...</SectionItem>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tsliaw do you want to weigh in on the language used here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NickAkhmetov Yes that language should be changed. Please change to "Protocols are loading. If protocols take a significant time to load, please contact [email protected] about this issue and mention the HuBMAP ID." And add the email icon after the email. The styling of that loader might need to change in the future since it doesn't match the rest of the portal, but this should be sufficient for now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've modified the text accordingly:

image

I've also added handling to make sure that the loading message is only displayed once in cases where there's more than one protocol URL.

Comment on lines 2 to 19
export const multiFetcher = (...urls: string[]) => {
const f = (url: string) => fetch(url).then((response) => response.json());
if (urls.length === 0) {
return Promise.resolve([]);
}
return Promise.all(urls.map((url) => f(url)));
};

export const multiFetcherWithToken = (token: string, ...urls: string[]) => {
const f = (url: string) =>
fetch(url, {
headers: {
Authorization: `Bearer ${token}`,
},
}).then((response) => response.json());
if (urls.length === 0) {
return Promise.resolve([]);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we refactor out the commonalities and enable the multiFetcher to accept fetch options as a an arg with a default value of an empty obj?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • fetcher and multiFetcher moved to a single swr file in helpers
  • Both functions take in an optional requestInit object
  • fetcher uses multiFetcher to minimize duplication
  • Added JSDoc explanations for usage which appear on hover in VS Code

image

image

context/app/static/js/hooks/useProtocolData.js Outdated Show resolved Hide resolved
Copy link
Collaborator

@john-conroy john-conroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

@NickAkhmetov NickAkhmetov merged commit 3cc7b44 into main Jul 21, 2023
8 checks passed
@NickAkhmetov NickAkhmetov deleted the nickakhmetov/hmp-152-protocols-fix branch July 21, 2023 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants