override HTTPS certificate failure

[Monte Goulding]

> On 26 Oct. 2016, at 11:24 am, Trevor DeVore <lists at mangomultimedia.com> wrote:
> 
>> 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.

Hmm… I’ll still worry that it will be used to clobber others but I can see the utility of setting a full list at startup.
> 
> 
>> 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?

One of the issues is this will mean the callback is defined globally which could be an issue although if we include a common but overridable dialog in the IDE and as a standalone inclusion it would seem unlikely to be a huge concern. Charles may have some feedback from a tsNet perspective. Particularly with async calls it might be interesting to pop up a modal…

I wonder if it should be a bit like ask and answer where it just presents a dialog if there’s one with the correct name instead of a callback?

Cheers

Monte