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
