> On Jul 11, 2015, at 4:58 PM, Bruce Pokras <bruc...@comcast.net> wrote: > > >> On Jul 11, 2015, at 9:26 AM, Richard Gaskin <ambassa...@fourthworld.com> >> wrote: >> >> Bruce Pokras wrote: >> >>> Recently, the app's requests for the access token kept resulting in >>> an error message. I tried a lot of differnt work-arounds. Nothing >>> helped. >>> >>> I finally posted my problem to an EPO forum for OPS users, and >>> included the error message which at the time made no sense to me. >>> From the response I received from OPS support, they had recently >>> changed from conventional SSL certificates to new “Extended >>> Validation” SSL certificates. Could there be something about the >>> Livecode implementation of https that is not compatible with these EV >>> certificates? Does that make sense? Here is the error message: >>> --- >>> error -Error with certificate at depth: 1 issuer = /OU=GlobalSign >>> Root CA - R2/O=GlobalSign/CN=GlobalSign subject = /C=BE/O=GlobalSign >>> nv-sa/CN=GlobalSign Extended Validation CA - SHA256 - G2 err >>> 7:certificate signature failure >>> — >>> Once I knew this to be related to SSL, I added >>> "libURLSetSSLVerification false” to the scripts. No more errors and >>> the app receives the access token without any problem. However, I >>> felt it might be useful to put this issue in front of this >>> knowledgeable group as both a warning and as a seed for discusion. >>> Why did Livecode work fine with the old SSL certificates, but does >>> not with the EV certificates? >> >> Thank you for posting that, Bruce. >> >> I've seen a similar issue with an app I make that uses a similar cert on the >> server we use for storage, but here the problem is intermittent so I've >> been reluctant to file a bug report until I can pin down a reliable recipe. >> >> Is this issue consistently reproducible for you? >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> ____________________________________________________________________ >> ambassa...@fourthworld.com http://www.FourthWorld.com >> > > Over the past week there were a couple of short periods of time (about 5 > minutes each) during which I was receiving the desired access token instead > of the error. In fact, right now with multiple attempts with > libURLSetSSLVerification set to “true” it worked fine all but one time. Of > course, I do not want to risk having even one failure when the fix is as easy > as setting libURLSetSSLVerification to “false”. (Oops, spoke too soon! Am now > consistently getting the error again when libURLSetSSLVerification is set to > “true”). > > One list member who e-mailed me directly suggested that it might be a > Livecode version issue with 7.0.5 giving the error because it was using an > older openssl but 7.0.6 was working fine. I am a dinosaur still using 6.0.2. > I will see if 7.0.6 makes any difference for me. > _______________________________________________ > 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
I started using 7.0.6 and with libURLSetSSLVerification is set to “true” I have not received a single certificate error. In fact, I just did an almost simultaneous test of 6.0.2 and 7.0.6 and 6.0.2 gave the certificate error with every attempt to obtain an access token, while 7.0.6 successfully retrieved an access token on every attempt. So it looks like I am upgrading! However, here is another mystery. The first time I opened the stack in 7.0.6 that had been developed under 6.0.2 I received an error message related to the “openstack” command in the stack script. It said that the value to which I had set the recursionlimit property “is not a number.” The value I used was 20000000. Looks like a number to me! (I am on a Mac, so the Windows issue does not effect me). I tried various numbers until I finally narrowed it down. Attempting to set the recursionlimit property to any number greater than 65535 gives me an error that that value is not a number. Also, setting the recursionlimit to a low number like 40 does not work as expected. After setting the recursionlimit property to 40 I typed “put the recursionlimit” into the message box and hit “return.” The number that it returned was in the high 30-thousands! I checked the bug reports and nothing like the above to anomalies has been reported. At one time I needed a much higher recursionlimit than the default 400000, so that is why I am using such a high number. Is anyone else seeing this issue? Regards, Bruce Pokras Blazing Dawn Software www.blazingdawn.com _______________________________________________ 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
