-
Notifications
You must be signed in to change notification settings - Fork 225
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
EDSC-3930: Fixing issue on EDSC #1698
Conversation
|
||
// Handle EDD redirects | ||
if (eddRedirectUrl) { | ||
const validEddRedirect = eddRedirectUrl.startsWith('earthdata-download') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be better to do an exact match on the url just in case we use "earthdata-download" in a url sometime down the line. Seems safer to be a little more specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little confused about what you mean for the exact matching. We wouldn't know what the eddRedirectUrl
value would be only its prefix at runtime of this module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For instance one value I see in testing with downloading a collection where EDL auth was required is earthdata-download://authCallback?fileId=3&ee=prod&token=<my-token>
I'm not sure we know what the fileId
is going to be or really that the token
matches whatever token we have saved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea so the fileId
coming from EDD
is The authUrl will have a
fileId parameter appended to it, which is the file ID of the file that triggered the authentication workflow
console.log('The redirectUrl is not a valid protocol') | ||
window.location.replace('/') | ||
let eddRedirectUrl = eddRedirect | ||
if (redirect.includes('earthdata-download')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be better to do an exact match on the url just in case we use "earthdata-download" in a url sometime down the line. Seems safer to be a little more specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One possibility is moving the test on line 53 with startsWith
up here, which would mean only valid EDD redirects get processed by the following if
block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rushgeo We could check if it starts with up there for redirect
but, we still need to have a startsWith
check in case the eddRedirectUrl
has been initialized to the value of the eddRedirect
. I used includes
because that was previous logic.
if (invalidRedirectUrl) { | ||
// Redirect to an error page or a safe location if the URL is not a relative path | ||
// https://developer.mozilla.org/en-US/docs/Web/API/Location/replace assign prevents back-button use in history | ||
window.location.replace('/') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we could send the user to the standard error page here. I think a "replace" makes more sense than a "assign" here.
|
||
if ( | ||
redirectUrl | ||
&& redirectUrl.protocol !== 'http:' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like we lost where were checking for the allowed protocols. Is that intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea that is intentional. The protocol check doesn't sufficiently cover the strictness we need to properly handle url redirects. Here we are now only allowing redirects to addresses relative to EDSC or earthdata-download
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1698 +/- ##
=======================================
Coverage 91.93% 91.94%
=======================================
Files 725 725
Lines 19349 19347 -2
Branches 4562 4558 -4
=======================================
Hits 17789 17789
+ Misses 1424 1422 -2
Partials 136 136 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than Trevor and I's comments on includes('earthdata-download')
, it looks good to me.
console.log('The redirectUrl is not a valid protocol') | ||
window.location.replace('/') | ||
let eddRedirectUrl = eddRedirect | ||
if (redirect.includes('earthdata-download')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One possibility is moving the test on line 53 with startsWith
up here, which would mean only valid EDD redirects get processed by the following if
block
…age instead of home
a82b6ba
to
15b636e
Compare
expect(window.location.replace.mock.calls[0]).toEqual(['/not-found']) | ||
}) | ||
|
||
test('does not follow the eddRedirect it is not a valid earthdata-download redirect', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know that this test is really very helpful. its very similar to the test below it and running though the same code. I added it for explicitness when it comes to what solution this PR is trying to do but, I'll pull it out if people deem to totally redundant
Overview
What is the feature?
Fix an issue on EDSC (Further info in the Teams file on this issue) this has been left purposefully vague
What is the Solution?
Altered parsing of redirect urls for strictness
Regression testing was done locally to ensure that we could still be redirected from EDD to URS and to the EULA page using the prod collection
C1214470488-ASF
with a profile that had not accepted any EulasWe can check
C2202497474-LPCLOUD
collection to ensure that EDD redirects through URS are getting sent as expectedWhat areas of the application does this impact?
List impacted areas.
EDD redirects
EDL redirects
Reproduction steps
(Further info in the Teams file on this issue) this has been left purposefully vague
Attachments
N/A
Checklist