Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 27AC5CEB9 for ; Sun, 20 May 2012 04:38:22 +0000 (UTC) Received: (qmail 63597 invoked by uid 500); 20 May 2012 04:38:22 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 63458 invoked by uid 500); 20 May 2012 04:38:21 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 63431 invoked by uid 99); 20 May 2012 04:38:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 May 2012 04:38:20 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of shazron@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-ob0-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 May 2012 04:38:14 +0000 Received: by obhx4 with SMTP id x4so6950635obh.6 for ; Sat, 19 May 2012 21:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=xHC/Yds9YsinCv5GugybG9oCYJUXD9cQvs+W9LM8itE=; b=M336i4trSPY4xvKdiG5VgtGhS/T8QVO9GBaf551xfYXOhPxBadqEo7gChbnFBLIc3Y p+rPTcO7zWB7JdFLEWeMgFXfJtwxjUCWSfEAsq6o4Z/qsHAvL3FqYE/mbFztq0rxCKJJ S/vREyOCM/qOot4t6Ets111ALf5rv0SgoQ41NnsgySnp0giinLqF/EnVg4++Af1wjB8m IcmZHL1hTzh0ojegf81O0oE4UtMcOoKSgugS+D2rzNGjCDRAqK8FKENWkupMuO/tlJN8 MbGCb5/w50Ef2K0sK6hsfNq1xwyJy3ZwyhZuMCJk2qrSezDUxM6WzqU0+5thnA0/A2EH 8OJg== Received: by 10.43.49.3 with SMTP id uy3mr826357icb.2.1337488673456; Sat, 19 May 2012 21:37:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.141.201 with HTTP; Sat, 19 May 2012 21:37:13 -0700 (PDT) In-Reply-To: References: From: Shazron Date: Sat, 19 May 2012 21:37:13 -0700 Message-ID: Subject: Re: API function: Open url in system web browser To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jesse, I understand the problem, I know what Brian is asking, I'm afraid no one does understand with regards to the two request problem. I was afraid someone would "go there" and suggest to compromise the whitelist. This is a security problem if we allow any url with _cordova-target=3D to circumvent the whitelist check, think about it - it's a big hole. On Sat, May 19, 2012 at 8:12 PM, Jesse wrote: > Shaz: I believe Brian is proposing you look for urls > containing _cordova-target=3D before rejecting them via the whitelist. > > IMHO: The discussed solutions resolve to the same thing, it is just a > semantics discussion. > > Given the following html placed in the document by the developer: > asdf > > Providing a new API means the link becomes (or something similar): > gap://app/openExtUrl/http%3A%2F%2Fsomwhere.com > > Brian's proposal means the link becomes : > http://somwhere.com&_cordova-target=3Dblank > > So either native code has to watch for links with '_cordova-target=3D' or > just handle another cordova command. > > Both solutions require re-writing urls on page load, or on dom change. > > Andrew's earlier suggestion added a document level click handler that wou= ld > determine if the clicked item was an and do the right thing based on > it's attributes, which I think has some merit in that it handles dynamic > content, and it doesn't modify it, it just observes it. > > I will be thinking more on this and adding my recommendation in a while .= .. > > > > On Sat, May 19, 2012 at 7:43 PM, Shazron wrote: > >> No. Read it again, especially the two request part. For urls NOT in >> the whitelist, the first request will be rejected by the whitelist. It >> won't work. >> >> On Sat, May 19, 2012 at 7:34 PM, Brian LeRoux wrote: >> > Ok, so read that, its referring to the target attribute but it looks >> > like you can check stil check for a url parameter on an NSURLRequest >> > [1]. >> > >> > >> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/F= oundation/Classes/NSURLProtocol_Class/Reference/Reference.html >> > >> > So what I'm proposing is this: cordovajs walks the dom finding all >> > anchors with a target attribute and adds something like this to the >> > href: >> > >> > a= sdf<.a> >> > >> > Then, when clicked, touched, whatever, you capture if the URL >> > parameter named _cordova-target exists. If it does, spawn browser. >> > >> > Dynamic links would be missed. I think thats an ok/fair quirk. If >> > wanted to be aggressive we *could* watch for dom mutation events and >> > solve that too tho I suspect it would not help performance! >> > >> > >> > On Sat, May 19, 2012 at 6:00 PM, Shazron wrote: >> >> When JIRA is back up (it's under maintenance right now), see my >> >> first/second comment on this issue: >> >> https://issues.apache.org/jira/browse/CB-362 >> >> >> >> It's a bit too long to rehash :) >> >> >> >> On Sat, May 19, 2012 at 8:17 AM, Brian LeRoux wrote: >> >>> Sorry shaz, I must be dense but I missed the technical reasons? >> >>> =A0On May 19, 2012 11:48 AM, "Shazron" wrote: >> >>> >> >>>> > The method I'm proposing >> >>>> > assumes all link events are trapped, inspected for a url param, a= nd >> in >> >>>> > its absence, falls back to default behavior. Maybe thats not >> >>>> > realistic. Seems like both iOS and Android do not trap the target >> >>>> > attribute. Which means we'd need to add a url param so that trap = is >> >>>> > caught. >> >>>> > >> >>>> >> >>>> It is not entirely a question of "nastiness" in adding a url param >> >>>> with regards to why it won't work in iOS (although imo I don't like >> >>>> it) - I have already presented valid technical reasons. >> >>>> >> >>>> With respect to achieving all our goals - not introducing a new API= , >> >>>> and fixing this bug that sorely needs fixing - ChildBrowser like yo= u >> >>>> proposed is the better bet then. So what should be the plan for thi= s? >> >>>> >> > > > > -- > @purplecabbage > risingj.com