You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cordova.apache.org by "Shazron Abdullah (JIRA)" <ji...@apache.org> on 2016/09/29 20:46:20 UTC
[jira] [Comment Edited] (CB-11440) iOS: Remove default: disabled
NSAppTransportSecurity - soon required by Apple
[ https://issues.apache.org/jira/browse/CB-11440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15534001#comment-15534001 ]
Shazron Abdullah edited comment on CB-11440 at 9/29/16 8:46 PM:
----------------------------------------------------------------
More clarification, straight from an Apple DTS engineer: https://forums.developer.apple.com/thread/48979#146140
Nothing has been disabled, but you will have to justify why you need an exception. So, this is more like, do we want to force users to be more discriminatory about their <access> tags? Are we supposed to be a filter before they get the rejection?
If they get a rejection, they can update their <access> tags and re-submit. This is a hassle, however.
What I don't think is that we can be the police for enforcing this behaviour -- although the wildcard might *not* be allowed, it is allowed in other platforms besides iOS. I think the only thing we can do is print a warning if the wildcard is used.
So my suggestion (like what jcesarmobile said) is to document, and print a warning as well, if the wildcard is used. However, I think we should keep the access tag with the wildcard, so that the warning is always printed for a new project (as a nag).
I'll add these three new options in another issue:
NSAllowsArbitraryLoadsInWebContent
NSRequiresCertificateTransparency
NSAllowsLocalNetworking
was (Author: shazron):
More clarification, straight from an Apple DTS engineer: https://forums.developer.apple.com/thread/48979#146140
Nothing has been disabled, but you will have to justify why you need an exception. So, this is more like, do we want to force users to be more discriminatory about their <access> tags? Are we supposed to be a filter before they get the rejection?
If they get a rejection, they can update their <access> tags and re-submit. This is a hassle, however.
What I don't think is that we can be the police for enforcing this behaviour -- although "*" might *not* be allowed, it is allowed in other platforms besides iOS. I think the only thing we can do is print a warning if the wildcard is used.
So my suggestion (like what jcesarmobile said) is to document, and print a warning as well, if the wildcard is used. However, I think we should keep the access tag with the wildcard, so that the warning is always printed for a new project (as a nag).
I'll add these three new options in another issue:
NSAllowsArbitraryLoadsInWebContent
NSRequiresCertificateTransparency
NSAllowsLocalNetworking
> iOS: Remove default: disabled NSAppTransportSecurity - soon required by Apple
> ------------------------------------------------------------------------------
>
> Key: CB-11440
> URL: https://issues.apache.org/jira/browse/CB-11440
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
> Environment: cordova-ios 4.1.1
> Reporter: Michael Schmidt
> Assignee: Shazron Abdullah
> Priority: Blocker
> Labels: iOS, triaged
>
> iOS platform by default disables https:
> {code}
> <key>NSAppTransportSecurity</key>
> <dict>
> <key>NSAllowsArbitraryLoads</key>
> <true/>
> </dict>
> {code}
> Apple soon requires HTTPS:
> "Apple mandates App Store apps support ATS security protocol by 2017"
> http://appleinsider.com/articles/16/06/14/apple-mandates-app-store-apps-support-ats-security-protocol-by-2017
> --> remove this default from cordova ios platform
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org