override HTTPS certificate failure
Monte Goulding
monte at appisle.net
Tue Oct 25 20:46:41 EDT 2016
> 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
More information about the use-livecode
mailing list