[android] How to remove the automatic default of

[Michal Mocny <mm...@google.com>]

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..

Re: [android] How to remove the automatic default of

[Steven Gill <st...@gmail.com>]

Nice! I will check it out later today.

On Thursday, December 5, 2013, Michal Mocny wrote:

> Alright, I've landed a defaults.xml for ios and android and closed the long
> standing bugs for this.
>
> Aside from removing the <access> tag, I also removed the settings which are
> overwritten by the app-level config anyway, such as app name, description,
> <content> tag, etc.  Please take a look if you have any concerns.  I did
> leave the default platform preferences/features in there, because those can
> be overridden in the app config and many really are platform specific.
>
> Tested using both the CLI and bin/create workflows to make sure both still
> work and do what we intent.
>
> Now, when a CLI user makes changes to the app config to remove <content> or
> <access> tags, the final platform config actually reflects those changes.
>  Win.
>
> -Michal
>
>
> On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams <tommy@devgeeks.org<javascript:;>
> >wrote:
>
> > +1
> >
> > This is all sounding great and no matter how much I love the CLI,
> > supporting both workflows is important.
> >
> >
> >
> >
> > On 5 Dec 2013, at 6:13 am, Michal Mocny <mm...@chromium.org> wrote:
> >
> > > Yes, there is no need to change the tools, which is why I like this
> > > approach.  I forgot to mention that part :P
> > >
> > > I did not think we previously discussed supplying both config files
> with
> > > different default settings.  I had previously imagined we would ship
> > > platforms with only one defaults file (defaults.xml/config.xml
> whichever
> > > name) that was consumed by both flows.  The function of a defaults.xml
> > was
> > > as an implementation detail of CLI to help us treat config.xml as a
> build
> > > artifact.  Now I am proposing using it as a first class config file
> that
> > > gets maintained along with config.xml in platform releases.
> > >
> > > -Michal
> > >
> > >
> > > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <braden@google.com
> > >wrote:
> > >
> > >> 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" <mm...@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

Re: [android] How to remove the automatic default of

[Michal Mocny <mm...@chromium.org>]

Alright, I've landed a defaults.xml for ios and android and closed the long
standing bugs for this.

Aside from removing the <access> tag, I also removed the settings which are
overwritten by the app-level config anyway, such as app name, description,
<content> tag, etc.  Please take a look if you have any concerns.  I did
leave the default platform preferences/features in there, because those can
be overridden in the app config and many really are platform specific.

Tested using both the CLI and bin/create workflows to make sure both still
work and do what we intent.

Now, when a CLI user makes changes to the app config to remove <content> or
<access> tags, the final platform config actually reflects those changes.
 Win.

-Michal


On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams <to...@devgeeks.org>wrote:

> +1
>
> This is all sounding great and no matter how much I love the CLI,
> supporting both workflows is important.
>
>
>
>
> On 5 Dec 2013, at 6:13 am, Michal Mocny <mm...@chromium.org> wrote:
>
> > Yes, there is no need to change the tools, which is why I like this
> > approach.  I forgot to mention that part :P
> >
> > I did not think we previously discussed supplying both config files with
> > different default settings.  I had previously imagined we would ship
> > platforms with only one defaults file (defaults.xml/config.xml whichever
> > name) that was consumed by both flows.  The function of a defaults.xml
> was
> > as an implementation detail of CLI to help us treat config.xml as a build
> > artifact.  Now I am proposing using it as a first class config file that
> > gets maintained along with config.xml in platform releases.
> >
> > -Michal
> >
> >
> > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <braden@google.com
> >wrote:
> >
> >> 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" <mm...@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 <ag...@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 <mm...@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" <mm...@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..
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [android] How to remove the automatic default of

[Tommy-Carlos Williams <to...@devgeeks.org>]

+1 

This is all sounding great and no matter how much I love the CLI, supporting both workflows is important.




On 5 Dec 2013, at 6:13 am, Michal Mocny <mm...@chromium.org> wrote:

> Yes, there is no need to change the tools, which is why I like this
> approach.  I forgot to mention that part :P
> 
> I did not think we previously discussed supplying both config files with
> different default settings.  I had previously imagined we would ship
> platforms with only one defaults file (defaults.xml/config.xml whichever
> name) that was consumed by both flows.  The function of a defaults.xml was
> as an implementation detail of CLI to help us treat config.xml as a build
> artifact.  Now I am proposing using it as a first class config file that
> gets maintained along with config.xml in platform releases.
> 
> -Michal
> 
> 
> On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <br...@google.com>wrote:
> 
>> 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" <mm...@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 <ag...@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 <mm...@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" <mm...@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..
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: [android] How to remove the automatic default of

[Braden Shepherdson <br...@chromium.org>]

If I remember correctly, that isn't a change for the policy - it's just
that most platforms don't have a defaults.xml yet.

My intention with the defaults.xml change has always been that we ship both
files, and maintain both files, since they're consumed by the different
workflows in different ways.

That could probably have been better-communicated, and we should have
pushed more firmly for getting defaults.xml files added to all platforms.

Braden


On Wed, Dec 4, 2013 at 11:13 AM, Michal Mocny <mm...@chromium.org> wrote:

> Yes, there is no need to change the tools, which is why I like this
> approach.  I forgot to mention that part :P
>
> I did not think we previously discussed supplying both config files with
> different default settings.  I had previously imagined we would ship
> platforms with only one defaults file (defaults.xml/config.xml whichever
> name) that was consumed by both flows.  The function of a defaults.xml was
> as an implementation detail of CLI to help us treat config.xml as a build
> artifact.  Now I am proposing using it as a first class config file that
> gets maintained along with config.xml in platform releases.
>
> -Michal
>
>
> On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <braden@google.com
> >wrote:
>
> > 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" <mm...@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 <ag...@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 <mm...@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" <mm...@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..
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [android] How to remove the automatic default of

[Michal Mocny <mm...@chromium.org>]

Yes, there is no need to change the tools, which is why I like this
approach.  I forgot to mention that part :P

I did not think we previously discussed supplying both config files with
different default settings.  I had previously imagined we would ship
platforms with only one defaults file (defaults.xml/config.xml whichever
name) that was consumed by both flows.  The function of a defaults.xml was
as an implementation detail of CLI to help us treat config.xml as a build
artifact.  Now I am proposing using it as a first class config file that
gets maintained along with config.xml in platform releases.

-Michal


On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <br...@google.com>wrote:

> 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" <mm...@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 <ag...@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 <mm...@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" <mm...@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..
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: [android] How to remove the automatic default of

[Braden Shepherdson <br...@google.com>]

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" <mm...@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 <ag...@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 <mm...@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 <to...@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" <mm...@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 <mm...@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..
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: [android] How to remove the automatic default of

[Michal Mocny <mm...@chromium.org>]

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 <ag...@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 <mm...@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 <to...@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" <mm...@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 <mm...@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..
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: [android] How to remove the automatic default of

[Andrew Grieve <ag...@chromium.org>]

Michal - I'm not s


On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams <to...@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 <mm...@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 <to...@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" <mm...@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 <mm...@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..
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [android] How to remove the automatic default of

[Tommy-Carlos Williams <to...@devgeeks.org>]

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 <mm...@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 <to...@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" <mm...@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 <mm...@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..
>>>>> 
>>>> 
>>> 
>> 

Re: [android] How to remove the automatic default of

[Michal Mocny <mm...@chromium.org>]

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 <to...@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" <mm...@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 <mm...@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..
> > > >
> > >
> >
>

Re: [android] How to remove the automatic default of

[Tommy Williams <to...@devgeeks.org>]

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" <mm...@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 <mm...@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..
> > >
> >
>

Re: [android] How to remove the automatic default of

[Michal Mocny <mm...@chromium.org>]

On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <br...@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 <mm...@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..
> >
>

Re: [android] How to remove the automatic default of

[Braden Shepherdson <br...@chromium.org>]

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.

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.

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?

Braden


On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny <mm...@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..
>