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

Use HTTPS for the packager server #15597

Closed
jankalfus opened this issue Aug 22, 2017 · 6 comments
Closed

Use HTTPS for the packager server #15597

jankalfus opened this issue Aug 22, 2017 · 6 comments
Labels
Ran Commands One of our bots successfully processed a command. Resolution: Locked This issue was locked by the bot.

Comments

@jankalfus
Copy link
Contributor

jankalfus commented Aug 22, 2017

When developing for iOS on a real device, you might have to set an IP address of your Mac in the RCTWebSocketExecutor.m file, instead of using localhost, otherwise you're not able to connect to it. I don't know if this is caused by strict policy of those who manage Wi-Fi in the offices or whatever, but it doesn't matter.

The main issue here is that the packager is using HTTP, not HTTPS and ATS policy on iOS disallows any insecure traffic for anything that's not localhost. Also, Apple doesn't allow you to create an exception in the Info.plist file for an IP address, only domain. So you have to use some cumbersome workaround like this one: https://stackoverflow.com/a/45798216/3979621

Please consider switching to HTTPS. It took me half a day to get around this problem, and I'm sure I'm not the only one.

@tabrindle
Copy link
Contributor

My understanding is that in debug mode, when building your IP is detected and an NSAppTransportSecurity:NSExceptionDomains rule is added for your IP using xip.io which is how they get around the IP address rule.

$PLISTBUDDY -c "Add NSAppTransportSecurity:NSExceptionDomains:$IP:NSTemporaryExceptionAllowsInsecureHTTPLoads bool true" "$PLIST"

Maybe something has changed that this is no longer working?

What version of xcode and iOS are you building with? If you are on react-native 0.47.2 or greater you can call react-native info or do the same thing with npm i -g envinfo && envinfo

I don't know how feasible it is to generate self signed certs locally during the build process, and accept them on the device, or how necessary the extra security is for development. That is certainly up for debate.

@jankalfus
Copy link
Contributor Author

jankalfus commented Aug 23, 2017

Ah, I see :) The problem is with this line:

IP=$(ipconfig getifaddr en0)

As my Mac Mini is connected both by a wire and wirelessly, the en0 interface is my ethernet connection, while Wi-Fi is sitting at en1.

So I guess this is a bug in the script? Maybe the networksetup -listallhardwareports command could be used to detect which interface is Wi-Fi?

BTW Here's the environment info:

  OS:  macOS Sierra 10.12.6
  Node:  8.2.1
  Yarn:  0.27.5
  npm:  5.3.0
  Watchman:  4.7.0
  Xcode:  Xcode 8.3.3 Build version 8E3004b

@tabrindle
Copy link
Contributor

Indeed this may be a problem in edge cases like yours - I don't think most of us have both connected. It appears the packager gets the WiFi IP, and this script is grabbing the LAN IP.

From some research I did, looks like en0 and en1 maybe either WiFi or LAN depending on mac model. We might be better off trying to add both IPs to NSAppTransportSecurity:NSExceptionDomains, unless we can determine which is which.

Another question is does the packager connect when only connected to LAN? I believe this has worked for me before, assuming they are on the same network.

Maybe a printout of your ifconfig might help track this down?

Alternate theory: is both LAN and WiFi connection necessary? We might just be able to document that this isn't supported rather than changing the script.

@jankalfus
Copy link
Contributor Author

The thing is that Wi-Fi and LAN are completely different networks in my case. I use LAN to connect to the company network, while I use Wi-Fi only for the packager (there's no access to the corporate network via Wi-Fi). That's why I need to use both.

I'm sure this is not a common use case, but I still think this should be fixed. I like your suggestion about adding both IPs to the exception list :)

@pull-bot
Copy link

@facebook-github-bot no-template

@facebook-github-bot
Copy link
Contributor

Hey, thanks for reporting this issue! It looks like your description is missing some necessary information, or the list of reproduction steps is not complete. Can you please add all the details specified in the Issue Template? This is necessary for people to be able to understand and reproduce the issue being reported. I am going to close this, but feel free to open a new issue with the additional information provided. Thanks! See "What to Expect from Maintainers" to learn more.

@facebook-github-bot facebook-github-bot added the Ran Commands One of our bots successfully processed a command. label Oct 10, 2017
@facebook facebook locked as resolved and limited conversation to collaborators Oct 10, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Oct 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Ran Commands One of our bots successfully processed a command. Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

5 participants