Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of braden@google.com designates
 209.85.214.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEeF2Tfh1b=hi3MaLMOzYaO1GAVw1WkN2dhB29CHmuP4qXrYXg@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>
	<CAPTyS6BxSMF4Ymp6H3Bc2=jJZOQcEBpM5VQxy38mG97Jkr5CYQ@mail.gmail.com>
	<CAEeF2Tf7-+HnCd+Rnmuy+gdD5oW5rVMUXSduOrb7=Y04_DfH5g@mail.gmail.com>
	<2266FED4-4870-4832-A00A-401BCEA4A921@devgeeks.org>
	<CABiQX1XNiQp8bPAGzw_84u-YWr4vXmj88VSS7Q7JMY2CJEw_7A@mail.gmail.com>
	<CAEeF2Tfh1b=hi3MaLMOzYaO1GAVw1WkN2dhB29CHmuP4qXrYXg@mail.gmail.com>
Date: Wed, 4 Dec 2013 10:43:58 -0800
Message-ID: 
 <CAMk5LL=z5QNfmTBNBhKKnmuQeV2JqhGrc6xzF2eZbJYOi0rk=A@mail.gmail.com>
Subject: Re: [android] How to remove the automatic default of <access
 origin="*"/>
From: Braden Shepherdson <braden@google.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=485b395db092c1385204ecb9cb80

--485b395db092c1385204ecb9cb80
Content-Type: text/plain; charset=ISO-8859-1

It's possible I'm misunderstanding something here, but the flow you
described here is exactly the one we intended when designing how
details.xml was going to work. Platforms ship both files, cli uses
defaults.xml where available, and config.xml where not. Platform scripts
use config.xml always.

I don't think any (many?) Changes to the tools will be necessary to support
this.

Braden
On Dec 4, 2013 8:25 AM, "Michal Mocny" <mmocny@chromium.org> wrote:

> Alright,  Andrew and I discussed this and think we have a resolution that
> works with all the use cases (yay for options).
>
> TLDR; I think we already (accidentally?) support using a different default
> platform config file for each of our two workflows.  This means we can have
> the <access origin="*"> tag live inside the platform config for
> platform-centric workflow, and inside the app config for app-centric
> workflow.  This means users less surprise for end users, and downstream
> distributions can more sensibly override these types of defaults should
> they chose to.
>
> ----
>
> Most platforms don't ship with a defaults.xml file yet (except for BB;
> because Jeff did this work, he followed through for that platform).  There
> are open bugs to add these (ie, CB-5047).
>
> Jeff also added a nice fallback to the CLI: if there does not exist a
> defaults.xml when running "prepare", backup the initial config.xml to a
> defaults.xml file before we go messing everything up with plugin / app
> settings.  Effectively the config.xml that ships with platforms is the
> defaults.xml for platforms that don't have one explicitly added.  This is a
> great default.
>
> However, if there actually were a defaults.xml, the CLI would consume that
> for its initial input in the prepare process, and completely ignore the
> platform config.xml.  The bin/create script would completely ignore the
> defaults.xml file and use only the config.xml file.
>
> So, if we shipped both a config.xml *and* defaults.xml, we could choose
> which settings to set for each workflow.  I don't actually think the
> settings should generally differ, and its mildly annoying that we would
> have mostly duplicated files, but it means we can move such "optional"
> settings as <access> or <dependency> etc out of the platform config, and
> into the default app config which lives in cordova-cli, since that is where
> users of the CLI expect them to be.
>
> Note that I think this is important & good because for users of the
> platform workflow, they expect to make changes directly to platform
> config.xml, but for users of the CLI, we keep harping at them to never edit
> those files, yet thats the only way at the moment to remove these optional
> defaults we inject for them.
>
> WDYT?  I'm working on a prototype and will report back if the theory works
> in practice.
>
> -Michal
>
>
>
> On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Michal - I'm not s
> >
> >
> > On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams <
> tommy@devgeeks.org
> > >wrote:
> >
> > > Absolutely agree.
> > >
> > > +1 for * as default, but just as importantly, +1 for never having to
> hax
> > > inside ./platforms/**/* for this stuff.
> > >
> > > We are already forced to use hooks to enforce ./platforms as a build
> > > artefact. Any progress towards the great goal of being able to safely
> > > .gitignore the platforms make me feel warm and fuzzy. ;)
> > >
> > >
> > >
> > > On 4 Dec 2013, at 7:09 am, Michal Mocny <mmocny@chromium.org> wrote:
> > >
> > > > Tommy, absolutely the default should remain *, as I said.
> > > >
> > > > But I hope we can agree that it should also be possible to override
> the
> > > > default without requiring hacks.  iOS already supports this, so its a
> > > > matter of feature parity.
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams <tommy@devgeeks.org>
> > > wrote:
> > > >
> > > >> 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.
> > >
> >
> > I like your suggestion here actually.
> > - Take <access> out of defaults.xml, and leave it in CLI's config.xml
> > template
> > - Leave <access> in template's config.xml
> >
> > That will mean:
> > - for non-CLI projects, it will be there by default, and users can edit
> it
> > directly
> > - for CLI projects, it will be there by default due to the app's
> > config.xml, and users can edit that one to remove it.
> >
> >
> >
> > > >>>>>
> > > >>>>>
> > > >>>>> 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..
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

--485b395db092c1385204ecb9cb80--