Perhaps this in addition to a callback / dialog? > On 26 Oct. 2016, at 2:43 pm, Charles Warwick <char...@techstrategies.com.au> > wrote: > > Monte, Trevor, > > My preference for handling the overriding of HTTPS certificates would be by > adding the ability within libUrl to "get" the SSL certificate of a particular > site (for example a self-signed one), and then "add" that SSL certificate to > a CA store that is utilised by the libUrl library. > > This would allow you to retrieve the SSL certificates for any self-signed > sites and add them to the CA store during your application's startup. Then > you can use libUrl as normal (with libUrlSetSSLVerification set to true) and > those self-signed sites would be accessible. > > The advantage of this is that it would provide the same benefit that Trevor > is looking to achieve while still providing any application with protection > from SSL connections being hijacked even if they are using self-signed > certificates, rather than completing disregarding the signing identity of > communications. > > tsNet currently does allow you to specify a separate CA store than the system > one. If you are writing an application that connects to a server that is > self-signed, then you can download the server's certificate and call > tsNetCABundle with that certificate file. This will allow your application > to verify that the self-signed certificate is the same as what you downloaded > when you make requests against that server. > > It is on my task list to create another function in tsNet that allows you to > retrieve the SSL certificates for a specific connection so that you don't > have to download them separately. > > As a side note (for anyone that needs this right now), tsNet copies the > tsNetVerifySSLPeer (and tsNetCABundle) setting that is current at the time a > tsNetGet (or any other tsNet* call) function is called and stores it with the > request. This means you can change those settings at any time and it won't > affect any requests already in progress. So if you want to leave SSL > verification on and *just* disable it for one request, you can simply do: > > tsNetVerifySSLPeer false > tsNetGet(....) > tsNetVerifySSLPeer true > > Regards, > > Charles > > > > On 26/10/2016 10:24 AM, Trevor DeVore wrote: >> On Tue, Oct 25, 2016 at 2:36 PM, Monte Goulding <mo...@appisle.net> wrote: >> >>>> On 26 Oct. 2016, at 3:25 am, Trevor DeVore <li...@mangomultimedia.com> >>> wrote: >>>> https://github.com/trevordevore/livecode/commit/ >>> 6a5bc42abebca23e6b8aa611c8f0966b221441c6 <https://github.com/ >>> trevordevore/livecode/commit/6a5bc42abebca23e6b8aa611c8f0966b221441c6> >>> One thing I might as well say now as I’ll say it in review anyway is it >>> would be better to set individual hosts rather than the entire list in one >>> hit to reduce the risk of different user code clobbering each other. >> >> The intended use of libURLGetServersThatBypassCertificateVerification and >> libURLSetServersThatBypassCertificateVerification is for getting servers to >> store with your app prefs and for restoring the saved settings when your >> app starts up. I still need to add a handler that adds to the list. >> >> >>> It will also be simpler to use: >>> >>> - get url >>> - verification failure >>> - ask user if they want to trust the host anyway >>> - turn off verification for that host >>> >> In my original implementation in my custom version of libURL I set up a >> repeat loop around the code that fetches data from the server. My libURL >> library allows you to define a callback that would be called if an SSL >> cert error occurred. I would display a dialog that looks similar to the one >> you see in Safari and let the user decide. The logic looks like this: >> >> repeat >> get url >> no errors? exit repeat >> did an ssl error occur? >> is a callback defined? >> send the callback >> did user say bypass? add to list of servers that ignore >> verification and try again in next repeat loop >> did user say cancel? exit repeat >> end repeat >> >> It got the job done for what I needed. I am a little hesitant to add it in >> to libURL as I’m not entirely sure of the implications of the repeat loop. >> I was going to start with adding the ability to get/set the servers and add >> a server to the list. That way a developer could check the result >> themselves and prompt the user. >> >> Ideally it would all happen from within libURL though. I’m not sure I have >> the time to think through all of the implications and do the testing >> necessary to submit the change to libURL. >> >> Thoughts? >> > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
