> On 26 Oct. 2016, at 11:24 am, Trevor DeVore <li...@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 _______________________________________________ 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
