[
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: [email protected]
For additional commands, e-mail: [email protected]
