Carlos - I'll add your notes to the JIRA issue below. Filed: https://issues.apache.org/jira/browse/CB-9568
Overall board: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 On Wed, Aug 26, 2015 at 7:58 AM, Carlos Santana <csantan...@gmail.com> wrote: > +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 > > > > >
