cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: [android] How to remove the automatic default of <access origin="*"/>
Date Wed, 04 Dec 2013 16:24:12 GMT
Alright,  Andrew and I discussed this and think we have a resolution that
works with all the use cases (yay for options).

TLDR; I think we already (accidentally?) support using a different default
platform config file for each of our two workflows.  This means we can have
the <access origin="*"> tag live inside the platform config for
platform-centric workflow, and inside the app config for app-centric
workflow.  This means users less surprise for end users, and downstream
distributions can more sensibly override these types of defaults should
they chose to.

----

Most platforms don't ship with a defaults.xml file yet (except for BB;
because Jeff did this work, he followed through for that platform).  There
are open bugs to add these (ie, CB-5047).

Jeff also added a nice fallback to the CLI: if there does not exist a
defaults.xml when running "prepare", backup the initial config.xml to a
defaults.xml file before we go messing everything up with plugin / app
settings.  Effectively the config.xml that ships with platforms is the
defaults.xml for platforms that don't have one explicitly added.  This is a
great default.

However, if there actually were a defaults.xml, the CLI would consume that
for its initial input in the prepare process, and completely ignore the
platform config.xml.  The bin/create script would completely ignore the
defaults.xml file and use only the config.xml file.

So, if we shipped both a config.xml *and* defaults.xml, we could choose
which settings to set for each workflow.  I don't actually think the
settings should generally differ, and its mildly annoying that we would
have mostly duplicated files, but it means we can move such "optional"
settings as <access> or <dependency> etc out of the platform config, and
into the default app config which lives in cordova-cli, since that is where
users of the CLI expect them to be.

Note that I think this is important & good because for users of the
platform workflow, they expect to make changes directly to platform
config.xml, but for users of the CLI, we keep harping at them to never edit
those files, yet thats the only way at the moment to remove these optional
defaults we inject for them.

WDYT?  I'm working on a prototype and will report back if the theory works
in practice.

-Michal



On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Michal - I'm not s
>
>
> On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams <tommy@devgeeks.org
> >wrote:
>
> > Absolutely agree.
> >
> > +1 for * as default, but just as importantly, +1 for never having to hax
> > inside ./platforms/**/* for this stuff.
> >
> > We are already forced to use hooks to enforce ./platforms as a build
> > artefact. Any progress towards the great goal of being able to safely
> > .gitignore the platforms make me feel warm and fuzzy. ;)
> >
> >
> >
> > On 4 Dec 2013, at 7:09 am, Michal Mocny <mmocny@chromium.org> wrote:
> >
> > > Tommy, absolutely the default should remain *, as I said.
> > >
> > > But I hope we can agree that it should also be possible to override the
> > > default without requiring hacks.  iOS already supports this, so its a
> > > matter of feature parity.
> > >
> > > -Michal
> > >
> > >
> > > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams <tommy@devgeeks.org>
> > wrote:
> > >
> > >> Please don't go back to when every new dev had to struggle with the
> > Google
> > >> group or irc to find out why their ajax requests didn't work.
> > >>
> > >> There was a huuuuge discussion at the time that we chose to default
> to *
> > >> On 04/12/2013 6:03 am, "Michal Mocny" <mmocny@chromium.org> wrote:
> > >>
> > >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <
> > braden@chromium.org
> > >>>> wrote:
> > >>>
> > >>>> There are two different files here: one is defaults.xml, which
the
> CLI
> > >>>> takes as the basis for its platform config.xml. The other is the
> > >>> config.xml
> > >>>> that you get after running bin/create. In the CLI world, that second
> > >> file
> > >>>> is immediately overwritten by one created from defaults.xml, the
> > >>> top-level
> > >>>> app config.xml, etc.
> > >>>>
> > >>>
> > >>> Okay, thats what I thought we were doing, but I cannot find where/how
> > the
> > >>> defaults.xml is created in the first place.  I see now that it does
> > exist
> > >>> in my CLI projects, but seems not to exist inside our platforms nor
> > CLI,
> > >>> nor can I find the code that generates it.
> > >>>
> > >>>
> > >>>>
> > >>>> I support the second point of removing the <access origin="*"
/>
> from
> > >> the
> > >>>> CLI's hello world template app; it should be turned into a comment.
> > >>>>
> > >>>
> > >>> Seems this is redundant anyway given that the platforms provide this
> > as a
> > >>> default.  Regarding leaving it in as a comment: should we embed the
> > full
> > >>> spec as a comment?  If not, I would just leave a general description
> > and
> > >>> link to the spec docs online.
> > >>>
> > >>>
> > >>>> I don't think we should be including <access origin="*" />
by
> default
> > >>>> anywhere, unless we really do want to disable the whitelist on
that
> > >>>> platform. And if we do want to disable it, why not in the native
> code
> > >>>> instead of allowing everything by default?
> > >>>>
> > >>>
> > >>> I remember about a year ago we had a bunch of talks regarding the
> > default
> > >>> whitelist, and decided that almost every developer doesn't want to
> use
> > a
> > >>> whitelist and wants every request to be allowed by default.  For
> those
> > >> few
> > >>> devs that want this (false?) sense of security they can learn how to
> > >>> opt-in, instead of having the same question on the user lists over
> and
> > >> over
> > >>> about how to opt-out.
> > >>>
> > >>> Changing the platforms to allow * by default is an interesting idea,
> > but
> > >> I
> > >>> would rather see a solution that doesn't need that change.  Plus its
> a
> > >> bit
> > >>> less semantic/declarative aka more magical/surprising.
> > >>>
> > >>>
> > >>>>
> > >>>> Braden
> > >>>>
> > >>>>
> > >>>> On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny <mmocny@google.com>
> > >> wrote:
> > >>>>
> > >>>>> On ios, the default config.xml file (aka the platform defaults)
is
> > >>>> bundled
> > >>>>> as part of the ios project template, and the project template
is
> easy
> > >>> to
> > >>>>> override using flags to create script / CLI config options.
 Easy,
> > >>> great.
> > >>>>>
> > >>>>> For android, the default config.xml file is bundled with the
> platform
> > >>>>> framework itself and not as part of the project template. 
I assume
> > >>> this
> > >>>> is
> > >>>>> not easy to fix, otherwise we would have made the change already?
> > >>>>>
> > >>>>> Since the <access> tag is additive (i.e. cannot just
override it by
> > >>>>> appending), there is no way to remove that default without
reaching
> > >> in
> > >>>> and
> > >>>>> editing cordova-android/framework/res/xml/config.xml file directly
> > >>>> (either
> > >>>>> with a custom post-platform-add hook to run sed, or by forking
> > >>>>> cordova-android to change the default, both shitty options
imho).
> > >>>>>
> > >>>>> Any suggestions on how to fix this?
> > >>>>>
> > >>>>> I was hoping to propose that we move the tag out of all the
> platform
> > >>>>> templates and instead add it to the hello-world app template
--
> but I
> > >>>> think
> > >>>>> that won't work well with the platform-scripts workflow since
that
> > >> flow
> > >>>>> doesn't use an application level config.xml at all right now.
> >
>
> I like your suggestion here actually.
> - Take <access> out of defaults.xml, and leave it in CLI's config.xml
> template
> - Leave <access> in template's config.xml
>
> That will mean:
> - for non-CLI projects, it will be there by default, and users can edit it
> directly
> - for CLI projects, it will be there by default due to the app's
> config.xml, and users can edit that one to remove it.
>
>
>
> > >>>>>
> > >>>>>
> > >>>>> Second, related issue: cordova-cli bundles a default application
> > >>>> config.xml
> > >>>>> file, which also includes <access origin="*"/>.  I think
this is
> just
> > >>>>> unnecessary and should be removed.
> > >>>>>
> > >>>>>
> > >>>>> -Michal
> > >>>>>
> > >>>>> p.s. as an aside, I thought we were moving the default platform
> > >>>> config.xml
> > >>>>> out into a file called "defaults.xml"?  It seems only the good
> folks
> > >> at
> > >>>>> blackberry have done that so far..
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message