Support credentials by josh · Pull Request #56 · JakeChampion/fetch ·

@dgraham

Incomplete.

I'm not sure how to support credentials: 'omit' with XHR.

Closes #43.

dgraham · 2015-01-06T00:35:21Z

test/test.js

@@ -196,3 +196,43 @@ promiseTest('supports HTTP DELETE', 2, function() {
 equal(request.data, '')
 })
 })
+
+promiseTest('doesnt send cookies with implicit omit credentials', 1, function() {


We need to default to "omit" in the Request constructor.

I wish the default was same-origin rather than omit. All of our fetch usage requires cookie headers.

Any ideas how to disable cookies for 'omit'? It seems like withCredentials is always ignored for same origin requests.

That feature does not exist in XMLHttpRequest. XMLHttpRequest only has same-origin and CORS.

I could be convinced to have the standard default to same-origin, but it seems rather ugly to have a different default from cross-origin. (Mistake with how we designed XMLHttpRequest...)

@annevk

@annevk it seems like the majority of fetch contexts (image, script, style, subresources) mostly use "include" even for cross origin resources with the exception of XHR's CORS semantics. I kinda agree that world would be a better place if stuff like script was actually omit by default. But for most direct fetch() api calls, I think I'll be using same-origin most the time.

Well they use include but also set mode to no-cors by default. If you use the crossorigin attribute I think the intent is omit and mode cors, though implementations might do same-origin and mode cors...

@annevk

I could be convinced to have the standard default to same-origin

@annevk From my perspective, a default of same-origin is most useful. A default of omit means that fetch cannot be used easily by sites with user sessions maintained by cookie headers.

A simple fetch('/some/url') call becomes fetch('/some/url', {credentials: 'same-origin'}) at each call site. I'd prefer to specify omit in the few cases it's needed instead.

For now, we've added a default of same-origin to the $.fetch wrapper we use on .com.

If you think it's appropriate, maybe the default in the specification could be changed to same-origin?

I recommend filing a bug against the specification. I don't really like same-origin myself as what it does depends on the origin of the URL you passed in, which is super weird.

Support credentials

@rwjblue

tl;dr - This commit add support for fetch. - pretender swap native fetch related API if exists - pretender.shutdown() restore native fetch related API - doesn't work with AbortController Pretender has been working well with xhr, but doesn't handle fetch. It's been 2 years since @rwjblue first open the [issue](pretenderjs#60) for fetch support. So people don't need to do extra work to polyfill for testing. Include a fetch ponyfill and swap the native fetch during pretender creation, then restore them when `shutdown`. Since fetch polyfill uses xhr behind the scene, pretender will "just work". Per Yetch homepage, the supplement set of yetch impl and spec include: - Inability to [set the redirect mode](JakeChampion/fetch#137) - Inability to [change the cache directive](JakeChampion/fetch#438 (comment)) - Inability to [disable same-origin cookies](JakeChampion/fetch#56 (comment)) - `xhr.abort()` first set state to done, finally response to a [network error](https://xhr.spec.whatwg.org/#the-abort()-method); - [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will reject promise with a new "AbortError" DOMException. For `fake_xml_http_request` impl, the request is resolved once its state is changed to `DONE` so the `reject` is not cathed. So the senario happens in pretender is: 1. state chagne to `DONE`, trigger resolve request 2. abort, trigger reject 3. xhr.onerror, trigger reject The first resolve wins, error thus not rejected but an empty request is resolved. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by nature.

@rwjblue

tl;dr - This commit add support for fetch. - pretender swap native fetch related API if exists - pretender.shutdown() restore native fetch related API - doesn't work with AbortController Motivation ------ Pretender has been working well with xhr, but doesn't handle fetch. It's been 2 years since @rwjblue first open the [issue](pretenderjs#60) for fetch support. So people don't need to do extra work to polyfill for testing. Changes ------ Include a fetch ponyfill and swap the native fetch during pretender creation, then restore them when `shutdown`. Since fetch polyfill uses xhr behind the scene, pretender should "just work". Caveats ------ 1. The supplement set of yetch impl and spec includes (not complete): - Inability to [set the redirect mode](JakeChampion/fetch#137) - Inability to [change the cache directive](JakeChampion/fetch#438 (comment)) - Inability to [disable same-origin cookies](JakeChampion/fetch#56 (comment)) 2. Abort - `xhr.abort()` first set state to done, finally response to a [network error](https://xhr.spec.whatwg.org/#the-abort()-method); - [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will reject promise with a new "AbortError" DOMException. As implemented in `fake_xml_http_request`, the request is resolved once its state is changed to `DONE`. So the senario happens in pretender is: 1). state chagne to `DONE`, trigger resolve request 2). abort, trigger reject 3). xhr.onerror, trigger reject The first resolve wins, error thus not rejected but an empty request is resolved. 3. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by nature.

@rwjblue

tl;dr - This commit adds support for fetch. - pretender swap native fetch related API if exists - pretender.shutdown() restore native fetch related API - doesn't work with AbortController Motivation ------ Pretender has been working well with xhr, but doesn't handle fetch. It's been 2 years since @rwjblue first open the [issue](pretenderjs#60) for fetch support. So people don't need to do extra work to polyfill for testing. Changes ------ Include a fetch ponyfill and swap the native fetch during pretender creation, then restore them when `shutdown`. Since fetch polyfill uses xhr behind the scene, pretender should "just work". Caveats ------ 1. The supplement set of yetch impl and spec includes (not complete): - Inability to [set the redirect mode](JakeChampion/fetch#137) - Inability to [change the cache directive](JakeChampion/fetch#438 (comment)) - Inability to [disable same-origin cookies](JakeChampion/fetch#56 (comment)) 2. Abort - `xhr.abort()` first set state to done, finally response to a [network error](https://xhr.spec.whatwg.org/#the-abort()-method); - [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will reject promise with a new "AbortError" DOMException. As implemented in `fake_xml_http_request`, the request is resolved once its state is changed to `DONE`. So the senario happens in pretender is: 1). state changes to `DONE`, trigger resolve request 2). abort, trigger reject 3). xhr.onerror, trigger reject The first resolve wins, error thus not rejected but an empty request is resolved. 3. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by nature.

tl;dr - This commit adds support for fetch, fix pretenderjs#60. - pretender swap native fetch related API if exists - pretender.shutdown() restore native fetch related API - doesn't work with AbortController Changes ------ Include a fetch ponyfill and swap the native fetch during pretender creation, then restore them when `shutdown`. Since fetch polyfill uses xhr behind the scene, pretender should "just work". Caveats ------ 1. The supplement set of yetch impl and spec includes (not complete): - Inability to [set the redirect mode](JakeChampion/fetch#137) - Inability to [change the cache directive](JakeChampion/fetch#438 (comment)) - Inability to [disable same-origin cookies](JakeChampion/fetch#56 (comment)) 2. Abort - `xhr.abort()` first set state to done, finally response to a [network error](https://xhr.spec.whatwg.org/#the-abort()-method); - [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will reject promise with a new "AbortError" DOMException. As implemented in `fake_xml_http_request`, the request is resolved once its state is changed to `DONE`. So the scenario happens in pretender is: 1). state changes to `DONE`, trigger resolve request 2). abort, trigger reject 3). xhr.onerror, trigger reject The first resolve wins, error thus not rejected but an empty request is resolved. 3. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by nature.

Test credentials options

68d86d0

dgraham reviewed Jan 6, 2015
View reviewed changes

josh added 2 commits January 5, 2015 19:13

No contraction

af17642

Default credentials to 'omit'

1bbe6f0

Merge branch 'master' into test-cookies

33d47f4

josh added a commit that referenced this pull request Jan 11, 2015
Merge pull request #56 from /test-cookies

6617c40
Support credentials

josh merged commit 6617c40 into master Jan 11, 2015

josh deleted the test-cookies branch January 11, 2015 03:15

mislav mentioned this pull request May 16, 2015
Unclear about how to deal with cookies #142
Closed

chalisegrogan mentioned this pull request Jun 13, 2016
Cookie not set in Request Headers, even with 'same-origin' credentials. #349
Closed

Mouvedia mentioned this pull request Dec 25, 2016
Allow * for Access-Control-Expose-Headers whatwg/fetch#252
Closed

xg-wang mentioned this pull request May 23, 2018
fetch support pretenderjs/pretender#230
Merged

-actions bot locked as resolved and limited conversation to collaborators Oct 1, 2020

ppichate2531 referenced this pull request in ppichate2531/css Mar 12, 2021
Initial commit

e51904c

Uh oh!

Uh oh!

dgraham Jan 6, 2015

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Conversation

Uh oh!

dgraham Jan 6, 2015

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!