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 <[email protected]> wrote: > Michal - I'm not s > > > On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams <[email protected] > >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 <[email protected]> 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 <[email protected]> > > 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" <[email protected]> wrote: > > >> > > >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson < > > [email protected] > > >>>> 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 <[email protected]> > > >> 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.. > > >>>>> > > >>>> > > >>> > > >> > > > > >
