incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <pmue...@gmail.com>
Subject Re: Consistent implementation of the whitelist
Date Tue, 31 Jan 2012 02:52:38 GMT
On Mon, Jan 30, 2012 at 21:04, Shazron <shazron@gmail.com> wrote:

> During the 1.4.0 planning call, Anis proposed these requirements:
> 1.  a consistent implementation of the whitelist across all platforms
>

yes!


> 2.  follow the Opera standard (need a url to the docs for this,

couldn't find it using the obvious keywords)
>

following existing standards is great, but let's find the URL


> 3.  white-listing should be documented on the docs site (Getting
> Started section)
>

yes!


> The only problem with iOS adopting this is the .plist format does not
> allow attributes in its xml. Right now the list of allowed hosts is
> just an array of strings, but to support "attributes" it would have to
> be an array of dictionaries. I could make this change but this
> satisfies neither requirements (1) nor (2).
>

Bending the iOS plist format seems wrong.


> Changing the iOS implementation to support a PhoneGap.xml list instead
> of .plist is another effort entirely, but better now than later -
> unless we are going to use config.xml. Thoughts?
>

Yes, let's go for complete consistency.

Another thought for a "standard" would be the app cache manifest.  It's a
simple text file, with "stanzas".  The applicable one here is the NETWORK
stanza, also referred to in the spec as the "online whitelist section".
 Basic idea is each line is either '*' (and then you don't need any more
lines!) or a URL prefix.  Any URLs you attempt to resolve that match a
prefix are allowed, others aren't.  Full spec for app-cache here, the
details are not simplistic for the whole ball of wax. [1]

If we wanted to do this, I'd say we just support the notion of a white list
file with the contents corresponding to the NETWORK stanza of the app-cache
file.

I believe one other issue that has come up is whether there should be
separate white lists for "normal" URL accesses and child browser usage.
 Easy to imagine some other plugin may want to take advantage of white
lists also.

[1] http://www.w3.org/TR/html5/offline.html

-- 
Patrick Mueller
http://muellerware.org

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