How is opening a URL in a web browser a security risk to the Cordova code shaz?
Jesse: a declarative approach just means devs need to manually add the URL param themselves (quirk). A fair trade while we wait for the beefier programmatic child browser API. On May 20, 2012 6:45 AM, "Shazron" <shaz...@gmail.com> wrote: > 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= to circumvent the whitelist check, think about it - > it's a big hole. > > On Sat, May 19, 2012 at 8:12 PM, Jesse <purplecabb...@gmail.com> wrote: > > Shaz: I believe Brian is proposing you look for urls > > containing _cordova-target= 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: > > <a href="http://somwhere.com"; target="_blank">asdf<a> > > > > 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=blank > > > > So either native code has to watch for links with '_cordova-target=' 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 > would > > determine if the clicked item was an <a> 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 <shaz...@gmail.com> 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 <b...@brian.io> 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/Foundation/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 href=http://somwhere.com&_cordova-target=blank > target=blank>asdf<.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 <shaz...@gmail.com> 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 <b...@brian.io> wrote: > >> >>> Sorry shaz, I must be dense but I missed the technical reasons? > >> >>> On May 19, 2012 11:48 AM, "Shazron" <shaz...@gmail.com> wrote: > >> >>> > >> >>>> > The method I'm proposing > >> >>>> > assumes all link events are trapped, inspected for a url param, > and > >> 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 > you > >> >>>> proposed is the better bet then. So what should be the plan for > this? > >> >>>> > >> > > > > > > > > -- > > @purplecabbage > > risingj.com >
