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 Thu, 05 Dec 2013 19:39:34 GMT
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>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 <mmocny@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" <mmocny@chromium.org> wrote:
> >>
> >>> Alright,  Andrew and I discussed this and think we have a resolution
> that
> >>> works with all the use cases (yay for options).
> >>>
> >>> TLDR; I think we already (accidentally?) support using a different
> >> default
> >>> platform config file for each of our two workflows.  This means we can
> >> have
> >>> the <access origin="*"> tag live inside the platform config for
> >>> platform-centric workflow, and inside the app config for app-centric
> >>> workflow.  This means users less surprise for end users, and downstream
> >>> distributions can more sensibly override these types of defaults should
> >>> they chose to.
> >>>
> >>> ----
> >>>
> >>> Most platforms don't ship with a defaults.xml file yet (except for BB;
> >>> because Jeff did this work, he followed through for that platform).
> >> There
> >>> are open bugs to add these (ie, CB-5047).
> >>>
> >>> Jeff also added a nice fallback to the CLI: if there does not exist a
> >>> defaults.xml when running "prepare", backup the initial config.xml to a
> >>> defaults.xml file before we go messing everything up with plugin / app
> >>> settings.  Effectively the config.xml that ships with platforms is the
> >>> defaults.xml for platforms that don't have one explicitly added.  This
> >> is a
> >>> great default.
> >>>
> >>> However, if there actually were a defaults.xml, the CLI would consume
> >> that
> >>> for its initial input in the prepare process, and completely ignore the
> >>> platform config.xml.  The bin/create script would completely ignore the
> >>> defaults.xml file and use only the config.xml file.
> >>>
> >>> So, if we shipped both a config.xml *and* defaults.xml, we could choose
> >>> which settings to set for each workflow.  I don't actually think the
> >>> settings should generally differ, and its mildly annoying that we would
> >>> have mostly duplicated files, but it means we can move such "optional"
> >>> settings as <access> or <dependency> etc out of the platform
config,
> and
> >>> into the default app config which lives in cordova-cli, since that is
> >> where
> >>> users of the CLI expect them to be.
> >>>
> >>> Note that I think this is important & good because for users of the
> >>> platform workflow, they expect to make changes directly to platform
> >>> config.xml, but for users of the CLI, we keep harping at them to never
> >> edit
> >>> those files, yet thats the only way at the moment to remove these
> >> optional
> >>> defaults we inject for them.
> >>>
> >>> WDYT?  I'm working on a prototype and will report back if the theory
> >> works
> >>> in practice.
> >>>
> >>> -Michal
> >>>
> >>>
> >>>
> >>> On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve <agrieve@chromium.org>
> >>> wrote:
> >>>
> >>>> Michal - I'm not s
> >>>>
> >>>>
> >>>> On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams <
> >>> tommy@devgeeks.org
> >>>>> wrote:
> >>>>
> >>>>> Absolutely agree.
> >>>>>
> >>>>> +1 for * as default, but just as importantly, +1 for never having
to
> >>> hax
> >>>>> inside ./platforms/**/* for this stuff.
> >>>>>
> >>>>> We are already forced to use hooks to enforce ./platforms as a build
> >>>>> artefact. Any progress towards the great goal of being able to safely
> >>>>> .gitignore the platforms make me feel warm and fuzzy. ;)
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 4 Dec 2013, at 7:09 am, Michal Mocny <mmocny@chromium.org>
wrote:
> >>>>>
> >>>>>> Tommy, absolutely the default should remain *, as I said.
> >>>>>>
> >>>>>> But I hope we can agree that it should also be possible to override
> >>> the
> >>>>>> default without requiring hacks.  iOS already supports this,
so
> >> its a
> >>>>>> matter of feature parity.
> >>>>>>
> >>>>>> -Michal
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams <tommy@devgeeks.org
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Please don't go back to when every new dev had to struggle
with
> >> the
> >>>>> Google
> >>>>>>> group or irc to find out why their ajax requests didn't
work.
> >>>>>>>
> >>>>>>> There was a huuuuge discussion at the time that we chose
to
> >> default
> >>>> to *
> >>>>>>> On 04/12/2013 6:03 am, "Michal Mocny" <mmocny@chromium.org>
> >> wrote:
> >>>>>>>
> >>>>>>>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <
> >>>>> braden@chromium.org
> >>>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> There are two different files here: one is defaults.xml,
which
> >> the
> >>>> CLI
> >>>>>>>>> takes as the basis for its platform config.xml.
The other is the
> >>>>>>>> config.xml
> >>>>>>>>> that you get after running bin/create. In the CLI
world, that
> >>> second
> >>>>>>> file
> >>>>>>>>> is immediately overwritten by one created from defaults.xml,
the
> >>>>>>>> top-level
> >>>>>>>>> app config.xml, etc.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Okay, thats what I thought we were doing, but I cannot
find
> >>> where/how
> >>>>> the
> >>>>>>>> defaults.xml is created in the first place.  I see now
that it
> >> does
> >>>>> exist
> >>>>>>>> in my CLI projects, but seems not to exist inside our
platforms
> >> nor
> >>>>> CLI,
> >>>>>>>> nor can I find the code that generates it.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I support the second point of removing the <access
origin="*" />
> >>>> from
> >>>>>>> the
> >>>>>>>>> CLI's hello world template app; it should be turned
into a
> >>> comment.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Seems this is redundant anyway given that the platforms
provide
> >>> this
> >>>>> as a
> >>>>>>>> default.  Regarding leaving it in as a comment: should
we embed
> >> the
> >>>>> full
> >>>>>>>> spec as a comment?  If not, I would just leave a general
> >>> description
> >>>>> and
> >>>>>>>> link to the spec docs online.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I don't think we should be including <access
origin="*" /> by
> >>>> default
> >>>>>>>>> anywhere, unless we really do want to disable the
whitelist on
> >>> that
> >>>>>>>>> platform. And if we do want to disable it, why not
in the native
> >>>> code
> >>>>>>>>> instead of allowing everything by default?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I remember about a year ago we had a bunch of talks
regarding the
> >>>>> default
> >>>>>>>> whitelist, and decided that almost every developer doesn't
want
> >> to
> >>>> use
> >>>>> a
> >>>>>>>> whitelist and wants every request to be allowed by default.
 For
> >>>> those
> >>>>>>> few
> >>>>>>>> devs that want this (false?) sense of security they
can learn how
> >>> to
> >>>>>>>> opt-in, instead of having the same question on the user
lists
> >> over
> >>>> and
> >>>>>>> over
> >>>>>>>> about how to opt-out.
> >>>>>>>>
> >>>>>>>> Changing the platforms to allow * by default is an interesting
> >>> idea,
> >>>>> but
> >>>>>>> I
> >>>>>>>> would rather see a solution that doesn't need that change.
 Plus
> >>> its
> >>>> a
> >>>>>>> bit
> >>>>>>>> less semantic/declarative aka more magical/surprising.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Braden
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny <mmocny@google.com
> >>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On ios, the default config.xml file (aka the
platform defaults)
> >>> is
> >>>>>>>>> bundled
> >>>>>>>>>> as part of the ios project template, and the
project template
> >> is
> >>>> easy
> >>>>>>>> to
> >>>>>>>>>> override using flags to create script / CLI
config options.
> >>> Easy,
> >>>>>>>> great.
> >>>>>>>>>>
> >>>>>>>>>> For android, the default config.xml file is
bundled with the
> >>>> platform
> >>>>>>>>>> framework itself and not as part of the project
template.  I
> >>> assume
> >>>>>>>> this
> >>>>>>>>> is
> >>>>>>>>>> not easy to fix, otherwise we would have made
the change
> >> already?
> >>>>>>>>>>
> >>>>>>>>>> Since the <access> tag is additive (i.e.
cannot just override
> >> it
> >>> by
> >>>>>>>>>> appending), there is no way to remove that default
without
> >>> reaching
> >>>>>>> in
> >>>>>>>>> and
> >>>>>>>>>> editing cordova-android/framework/res/xml/config.xml
file
> >>> directly
> >>>>>>>>> (either
> >>>>>>>>>> with a custom post-platform-add hook to run
sed, or by forking
> >>>>>>>>>> cordova-android to change the default, both
shitty options
> >> imho).
> >>>>>>>>>>
> >>>>>>>>>> Any suggestions on how to fix this?
> >>>>>>>>>>
> >>>>>>>>>> I was hoping to propose that we move the tag
out of all the
> >>>> platform
> >>>>>>>>>> templates and instead add it to the hello-world
app template --
> >>>> but I
> >>>>>>>>> think
> >>>>>>>>>> that won't work well with the platform-scripts
workflow since
> >>> that
> >>>>>>> flow
> >>>>>>>>>> doesn't use an application level config.xml
at all right now.
> >>>>>
> >>>>
> >>>> I like your suggestion here actually.
> >>>> - Take <access> out of defaults.xml, and leave it in CLI's config.xml
> >>>> template
> >>>> - Leave <access> in template's config.xml
> >>>>
> >>>> That will mean:
> >>>> - for non-CLI projects, it will be there by default, and users can
> edit
> >>> it
> >>>> directly
> >>>> - for CLI projects, it will be there by default due to the app's
> >>>> config.xml, and users can edit that one to remove it.
> >>>>
> >>>>
> >>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Second, related issue: cordova-cli bundles a
default
> >> application
> >>>>>>>>> config.xml
> >>>>>>>>>> file, which also includes <access origin="*"/>.
 I think this
> >> is
> >>>> just
> >>>>>>>>>> unnecessary and should be removed.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -Michal
> >>>>>>>>>>
> >>>>>>>>>> p.s. as an aside, I thought we were moving the
default platform
> >>>>>>>>> config.xml
> >>>>>>>>>> out into a file called "defaults.xml"?  It seems
only the good
> >>>> folks
> >>>>>>> at
> >>>>>>>>>> blackberry have done that so far..
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

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