You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2012/02/01 01:23:05 UTC
Re: Naviation Use Cases and whitelist
> - iframe within a cordova page - user just wants to display some other
> content within the page and sandbox it in an iframe. They do not want to
> have to worry about any PG commands getting invoked by the pages loaded in
> the iframe and do not want to have to specify a whitelist for the iframe.
> Although I have seen requests where people DO want to run PG commands from
> the iframe - although I'm not sure I understand why.
For iOS, currently use of our custom NSURLProtocol is all or nothing -
it's a whitelist for all connections. We'll have to figure out an
exemption mechanism (it's possible with
https://github.com/apache/incubator-cordova-ios/blob/master/PhoneGapLib/Classes/PGViewController.m#L379
and a config.xml setting I suppose)
> - childbrowser plugin - I have an app that tracks my blood donations. I
> want to go out to the Red Cross web site to find the next donations in my
> area. In this case I don't want to use the whitelist and I do not want any
> PG commands invoked from within the Childbrowser (other than to deal with
> the events from the Childbrowser). There may be cases where the user does
> want PG commands within a ChildBrowser - with the new Web View /Cleaver
> implementations this could be an option.
For iOS, we will have to have an exemption mechanism for the "all or
nothing" custom NSURLProtocol. I'm thinking something like this:
1. ChildBrowser registers its app id with our custom NSURLProtocol
(PGURLProtocol)
2. ChildBrowser receives an access token (randomly generated, only
valid for this app session) from the PGURLProtocol
3. ChildBrowser uses this access token in a custom header in the
NSURLRequest in webView:shouldStartLoadWithRequest:navigationType:
4. PGURLProtocol will try to read this access token and app id in the
header, and if it is found and it matches, skips the whitelist check
> - ajax requests - enforce the whitelist
> - Not sure how we should deal with JavaScript invocations to open a new
> page?
I believe the UIWebViewNavigationType would give a clue in
webView:shouldStartLoadWithRequest:navigationType: but this value is
ambiguous / not reliable
> Should these open in the webview or open in the mobile browser (in the
> case of iOS this will leave the app with no way to return via a back button
> unless the Childbrowser is used).
> One would suspect that you would want a remote URL to open in the
> mobile browser UNLESS you are loading PhoneGap.js from that location as
> well and thus want it in the webView (in which case the whitelist is
> enforced)
> - window.location = url
> - <a href=url>new local or remote location</a>
Remote url would be mobile browser. How would you know that a remote
url has PhoneGap.js? I'm assuming this can be solved with my answer
below (API function)
> - Need a way to force opening in the browser (not the webview) and
> ignoring the whitlist check.
Use case? In any case I can't think of a 'standards' way for this - we
would have to provide some API function - if not available, just use
document.location
Re: Naviation Use Cases and whitelist
Posted by Marcos Caceres <co...@marcosc.com>.
Hi,
I just joined the mailing list…
On Friday, 3 February 2012 at 19:56, Shazron wrote:
> > I *highly* suggest we employ config.xml as the abstraction for app
> > configuration/metadata such as whitelisting, orientation locking,
> > application naming, author info, etc. etc.
>
>
>
> That's what we agreed (consensus?) in the other thread - one
> config.xml to rule them all.
>
> iOS has other issues with the implementation of the whitelist that is
> not covered by the spec, like I already mentioned (whitelist exemption
> for a particular component, like the ChildBrowser - see my proposal
> for a mechanism for fixing this, earlier - and it is iOS specific)
> unless this situation can be covered by the spec, which after looking
> at the widgets access spec I don't think it is?
I co-authored that spec (and most of the W3C widget specs), so happy to answer any questions… As I said above, I just joined this mailing list so don't have much context but can try to help.
Re: Naviation Use Cases and whitelist
Posted by Marcos Caceres <co...@marcosc.com>.
On Friday, 3 February 2012 at 20:06, Filip Maj wrote:
> The neat thing about config.xml is that the elements are
> composable/nestable.
This is true to a degree…. The W3C spec defines the following algorithm to process XML files:
http://dev.w3.org/2006/waf/widgets/#algorithm-to-process-a-configuration-document
> WebWorks employs this for some of their stuff too,
> for example consider this use case that is doable in WebWorks with the
> help of config.xml:
>
> You set your app's <content> element to point to some start page within
> your app package, i.e. index.html. But you want to iterate on your app
> development faster, so instead of redeploying your app to clients every
> time you make a change, instead you change the start page to point to some
> page online, I.e. http://mydomain.com/mycordovaapp/index.html. In
> webworks, you can nest the various elements inside each other, so you can
> do:
>
> <access origin="http://mydomain.com" subdomains="true">
> <content src="http://mydomain.com/mycordovaapp/index.html" />
> </access>
hmm… the WARP parsing algorithm would generally ignore such a construct (see [1]). However, it could be coerced to work - but it would not be standards compliant.
[1] http://dev.w3.org/2006/waf/widgets-access/#dfn-rule-for-processing-an-access-element
>
> This would explicitly allow the start page to be loaded from a remote
> location.
Also, the src attribute only accepts a Path to local file (I know, that's limiting… but it was for historical/security reasons). However, in the new version of the spec [2], we could certainly allow URLs (it was always the intention to allow them at some point, but we just wanted to get widgets working locally).
[2] http://dev.w3.org/2006/waf/widgets/#the-src-attribute-0
The current way to do the above is without modifying anything is…
config.xml:
<widget …>
<access origin="http://mydomain.com" subdomains="true">
</widget>
index.html:
<doctype html>
<iframe style="width:100%; height: 100%" src="http://mydomain.com/mycordovaapp/index.html">
>
> We could employ the same thing for plugins. Assuming plugin definitions
> would be specified declaratively in the config.xml with the help of
> <feature> elements, you could nest <feature> elements inside <access>
> elements, for example.
>
> I like this approach from a user of cordova perspective. The
> implementation will be a bit more challenging I think :r
>
> On 12-02-03 11:56 AM, "Shazron" <shazron@gmail.com (mailto:shazron@gmail.com)> wrote:
>
> > > I *highly* suggest we employ config.xml as the abstraction for app
> > > configuration/metadata such as whitelisting, orientation locking,
> > > application naming, author info, etc. etc.
> >
> >
> >
> > That's what we agreed (consensus?) in the other thread - one
> > config.xml to rule them all.
> >
> > iOS has other issues with the implementation of the whitelist that is
> > not covered by the spec, like I already mentioned (whitelist exemption
> > for a particular component, like the ChildBrowser - see my proposal
> > for a mechanism for fixing this, earlier - and it is iOS specific)
> > unless this situation can be covered by the spec, which after looking
> > at the widgets access spec I don't think it is?
>
--
Marcos Caceres
Re: Naviation Use Cases and whitelist
Posted by Filip Maj <fi...@adobe.com>.
The neat thing about config.xml is that the elements are
composable/nestable. WebWorks employs this for some of their stuff too,
for example consider this use case that is doable in WebWorks with the
help of config.xml:
You set your app's <content> element to point to some start page within
your app package, i.e. index.html. But you want to iterate on your app
development faster, so instead of redeploying your app to clients every
time you make a change, instead you change the start page to point to some
page online, I.e. http://mydomain.com/mycordovaapp/index.html. In
webworks, you can nest the various elements inside each other, so you can
do:
<access origin="http://mydomain.com" subdomains="true">
<content src="http://mydomain.com/mycordovaapp/index.html" />
</access>
This would explicitly allow the start page to be loaded from a remote
location.
We could employ the same thing for plugins. Assuming plugin definitions
would be specified declaratively in the config.xml with the help of
<feature> elements, you could nest <feature> elements inside <access>
elements, for example.
I like this approach from a user of cordova perspective. The
implementation will be a bit more challenging I think :r
On 12-02-03 11:56 AM, "Shazron" <sh...@gmail.com> wrote:
>> I *highly* suggest we employ config.xml as the abstraction for app
>> configuration/metadata such as whitelisting, orientation locking,
>> application naming, author info, etc. etc.
>
>That's what we agreed (consensus?) in the other thread - one
>config.xml to rule them all.
>
>iOS has other issues with the implementation of the whitelist that is
>not covered by the spec, like I already mentioned (whitelist exemption
>for a particular component, like the ChildBrowser - see my proposal
>for a mechanism for fixing this, earlier - and it is iOS specific)
>unless this situation can be covered by the spec, which after looking
>at the widgets access spec I don't think it is?
Re: Naviation Use Cases and whitelist
Posted by Shazron <sh...@gmail.com>.
> I *highly* suggest we employ config.xml as the abstraction for app
> configuration/metadata such as whitelisting, orientation locking,
> application naming, author info, etc. etc.
That's what we agreed (consensus?) in the other thread - one
config.xml to rule them all.
iOS has other issues with the implementation of the whitelist that is
not covered by the spec, like I already mentioned (whitelist exemption
for a particular component, like the ChildBrowser - see my proposal
for a mechanism for fixing this, earlier - and it is iOS specific)
unless this situation can be covered by the spec, which after looking
at the widgets access spec I don't think it is?
Re: Naviation Use Cases and whitelist
Posted by Filip Maj <fi...@adobe.com>.
Personally I like the mailing list threads for discussion. For
brainstorming use cases maybe summarizing in e-mail and detailing on wiki
makes sense.
Also wanted to mention that the W3C Configuration Document's <access>
element (used by WebWorks to define whitelists) a.k.a. Widget Access
Request Policy has been given the green light to become a W3C
Recommendation:
http://dev.w3.org/2006/waf/widgets-access/
I *highly* suggest we employ config.xml as the abstraction for app
configuration/metadata such as whitelisting, orientation locking,
application naming, author info, etc. etc.
On 12-02-02 2:43 PM, "Bryce Curtis" <cu...@gmail.com> wrote:
>I agree it will be easier to keep track of the the scenarios that can be
>easily lost in the thread. Also, the whitelist discussion too. We can
>include conclusions in thread if needed for record.
>
>On Thu, Feb 2, 2012 at 4:38 PM, Becky Gibson <gi...@gmail.com>
>wrote:
>
>> I moved this discussion to a wiki page for what I hope is better
>>clarity:
>> http://wiki.apache.org/cordova/NavigationUseCases. Please add more
>> examples and any device specific implementations and issues.
>>
>> We may want to consider taking the "Consistent implementation of the
>> whitelist" discussion thread to the wiki as well. I think it gets
>>hard to
>> follow the discussion in the email thread. Do others agree?
>>
>> thanks,
>> -becky
>>
>> On Tue, Jan 31, 2012 at 7:23 PM, Shazron <sh...@gmail.com> wrote:
>>
>> > > - iframe within a cordova page - user just wants to display some
>> other
>> > > content within the page and sandbox it in an iframe. They do not
>> want
>> > to
>> > > have to worry about any PG commands getting invoked by the pages
>> > loaded in
>> > > the iframe and do not want to have to specify a whitelist for the
>> > iframe.
>> > > Although I have seen requests where people DO want to run PG
>> commands
>> > from
>> > > the iframe - although I'm not sure I understand why.
>> >
>> > For iOS, currently use of our custom NSURLProtocol is all or nothing -
>> > it's a whitelist for all connections. We'll have to figure out an
>> > exemption mechanism (it's possible with
>> >
>> >
>>
>>https://github.com/apache/incubator-cordova-ios/blob/master/PhoneGapLib/C
>>lasses/PGViewController.m#L379
>> > and a config.xml setting I suppose)
>> >
>> > > - childbrowser plugin - I have an app that tracks my blood
>>donations.
>> > I
>> > > want to go out to the Red Cross web site to find the next
>>donations
>> in
>> > my
>> > > area. In this case I don't want to use the whitelist and I do not
>> > want any
>> > > PG commands invoked from within the Childbrowser (other than to
>>deal
>> > with
>> > > the events from the Childbrowser). There may be cases where the
>>user
>> > does
>> > > want PG commands within a ChildBrowser - with the new Web View
>> /Cleaver
>> > > implementations this could be an option.
>> >
>> > For iOS, we will have to have an exemption mechanism for the "all or
>> > nothing" custom NSURLProtocol. I'm thinking something like this:
>> >
>> > 1. ChildBrowser registers its app id with our custom NSURLProtocol
>> > (PGURLProtocol)
>> > 2. ChildBrowser receives an access token (randomly generated, only
>> > valid for this app session) from the PGURLProtocol
>> > 3. ChildBrowser uses this access token in a custom header in the
>> > NSURLRequest in webView:shouldStartLoadWithRequest:navigationType:
>> > 4. PGURLProtocol will try to read this access token and app id in the
>> > header, and if it is found and it matches, skips the whitelist check
>> >
>> > > - ajax requests - enforce the whitelist
>> > > - Not sure how we should deal with JavaScript invocations to open
>>a
>> new
>> > > page?
>> >
>> > I believe the UIWebViewNavigationType would give a clue in
>> > webView:shouldStartLoadWithRequest:navigationType: but this value is
>> > ambiguous / not reliable
>> >
>> > > Should these open in the webview or open in the mobile browser
>>(in
>> the
>> > > case of iOS this will leave the app with no way to return via a
>>back
>> > button
>> > > unless the Childbrowser is used).
>> > > One would suspect that you would want a remote URL to open in the
>> > > mobile browser UNLESS you are loading PhoneGap.js from that
>>location
>> as
>> > > well and thus want it in the webView (in which case the whitelist
>>is
>> > > enforced)
>> > > - window.location = url
>> > > - <a href=url>new local or remote location</a>
>> >
>> > Remote url would be mobile browser. How would you know that a remote
>> > url has PhoneGap.js? I'm assuming this can be solved with my answer
>> > below (API function)
>> >
>> > > - Need a way to force opening in the browser (not the webview) and
>> > > ignoring the whitlist check.
>> >
>> > Use case? In any case I can't think of a 'standards' way for this - we
>> > would have to provide some API function - if not available, just use
>> > document.location
>> >
>>
Re: Naviation Use Cases and whitelist
Posted by Bryce Curtis <cu...@gmail.com>.
I agree it will be easier to keep track of the the scenarios that can be
easily lost in the thread. Also, the whitelist discussion too. We can
include conclusions in thread if needed for record.
On Thu, Feb 2, 2012 at 4:38 PM, Becky Gibson <gi...@gmail.com> wrote:
> I moved this discussion to a wiki page for what I hope is better clarity:
> http://wiki.apache.org/cordova/NavigationUseCases. Please add more
> examples and any device specific implementations and issues.
>
> We may want to consider taking the "Consistent implementation of the
> whitelist" discussion thread to the wiki as well. I think it gets hard to
> follow the discussion in the email thread. Do others agree?
>
> thanks,
> -becky
>
> On Tue, Jan 31, 2012 at 7:23 PM, Shazron <sh...@gmail.com> wrote:
>
> > > - iframe within a cordova page - user just wants to display some
> other
> > > content within the page and sandbox it in an iframe. They do not
> want
> > to
> > > have to worry about any PG commands getting invoked by the pages
> > loaded in
> > > the iframe and do not want to have to specify a whitelist for the
> > iframe.
> > > Although I have seen requests where people DO want to run PG
> commands
> > from
> > > the iframe - although I'm not sure I understand why.
> >
> > For iOS, currently use of our custom NSURLProtocol is all or nothing -
> > it's a whitelist for all connections. We'll have to figure out an
> > exemption mechanism (it's possible with
> >
> >
> https://github.com/apache/incubator-cordova-ios/blob/master/PhoneGapLib/Classes/PGViewController.m#L379
> > and a config.xml setting I suppose)
> >
> > > - childbrowser plugin - I have an app that tracks my blood donations.
> > I
> > > want to go out to the Red Cross web site to find the next donations
> in
> > my
> > > area. In this case I don't want to use the whitelist and I do not
> > want any
> > > PG commands invoked from within the Childbrowser (other than to deal
> > with
> > > the events from the Childbrowser). There may be cases where the user
> > does
> > > want PG commands within a ChildBrowser - with the new Web View
> /Cleaver
> > > implementations this could be an option.
> >
> > For iOS, we will have to have an exemption mechanism for the "all or
> > nothing" custom NSURLProtocol. I'm thinking something like this:
> >
> > 1. ChildBrowser registers its app id with our custom NSURLProtocol
> > (PGURLProtocol)
> > 2. ChildBrowser receives an access token (randomly generated, only
> > valid for this app session) from the PGURLProtocol
> > 3. ChildBrowser uses this access token in a custom header in the
> > NSURLRequest in webView:shouldStartLoadWithRequest:navigationType:
> > 4. PGURLProtocol will try to read this access token and app id in the
> > header, and if it is found and it matches, skips the whitelist check
> >
> > > - ajax requests - enforce the whitelist
> > > - Not sure how we should deal with JavaScript invocations to open a
> new
> > > page?
> >
> > I believe the UIWebViewNavigationType would give a clue in
> > webView:shouldStartLoadWithRequest:navigationType: but this value is
> > ambiguous / not reliable
> >
> > > Should these open in the webview or open in the mobile browser (in
> the
> > > case of iOS this will leave the app with no way to return via a back
> > button
> > > unless the Childbrowser is used).
> > > One would suspect that you would want a remote URL to open in the
> > > mobile browser UNLESS you are loading PhoneGap.js from that location
> as
> > > well and thus want it in the webView (in which case the whitelist is
> > > enforced)
> > > - window.location = url
> > > - <a href=url>new local or remote location</a>
> >
> > Remote url would be mobile browser. How would you know that a remote
> > url has PhoneGap.js? I'm assuming this can be solved with my answer
> > below (API function)
> >
> > > - Need a way to force opening in the browser (not the webview) and
> > > ignoring the whitlist check.
> >
> > Use case? In any case I can't think of a 'standards' way for this - we
> > would have to provide some API function - if not available, just use
> > document.location
> >
>
Re: Naviation Use Cases and whitelist
Posted by Becky Gibson <gi...@gmail.com>.
I moved this discussion to a wiki page for what I hope is better clarity:
http://wiki.apache.org/cordova/NavigationUseCases. Please add more
examples and any device specific implementations and issues.
We may want to consider taking the "Consistent implementation of the
whitelist" discussion thread to the wiki as well. I think it gets hard to
follow the discussion in the email thread. Do others agree?
thanks,
-becky
On Tue, Jan 31, 2012 at 7:23 PM, Shazron <sh...@gmail.com> wrote:
> > - iframe within a cordova page - user just wants to display some other
> > content within the page and sandbox it in an iframe. They do not want
> to
> > have to worry about any PG commands getting invoked by the pages
> loaded in
> > the iframe and do not want to have to specify a whitelist for the
> iframe.
> > Although I have seen requests where people DO want to run PG commands
> from
> > the iframe - although I'm not sure I understand why.
>
> For iOS, currently use of our custom NSURLProtocol is all or nothing -
> it's a whitelist for all connections. We'll have to figure out an
> exemption mechanism (it's possible with
>
> https://github.com/apache/incubator-cordova-ios/blob/master/PhoneGapLib/Classes/PGViewController.m#L379
> and a config.xml setting I suppose)
>
> > - childbrowser plugin - I have an app that tracks my blood donations.
> I
> > want to go out to the Red Cross web site to find the next donations in
> my
> > area. In this case I don't want to use the whitelist and I do not
> want any
> > PG commands invoked from within the Childbrowser (other than to deal
> with
> > the events from the Childbrowser). There may be cases where the user
> does
> > want PG commands within a ChildBrowser - with the new Web View /Cleaver
> > implementations this could be an option.
>
> For iOS, we will have to have an exemption mechanism for the "all or
> nothing" custom NSURLProtocol. I'm thinking something like this:
>
> 1. ChildBrowser registers its app id with our custom NSURLProtocol
> (PGURLProtocol)
> 2. ChildBrowser receives an access token (randomly generated, only
> valid for this app session) from the PGURLProtocol
> 3. ChildBrowser uses this access token in a custom header in the
> NSURLRequest in webView:shouldStartLoadWithRequest:navigationType:
> 4. PGURLProtocol will try to read this access token and app id in the
> header, and if it is found and it matches, skips the whitelist check
>
> > - ajax requests - enforce the whitelist
> > - Not sure how we should deal with JavaScript invocations to open a new
> > page?
>
> I believe the UIWebViewNavigationType would give a clue in
> webView:shouldStartLoadWithRequest:navigationType: but this value is
> ambiguous / not reliable
>
> > Should these open in the webview or open in the mobile browser (in the
> > case of iOS this will leave the app with no way to return via a back
> button
> > unless the Childbrowser is used).
> > One would suspect that you would want a remote URL to open in the
> > mobile browser UNLESS you are loading PhoneGap.js from that location as
> > well and thus want it in the webView (in which case the whitelist is
> > enforced)
> > - window.location = url
> > - <a href=url>new local or remote location</a>
>
> Remote url would be mobile browser. How would you know that a remote
> url has PhoneGap.js? I'm assuming this can be solved with my answer
> below (API function)
>
> > - Need a way to force opening in the browser (not the webview) and
> > ignoring the whitlist check.
>
> Use case? In any case I can't think of a 'standards' way for this - we
> would have to provide some API function - if not available, just use
> document.location
>