Skip to content

added cookie headers to websocket and XMLHttpRequest - #7167

Closed
clozr wants to merge 2532 commits into
react:masterfrom
clozr:master
Closed

added cookie headers to websocket and XMLHttpRequest#7167
clozr wants to merge 2532 commits into
react:masterfrom
clozr:master

Conversation

@clozr

Copy link
Copy Markdown

web socket connect doesn’t retrieve and set HTTP cookies automatically. Manual approach is to retrieve the cookie through a cookie manager plugin and pass it as headers to web socket. This may cause problems in integrating some library which abstract out web socket transport.

@facebook-github-bot

Copy link
Copy Markdown
Contributor

By analyzing the blame information on this pull request, we identified @philikon and @nicklockwood to be potential reviewers.

@facebook-github-bot

Copy link
Copy Markdown
Contributor

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

@facebook-github-bot

Copy link
Copy Markdown
Contributor

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@facebook-github-botfacebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Apr 23, 2016
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:URL];

// We load cookies from sharedHTTPCookieStorage (shared with XHR and
// fetch). To get HTTPS-only cookies for wss URLs, replace wss with https

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe say "secure" cookies instead of HTTPS-only because "http-only" means something different for cookies

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Good point. I will update the description

@ide

ide commented Apr 23, 2016

Copy link
Copy Markdown
Contributor

This looks mostly good to me -- just a couple small comments.

We're working to get the CI testing back in a good state so it might be a few days before we feel more confident merging this but thank you for the PR!

@facebook-github-bot

Copy link
Copy Markdown
Contributor

@clozr updated the pull request.

1 similar comment
@facebook-github-bot

Copy link
Copy Markdown
Contributor

@clozr updated the pull request.

@clozrclozr changed the title added cookie headers to websocket requestsadded cookie headers to websocket and XMLHttpRequestApr 23, 2016
@clozr

clozr commented Apr 23, 2016

Copy link
Copy Markdown
Author

Added the same code to XMLHttpRequest as well

@facebook-github-bot

Copy link
Copy Markdown
Contributor

@clozr updated the pull request.

1 similar comment
@facebook-github-bot

Copy link
Copy Markdown
Contributor

@clozr updated the pull request.

@jsierles

Copy link
Copy Markdown
Contributor

@ide CI is green now. OK to merge this? Do we need a test plan?


// Load and set the cookie header.
NSArray<NSHTTPCookie *> *cookies = [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookiesForURL:URL];
request.allHTTPHeaderFields = [NSHTTPCookie requestHeaderFieldsWithCookies:cookies];

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

NSURLSession normally sends cookies automatically unless told not to. Are you sure this is necessary?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

RCTNetworking is using NSURLSession while Websocket is using NSURLConnection. So it may not be necessary for RCTNetworking. However currently NSURL session is initialized with default configuration, without specifying HTTPCookieAcceptPolicy, HTTPCookieStorage and HTTPShouldSetCookies. I can make the changes and test it out if you want to go that route.
I think that would be a better approach too.

On the other for Websocket, we may need to do this.

@nicklockwood

Copy link
Copy Markdown
Contributor

It would be great if you could include some test code for this - perhaps an example in UIExplorer?

@ide

ide commented May 3, 2016

Copy link
Copy Markdown
Contributor

It's a good idea to include a test plan even if you don't have unit tests so that the next person who works on this code can figure out how to test that they didn't break something.

@clozr

clozr commented May 4, 2016

Copy link
Copy Markdown
Author

Let me take a look on the existing test cases for RCTNetworking and Websocket and then I can add one for this change.

@ghost

Copy link
Copy Markdown

@nicklockwood would you mind taking a look at this pull request? It's been a while since the last commit was reviewed.

@clozr

Copy link
Copy Markdown
Author

Thanks for reminding Nick. I have the NSURLSession based changes ready and tested in my local build. I will update the pull request today.

@jellevandenhooff

jellevandenhooff commented May 19, 2016

Copy link
Copy Markdown

The websocket code already sends cookies (see https://github.com/facebook/react-native/blob/master/Libraries/WebSocket/RCTSRWebSocket.m#L308). Does that not work?

It seems the code in this PR's version of Libraries/WebSocket/RCTWebSocketModule.m copies over the code from Libraries/WebSocket/RCTSRWebSocket.m. Is the new location better? Should the code in the old location be removed?

@jellevandenhooff

Copy link
Copy Markdown

Ah. I see. The code I linked on master does not currently get called, so sending cookies on master is likely broken.

Commit 205b5d4 changed the code in RCTWebSocketModule.m to use initWithURLRequest instead of initWithURL (both in RCTSRWebSocket.m), and only initWithURL sets a cookie.

I would like to see this PR remove the unused initWith... functions to prevent this problem in the future. When I initially added support for sending cookies, I did not any automated tests because, well, I didn't really have a clue how to. I would love to see this PR add tests to make sure cookies keep working, but that might be hard.

littlesomeand others added 16 commits October 26, 2016 16:16
Summary:
1. Using weak container to hold the currently opened alerts.
2. Using weak reference to alertController in action handler block.
3. BTW, remove the unused vars: _alertCallbacks, _alertButtonKeys.
Test plan (required)
```
- (void)invalidate
{
for (UIAlertController *alertController in _alertControllers) {
[alertController.presentingViewController dismissViewControllerAnimated:YES completion:nil];
}
}
```
Since we use weak container, _alertControllers should only contains the currently opened alerts.
I test this way: Put a breakpoint in invalidate, open the UIExplorer play with the 'Alert' & 'AlertIOS' examples, then fire a reload and see if _alertControllers contains the expected values.
Closes#10407
Differential Revision: D4078649
Pulled By: lacker
fbshipit-source-id: 8509e7e7142379a81d5b28c9067c085bad8bb5cb
Summary:
Small contribution for MacOS users:
For those users who using zsh with their Mac OS filename to place variables should be different
Closes#10432
Differential Revision: D4078102
Pulled By: lacker
fbshipit-source-id: 6cbfb81a472f37bfda85964e929c99b438348fd8
Summary:
Update integrating with existing Swift App code for Swift 3.
Closes#10547
Differential Revision: D4079631
Pulled By: lacker
fbshipit-source-id: 7a493ca7131a10a2466816b104b9cb4f1ff369f5
Summary:
In the `NetworkingModule.java`, `header.getString(1)` was
called, so the value must be String type.
FIX#10198Closes#10222
Differential Revision: D4080319
Pulled By: lacker
fbshipit-source-id: 85234a2bbf90e5b9e0e65ceadbfabb330b2d1322
Summary:
Fixes#9485Closes#9516
Differential Revision: D4080618
Pulled By: lacker
fbshipit-source-id: 296c209a0438c4a06b3b3556d7084c5435d60c72
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
See #10506. A native `NSError` with `NSUnderlyingErrorKey` set causes a JSON stringify error from the websocket dispatcher if remote debugging is enabled.
**Test plan (required)**
I'm not familiar with the react native testing framework. Happy to add a test for this if someone can point me to where this part of the codebase is exercised :)
I did some spot checks with nil user dictionaries and nil underlying errors here. The case that this solves is testable using https://github.com/superseriouscompany/react-native-error-repro, specifically:
```objective-c
NSError *underlyingError = [NSError errorWithDomain:@"underlyingDomain" code:421 userInfo:nil];
NSError *err = [NSError errorWithDomain:@"domain" code:68 userInfo:@{@"NSUnderlyingError": underlyingError}];
reject(@"foo", @"bar", err);
```
Closes#10507
Differential Revision: D4080802
Pulled By: lacker
fbshipit-source-id: 93a41d9e9a710e406a6ccac214a5617271b4bede
…position was set
Differential Revision: D4080909
fbshipit-source-id: 7eb1885c615191055aa21e3435c6fbc652b883ae
Summary:
* Motivation
Locally I'm seeing consistent failures in IntegrationTests/TimersTest.js. Adding a little delay before starting the first test seems to make these issues go away.
Closes#10548
Differential Revision: D4080920
Pulled By: bestander
fbshipit-source-id: 2dec86073786658f24b809284123815e77fbbd99
Summary:
**Motivation**
I'm working on a project that uses React Native and needs to add direct synchronous bindings to native stuff through the JavaScriptCore C API. This is because it's performance-sensitive and would benefit from the quickest JS->C path. It does this using cross-platform C++ code that works on both iOS and Android. Most of the infrastructure for getting access to the JSC context is already in React Native actually, just had to add a few more things.
(lexs you mentioned to tag you in this pull request)
**Test plan**
Modify the JavaScriptCore context through the `JSContextRef` returned (eg. add an object at global scope) and verify that it exists in JavaScript.
Closes#10399
Differential Revision: D4080945
Pulled By: lexs
fbshipit-source-id: 6659b7a01e09fd84475adde183c1d3aca2d4cf09
Differential Revision: D4081049
fbshipit-source-id: 0b9ad70339ad906ad5219ad2679329cfe2fd7abc
Reviewed By: javache
Differential Revision: D4075622
fbshipit-source-id: 4a6b6c4068d762dce2b1535bfd9630e185f5489f
Summary:
Followup for #5822, addressing nits.
**Test Plan**
Travis CI (the author of #5822 tested the change).
Closes#10563
Differential Revision: D4081826
fbshipit-source-id: f3a2e1996bf02f81fecea6e53fe1c522b8c85689
Summary:
Simple documentation errata.
Closes#10098
Differential Revision: D4082724
Pulled By: lacker
fbshipit-source-id: 5b4df66472b37b643ced62fafefe461c0c2c86c7
Summary:
Currently there is a typo in Accessibility.md which will result in an invalid prop type warning if directly adhered to. The instance of `no-hide-descendant` should instead be updated to `no-hide-descendants` (plural) in the documentation.
Closes#10566
Differential Revision: D4082750
Pulled By: lacker
fbshipit-source-id: 18e2d9db6004767903e9308a2c0a900d2d9055fc
Reviewed By: emilsjolander
Differential Revision: D4081779
fbshipit-source-id: 4e2a1780738423396111c7cfde2fe12010ad0e93
Reviewed By: emilsjolander
Differential Revision: D4081788
fbshipit-source-id: 91da6af0fff1317ff4661572e8e7c1cc5594f810
@clozr

Copy link
Copy Markdown
Author

This pull request got messed up so I created another one.
Please see
#10575

@lackerlacker closed this Oct 27, 2016
facebook-github-bot pushed a commit that referenced this pull request May 24, 2017
Summary:
Continuation of Pull Request #7167#7167
Needed to clean my repository. So created this Pull Request
Closes#10575
Differential Revision: D4955291
Pulled By: shergin
fbshipit-source-id: 94b9a086b7cf70ee6cc152d0b1a36c260140450e
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA SignedThis label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

20 participants

@clozr@facebook-github-bot@ide@jsierles@nicklockwood@jellevandenhooff@jkbailey@mkonicek@travishaagen@lacker@javache@alwx@timcreasy@dinhvh@jeffmo@andy9775@yungsters@foghina@ncuillery@frantic