React-native-code-push: What are all the possible domains CodePush may make requests to?

[almirfilho]

In order to submit an iOS app to Apple's App Store, and to keep it as secure as possible, we have to define the NSAppTransportSecurity inside _Info.plist_ file, in which we can define a list of all the domains the app can make HTTP request to – otherwise iOS is just going to block the requests to unspecified domains. I know that just setting NSAllowsArbitraryLoads key to __true__ enables your app to make requests for any domain, but since it decreases security, it's not a good option (and you'll have to justify it to Apple during the app review process).

Doing a little research I've stumbled upon these two domains:

• __codepush.azurewebsites.net__ (REST API endpoint)
  
  
  
  • Codepush uses this endpoint to check for updates from inside the app.
  
  
• __codepushupdates.azureedge.net__ (CDN for the uploaded bundles)
  
  
  
  • Codepush uses this endpoint to download new updates (bundles) from.
  
  

Questions:

1. Are these domains correct?
2. Are there more?

Thank you for the awesome service and package! =D

[max-mironov]

Hello @almirfilho, thank you for your question and for your kind words :)

I believe the following domains should be added (taken from here):

<access origin="https://codepush.azurewebsites.net" />
<access origin="https://codepush.blob.core.windows.net" />
<access origin="https://codepushupdates.azureedge.net" />

Please let us know if it answers your question.

[almirfilho]

Thank you very much @max-mironov, I'll test it and return to this issue in the case it does not work.
Closing this issue.

P.S.: Don't you think it's worth mentioning this in the Docs?

[chirag04]

@almirfilho can you send a PR to add this to the docs?

[almirfilho]

PR sent =)
https://github.com/Microsoft/react-native-code-push/pull/830

[uripre]

@almirfilho I saw your contribution in the docs, thank you for that.

However, I don't think the scenario you described requires anyone to customize ATS for CodePush's domains. Could you maybe help me understand your reasoning?

I presume those requests follow proper SSL standards and therefore should have no problem with regular ATS restrictions. The only reason I can think of is if someone decided to disable ATS altogether, and then would like to reactivate ATS for CodePush's domains, but that doesn't seem to be the scenario you described above. In the general recommended case you described where NSAllowsArbitraryLoads is false - I don't think anyone need to customize anything.

If you could help me clarify this point - maybe I'm missing something, and I will surely try improve the docs accordingly. Thanks!!!

[almirfilho]

You’re right. I was still new to RN/XCode at the time. I realized some time
after this config was not required. I guess it can be removed from the docs
with no problems.

On Tue, Nov 24, 2020 at 12:59 uripre [e-mail] wrote:

@almirfilho https://github.com/almirfilho I saw your contribution in
the docs, thank you for that.

However, I don't think the scenario you described requires anyone to
customize ATS for CodePush's domains. Could you maybe help me understand
your reasoning?

I presume those requests follow proper SSL standards and therefore should
have no problem with regular ATS restrictions. The only reason I can think
of is if someone decided to disable ATS altogether, and then would like to
reactivate ATS for CodePush's domains, but that doesn't seem to be the
scenario you described above. In the general recommended case you described
where NSAllowsArbitraryLoads is false - I don't think anyone need to
customize anything.

If you could help me clarify this point, I will surely try improve the
docs accordingly. Thanks!!!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/react-native-code-push/issues/825#issuecomment-733281511,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEB6HWGTCUATAHIBR6MFNTSRQ3EXANCNFSM4DKAQDOQ
.

>

Almir Filho

Software Engineer