+1 on Joe Bower "Breaking SSL for InAppBrowser or Cordova itself would be really foolish"
+1 on Raman "a normal browser gives an option to the user in case of a unverifiable https link, so i suppose this should be the case for Cordova WebView as well as InAppBrowser, after all you are treating InAppBrowser as a normal browser window." I think is the right answer --Carlos On Wed, Aug 21, 2013 at 3:53 AM, Joe Bowser <bows...@gmail.com> wrote: > It's an open source plugin, which means you can implement your own > plugin and add this feature. I'm personally against adding this > feature. If you're using Android for the Enterprise, you can install > your own cert on all the devices you support so that this works and > have your network even more locked down. Breaking SSL for > InAppBrowser or Cordova itself would be really foolish, > > On Tue, Aug 20, 2013 at 10:50 PM, Singh, Ramandeep > <ramandeep.si...@barco.com> wrote: > > Wow, this is really a sad sad decision to not fix this issue (or add > this functionality in InAppBrowser). Please check these enterprise apps: > > > > https://itunes.apple.com/us/app/cinemate/id674386455?mt=8 > > https://play.google.com/store/apps/details?id=com.barco.cinemate > > > > These apps do require privately signed URL access and i had to hack my > way to make it work in InAppBrowser. Lot of people have commented in this > thread itself that they do need this functionality. As i mentioned earlier, > it's possible to make it work in the main Cordova WebView by overwriting > onReceivedSslError(), then why there is no such option in the InAppBrowser? > In that case, you should remove this option from the main Cordova WebView > too. > > > >>> Joe Bowser wrote: > >>> After reading the mailing list, it looks like this will NOT be added > to InAppBrowser, since there is very little reason to add it for a corp >> > VPN setup. (If your network is so secure, why do you need broken SSL?) > > > > Corporate networks or VPNs are secure that's why we usually can't verify > the https identity through an external certification authority. You can't > expect them to change https to http for all internal sites just because > InAppBrowser doesn't handle it or give an option to the user if he wants to > continue with the link or block it. > > > > If you compare InAppBrowser to a normal browser, a normal browser gives > an option to the user in case of a unverifiable https link, so i suppose > this should be the case for Cordova WebView as well as InAppBrowser, after > all you are treating InAppBrowser as a normal browser window. > > > > Regards, > > Raman > > > > -----Original Message----- > > From: Singh, Ramandeep > > Sent: 24 July 2013 10:59 > > To: 'Josh Soref'; dev@cordova.apache.org > > Subject: RE: Ignoring SSL Errors for InAppBrowser > > > > Hi > > > > Many enterprise apps require functionality to access self-signed URLs so > this option is really missing in the InAppBrowser. In the main PhoneGap web > view, one can overwrite a public function (onReceivedSslError()) to allow > self-signed URLs so something similar should be possible in the > InAppBrowser too. You can check the following app which has been made using > PhoneGap: > > > > Regards, > > Raman > > > > -----Original Message----- > > From: Josh Soref [mailto:jso...@blackberry.com] > > Sent: 24 July 2013 01:51 > > To: dev@cordova.apache.org > > Cc: Singh, Ramandeep > > Subject: RE: Ignoring SSL Errors for InAppBrowser > > > > A simple flag is definitely wrong... a static whitelist could be > interesting. > > > > Are there real use cases beyond `localhost`? > > > > If someone whitelists any site that isn't on the local device, then when > I'm in an Internet Café, the wrong thing can happen (and in certain cases, > the wrong thing probably will happen). > > > > Making it easy for people to write broken applications doesn't seem to > be a good "value-add". Unfortunately, people will do the wrong thing and > not care about their customers.... > > > > But, this is just my personal opinion.... > > > >> -----Original Message----- > >> From: Shazron [mailto:shaz...@gmail.com] > >> Sent: Tuesday, July 23, 2013 3:40 PM > >> To: dev@cordova.apache.org > >> Cc: ramandeep.si...@barco.com > >> Subject: Re: Ignoring SSL Errors for InAppBrowser > >> > >> Why the js callback and not just the static white-list? > >> the js callback allows someone to change the security rules at runtime > >> which could be a hole I suppose. > >> > >> > >> On Tue, Jul 23, 2013 at 12:26 PM, Andrew Grieve > >> <agri...@chromium.org>wrote: > >> > >> > https://issues.apache.org/jira/browse/CB-3576 > >> > > >> > There are pulls request for adding to iOS & Android that add: > >> > > >> > window.open(url, '_blank', 'location=yes,validatessl=no'); > >> > > >> > > >> > Given that this is security-related though, I wanted to get more > >> > eyes on it. Other proposals are to have each questionable cert go > >> > through a JS > >> > callback: > >> > > >> > var iab = window.open(...); > >> > iab.onSSLError = function(url) { > >> > return !!/^https://myalloweddomain.com\//.exec(url); > >> > }; > >> > > >> > Or to add a white-list to your config.xml for allowed self-signed > https: > >> > addresses. > >> > > >> > If your app is not going to validate ssl certs, then perhaps > >> > restricting the scope of it isn't really increasing security > >> > anyways. It's certainly useful for development to be able to turn it > >> > off, but maybe for that reason we should turn it off globally with a > <preference> tag? > >> > > >> > Thoughts? Willingness from other platforms? > >> > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > > This message is subject to the following terms and conditions: > http://www.barco.com/en/maildisclaimer > -- Carlos Santana <csantan...@gmail.com>
