Yikes! Filed this: https://issues.apache.org/jira/browse/CB-7183
Anyone able to fix it? On Mon, Jul 21, 2014 at 1:10 PM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Just a note, currently any plugin can add some custom file to hooks > directory and it will be executed > > <source-file src="src/someScript.js" > target-dir="../../../../../hooks/pre_package"/> > > Thx! > Sergey > -----Original Message----- > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal > Mocny > Sent: Monday, July 21, 2014 6:28 PM > To: dev > Subject: Re: Proposal: hooks support for plugins > > Whatever the decision for default prompt/no-prompt, I suggest we add a > flag to do the reverse for anyone concerned. > > Aka, --prompt-for-plugin-hooks or --no-prompt-for-plugin-hooks > > > On Fri, Jul 18, 2014 at 5:55 PM, Shazron <shaz...@gmail.com> wrote: > > > Echoing what Jesse said - having a prompt will defeat tools, > > especially since early on we kinda had consensus not to add in a > > security layer. > > The middle way is to add a CLI option to "auto-accept" all prompts > > with Y, kinda like a lot of command line tools. I think there is this > > pattern in Windows command line tools ( > > https://www.microsoft.com/resources/documentation/windows/xp/all/prodd > > ocs/en-us/copy.mspx?mfr=true > > ), > > not sure *nix, I think for *nix the pattern is only prompt if a flag > > is added, the opposite. > > > > On Fri, Jul 18, 2014 at 2:26 PM, Jesse <purplecabb...@gmail.com> wrote: > > > Prompting would make it nearly impossible for third party tools to > > > use, there is no one to accept. > > > PGBuild will allow scripts, but they will only be for pre-verified > > plugins, > > > just like they deal with compiling arbitrary native code ... the > > > script-exec is NOT a new backdoor in this case, just another window. > > > When you type `npm install ios-sim` unknown, unverified (by you) > > > scripts are run ... how is this any different? Any npm package with > > > a preinstall script will do the same, I thought we agreed that this > > > is a community/social > > issue > > > and not a technical/framework issue. > > > > > >>> - Not a fan of "<script>", "<hook>" might be better > > > I agree, or <hook-script> > > > > > >>> - context.commonModules is a great idea, but I don't think > > >>> exposing requireCordovaModule or elementtree is a good idea. > > > +1 Let's not create tech debt if we can avoid it. > > > > > >>> - Since you're making a new class, please don't call it "Hooker" > > > +1 some other ideas, ScriptEscort, PimpMyApp, Hookah > > > > > > > > > > > > @purplecabbage > > > risingj.com > > > > > > > > > On Fri, Jul 18, 2014 at 1:47 PM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > >> What about prompting during plugin install instead of prepare? > > >> "This plugin has hooks, would you like continue? Y/N" > > >> > > >> I'm concerned about being prompted on each prepare, especially in > > >> the > > face > > >> of --watch type scripts. I'm also not sure that plugin authors > > >> should worry about supporting the "no" use case. If a hook is > > >> optional, you > > can > > >> split it out into a separate plugin that is optionally installed. > > >> If > > its > > >> not optional, you should probably not install the plugin at all if > > >> you don't want to run the hook. > > >> > > >> WDYT? > > >> > > >> -Michal > > >> > > >> > > >> On Fri, Jul 18, 2014 at 4:25 PM, Andrew Grieve > > >> <agri...@chromium.org> > > >> wrote: > > >> > > >> > Finally got to having a look. Lots of neat stuff in there! Some > > specific > > >> > feedback: > > >> > > > >> > - Not a fan of "<script>", "<hook>" might be better > > >> > - context.commonModules is a great idea, but I don't think > > >> > exposing requireCordovaModule or elementtree is a good idea. > > >> > - E.g. what if we want to drop our dependency on elementtree? > > >> > - I think it's important that we only expose cordova-lib's > > >> > public > > API > > >> to > > >> > hooks. > > >> > - For the same reason, let's not expose cordovaUtil. just make > > >> > the top-level "cordova" object available. If there are other APIs > > >> > that are needed, we should add them to the public API. > > >> > - Since you're making a new class, please don't call it "Hooker" > > >> > ("HookManager", "HookRunner", etc) > > >> > - Looks like you already added "ScriptsRunner.js" > > >> > - Don't capitalize the file unless it exports as constructor > > >> > - Maybe Hooker can be combined with ScriptsRunner? > > >> > > > >> > Supporting node hooks and adding plugin hooks are two big changes. > > Didn't > > >> > look to see how the commits had things split up, but I'd like to > > >> > see > > one > > >> > change go in separately from the other. > > >> > > > >> > I'm a bit concerned that plugin hooks won't work well due to it > > >> > being > > >> hard > > >> > to write x-platform, server builds like PGBuild, Telerik won't > > >> > want to > > >> have > > >> > hooks run on their servers, Thym likely can't support it. > > >> > Security-wise, I'd feel better about it if we prompted the user > > >> > before enabling plugin scripts to run. Just a simple Y/N > > >> > confirmation would > > be > > >> > enough. E.g.: "Plugin org.foo.bar contains an installation hook. > > Allow it > > >> > to run?" > > >> > > > >> > > > >> > > > >> > > > >> > On Fri, Jul 11, 2014 at 3:42 AM, Sergey Grebnov (Akvelon) < > > >> > v-seg...@microsoft.com> wrote: > > >> > > > >> > > Updated docs[1] as per review. Looking forward to community > > >> > > feedback > > >> > > regarding: > > >> > > 1 . Idea of defining hook scripts via config.xml and plugin.xml > > >> > > 2. New Script Interface for .js files (not used for /hooks > > >> > > scripts > > for > > >> > > backward compatibility) > > >> > > > > >> > > [1]https://github.com/apache/cordova-lib/pull/55 > > >> > > [2] > > >> > > > > >> > > > >> > > https://github.com/MSOpenTech/cordova-lib/blob/CB-6481-hooks/cordova-l > > ib/templates/hooks-README.md#script-interface > > >> > > > > >> > > Thx! > > >> > > Sergey > > >> > > -----Original Message----- > > >> > > From: Shazron [mailto:shaz...@gmail.com] > > >> > > Sent: Wednesday, July 9, 2014 9:26 PM > > >> > > To: dev@cordova.apache.org > > >> > > Subject: Re: Proposal: hooks support for plugins > > >> > > > > >> > > Ah ok. However I think since it is effectively deprecated we > > >> > > should > > not > > >> > > advertise the old way as a supported way to do things but add > > another > > >> > > section saying that support for "./cordova/hooks" may be > > >> > > removed in > > the > > >> > > future, and perhaps give a timeline for removal. > > >> > > > > >> > > On Wed, Jul 9, 2014 at 10:15 AM, Josh Soref > > >> > > <jso...@blackberry.com> > > >> > wrote: > > >> > > > Shazron wrote: > > >> > > >> from the Cordova Hooks doc: > > >> > > >> "This directory used to exist at .cordova/hooks, but has now > > >> > > >> been moved to the project root." > > >> > > >> -> doesn't this imply that .cordova/hooks > > >> > > >> does not work anymore, you should use hooks/ ? > > >> > > > > > >> > > > I believe it's supported for backwards compatibility (just as > > >> > > > www/config.xml is) > > >> > > > > >> > > > >> > > >
