cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shazron Abdullah (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CB-11440) iOS: Remove default: disabled NSAppTransportSecurity - soon required by Apple
Date Thu, 29 Sep 2016 20:46:20 GMT

    [ 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


Mime
View raw message