Return-Path: 
 <dev-return-28514-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-dev-archive@www.apache.org
Delivered-To: apmail-cordova-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 2712810FCD
	for <apmail-cordova-dev-archive@www.apache.org>;
 Tue,  3 Dec 2013 19:57:54 +0000 (UTC)
Received: (qmail 64006 invoked by uid 500); 3 Dec 2013 19:57:53 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 63981 invoked by uid 500); 3 Dec 2013 19:57:53 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 63973 invoked by uid 99); 3 Dec 2013 19:57:53 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 19:57:53 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of tommy@devgeeks.org designates
 74.125.82.174 as permitted sender)
Received: from [74.125.82.174] (HELO mail-we0-f174.google.com) (74.125.82.174)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 19:57:47 +0000
Received: by mail-we0-f174.google.com with SMTP id q58so13924099wes.19
        for <dev@cordova.apache.org>; Tue, 03 Dec 2013 11:57:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:content-type;
        bh=am8jt5L4GuOI8x2HaW/KQB3iprXH3q7g+ogdwjTSWFo=;
        b=AC/IjpnCv1pf8jt7TbdGDJhLhgSFPyzt6dx8gaga+SdzgybqJ71BdCQRTK/ik0J4nT
         tWT7cngcA+G6wBMeW9F/Jqyk+dCX9Dm3kedqwSB5QEk3MS836+pK28VjYqGr+Cps6R1N
         74ookm2izXId8X006Og+9e1kQNBB838p5bMAnLynfWCf/E2+W1/Na9FCpPtB77yBuryD
         nHdwVcQi1fLkygh3Z5GHqPZNSAVgeQGNomXO9YG7ZiqPihb5zqYdCRgws6V83CEejOtX
         qKBMZTdkh66iqghho+JULlo8zvrByGtReH4JoKkeDBBBvfU7DzgMv9uzACFYc5tzbiQu
         WGjQ==
X-Gm-Message-State: 
 ALoCoQnHpcsTS7qE0uYf+woglV3QDzAARQyJbZKGOdwRT9ySU/G7BH4L2UiMfp6+XpvYNbbigyYc
MIME-Version: 1.0
X-Received: by 10.180.182.136 with SMTP id ee8mr4055590wic.19.1386100624801;
 Tue, 03 Dec 2013 11:57:04 -0800 (PST)
Received: by 10.180.36.35 with HTTP; Tue, 3 Dec 2013 11:57:04 -0800 (PST)
X-Originating-IP: [110.148.142.78]
Received: by 10.180.36.35 with HTTP; Tue, 3 Dec 2013 11:57:04 -0800 (PST)
In-Reply-To: 
 <CAEeF2TfCVnt+3zTA_v1vxVUFjt1AVLN1+hMVg4hFJxvjV6Yfiw@mail.gmail.com>
References: 
 <CAEeF2Te=RvLw+cUkYcwHo+dRKpYTpOyQYHLu2Ui+X7Kj-7z0xQ@mail.gmail.com>
	<CAMk5LL=qjaOghnPQ6oPyws3nZt4icbqEfo=wctbOoeFYS0nz7Q@mail.gmail.com>
	<CAEeF2TfCVnt+3zTA_v1vxVUFjt1AVLN1+hMVg4hFJxvjV6Yfiw@mail.gmail.com>
Date: Wed, 4 Dec 2013 06:57:04 +1100
Message-ID: 
 <CAPTyS6BxSMF4Ymp6H3Bc2=jJZOQcEBpM5VQxy38mG97Jkr5CYQ@mail.gmail.com>
Subject: Re: [android] How to remove the automatic default of <access
 origin="*"/>
From: Tommy Williams <tommy@devgeeks.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=089e016346b45d533904eca6b373
X-Virus-Checked: Checked by ClamAV on apache.org

--089e016346b45d533904eca6b373
Content-Type: text/plain; charset=ISO-8859-1

Please don't go back to when every new dev had to struggle with the Google
group or irc to find out why their ajax requests didn't work.

There was a huuuuge discussion at the time that we chose to default to *
On 04/12/2013 6:03 am, "Michal Mocny" <mmocny@chromium.org> wrote:

> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > There are two different files here: one is defaults.xml, which the CLI
> > takes as the basis for its platform config.xml. The other is the
> config.xml
> > that you get after running bin/create. In the CLI world, that second file
> > is immediately overwritten by one created from defaults.xml, the
> top-level
> > app config.xml, etc.
> >
>
> Okay, thats what I thought we were doing, but I cannot find where/how the
> defaults.xml is created in the first place.  I see now that it does exist
> in my CLI projects, but seems not to exist inside our platforms nor CLI,
> nor can I find the code that generates it.
>
>
> >
> > I support the second point of removing the <access origin="*" /> from the
> > CLI's hello world template app; it should be turned into a comment.
> >
>
> Seems this is redundant anyway given that the platforms provide this as a
> default.  Regarding leaving it in as a comment: should we embed the full
> spec as a comment?  If not, I would just leave a general description and
> link to the spec docs online.
>
>
> > I don't think we should be including <access origin="*" /> by default
> > anywhere, unless we really do want to disable the whitelist on that
> > platform. And if we do want to disable it, why not in the native code
> > instead of allowing everything by default?
> >
>
> I remember about a year ago we had a bunch of talks regarding the default
> whitelist, and decided that almost every developer doesn't want to use a
> whitelist and wants every request to be allowed by default.  For those few
> devs that want this (false?) sense of security they can learn how to
> opt-in, instead of having the same question on the user lists over and over
> about how to opt-out.
>
> Changing the platforms to allow * by default is an interesting idea, but I
> would rather see a solution that doesn't need that change.  Plus its a bit
> less semantic/declarative aka more magical/surprising.
>
>
> >
> > Braden
> >
> >
> > On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny <mmocny@google.com> wrote:
> >
> > > On ios, the default config.xml file (aka the platform defaults) is
> > bundled
> > > as part of the ios project template, and the project template is easy
> to
> > > override using flags to create script / CLI config options.  Easy,
> great.
> > >
> > > For android, the default config.xml file is bundled with the platform
> > > framework itself and not as part of the project template.  I assume
> this
> > is
> > > not easy to fix, otherwise we would have made the change already?
> > >
> > > Since the <access> tag is additive (i.e. cannot just override it by
> > > appending), there is no way to remove that default without reaching in
> > and
> > > editing cordova-android/framework/res/xml/config.xml file directly
> > (either
> > > with a custom post-platform-add hook to run sed, or by forking
> > > cordova-android to change the default, both shitty options imho).
> > >
> > > Any suggestions on how to fix this?
> > >
> > > I was hoping to propose that we move the tag out of all the platform
> > > templates and instead add it to the hello-world app template -- but I
> > think
> > > that won't work well with the platform-scripts workflow since that flow
> > > doesn't use an application level config.xml at all right now.
> > >
> > >
> > > Second, related issue: cordova-cli bundles a default application
> > config.xml
> > > file, which also includes <access origin="*"/>.  I think this is just
> > > unnecessary and should be removed.
> > >
> > >
> > > -Michal
> > >
> > > p.s. as an aside, I thought we were moving the default platform
> > config.xml
> > > out into a file called "defaults.xml"?  It seems only the good folks at
> > > blackberry have done that so far..
> > >
> >
>

--089e016346b45d533904eca6b373--