-
Notifications
You must be signed in to change notification settings - Fork 121
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
Secure token in POST body or auth header #697
Conversation
Codecov Report
@@ Coverage Diff @@
## master #697 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 108 108
Lines 1637 1644 +7
Branches 291 293 +2
=========================================
+ Hits 1637 1644 +7
Continue to review full report at Codecov.
|
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.
Thanks @ssylvia
I really like the idea of secureToken
as you've designed it.
I'm less sure about fetchMode
b/c I'm wary of exposing yet another fetch option via IRequestOptions
. What is fetch's default mode
? If it's not no-cors
then couldn't we do this w/o adding fetchMode
? People have the option of passing custom fetch
so if they want to specify no-cors
mode they could use that, right?
I'd also like @patrickarlt to have eyes on this.
@@ -14,6 +15,10 @@ export interface IRequestOptions { | |||
* The HTTP method to send the request with. | |||
*/ | |||
httpMethod?: HTTPMethods; | |||
/** | |||
* The fetch mode to send the request with. |
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.
Let's add link to some docs on this, maybe https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Syntax
/** | ||
* Fetch mode used by the ArcGIS REST API. | ||
*/ | ||
export type FetchMode = "cors" | "no-cors" | "same-origin"; |
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 if we need a type for this. Can we just put the string union inline in IRequestOptions
for now?
// Mixin headers from request options | ||
fetchOptions.headers = { | ||
...options.headers | ||
}; | ||
|
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'm not sure we should move this above the blocks below. I know why you did, but I think if someone passes in an X-Esri-Authorization
as well as secureToken
, then that should trump what we generate.
expect(url).toEqual( | ||
"https://www.arcgis.com/sharing/rest/content/items/43a8e51789044d9480a20089a84129ad/data" | ||
); | ||
expect(options.body).toContain("token=token"); |
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.
should we also expect the method to be POST
?
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.
This is great @ssylvia.
I have a slight preference for my suggestion below, but let me know what you think.
I've asked the others to weigh in on this PR, if I don't hear vocal opposition we'll get this merged and released tomorrow.
// Add token back to body with other params instead of header | ||
if (token.length && options.secureToken) { | ||
params.token = token; | ||
delete requestHeaders["X-Esri-Authorization"]; | ||
} |
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 think you are right to move the token out of the header and into the body if we have to use POST.
I only wonder if we should check for the existence of the token in the header rather than the re-check the criteria for putting it there.
// Add token back to body with other params instead of header | |
if (token.length && options.secureToken) { | |
params.token = token; | |
delete requestHeaders["X-Esri-Authorization"]; | |
} | |
const headerToken = requestHeaders["X-Esri-Authorization"]; | |
if (headerToken) { | |
// Add token back to body with other params instead of header | |
params.token = headerToken; | |
delete requestHeaders["X-Esri-Authorization"]; | |
} |
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.
@tomwayson We can do that but it will get more complicated. When passed as a header, the value is different. It's actually Bearer ${token}
. Thought it would be better to use our original which we know is not modified elsewhere.
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.
let's leave it as is
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.
This looks good to me. I am a little concerned that secureToken
implies that tokens are insecure in other contexts. I'm not entirely sure what to rename it to however.
Thanks @patrickarlt Some name ideas:
|
hideToken? |
I'm curious, why was the choice made to only put the token into the header for a GET and not a POST too (for consistency if anything)? |
Adds two option to the IRequestOption:
fetchMode
: specify the mode to fetch with (cors, no-cors, etc)secureToken
: hides the token ofGET
request inX-Esri-Authorization
header.Both options are disabled by default. This could become the default at a major release.
Fixes: #557