cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <to...@devgeeks.org>
Subject Re: [android] How to remove the automatic default of <access origin="*"/>
Date Wed, 04 Dec 2013 19:31:53 GMT
+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
View raw message