incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Naviation Use Cases and whitelist
Date Fri, 03 Feb 2012 18:44:32 GMT
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" <curtis.bryce@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 <gibson.becky@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 <shazron@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
>> >
>>


Mime
View raw message