+1 But we need better docs to explain the differences between legacy-whitelist and whitelist
And more detailed explanation on how to create a proper config.xml that works across the board for ios and android. What about windows? Also to look on how to have a good config.xml in hello-world template, since most users will start with this first and I would like to be secure by default and they open. meaning rely on CSP, and only use config.xml for x, y, z On Wed, Aug 26, 2015 at 10:34 AM Tommy-Carlos Williams <to...@devgeeks.org> wrote: > +1 from me. > > > > > On 26 Aug 2015, at 23:13, Shazron <shaz...@gmail.com> wrote: > > > > Any objections or further feedback? If not I will move on to what we seem > > to have consensus about: > > > > If there are no <access> entries, then network requests are wide open > > (wildcard * default) and security is handled via CSP. > > We would recommend no <access> entries to be used, users should use CSP. > > > >> On Tue, Aug 11, 2015 at 7:01 PM, Shazron <shaz...@gmail.com> wrote: > >> > >> > >> So, is the whitelist plugin network request list "*" with no <access> > >>> entries, or > >>> "*" because of the <access> entry added to the default project? > >> > >> > >> "*" would be the default. So if there are no <access> entries, it would > be > >> added. If the default project had the <access> wildcard, then no change > >> (since that is the default anyway). > >> > >> The old way you would need an explicit <access> entry wildcard for > >> unrestricted native and web code access -- the new way is unrestricted > >> native code access (unless set explicitly), and CSP for web code access. > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
