Bob,
Thanks for replying - I suspect you're right as to the immediate cause and
where something has changed (it might just be about a new certificate, for
example).
However, my real question is why it works in terminal but not using LC
"shell"; although calling the same service does work via LC "shell" on my dev
machine (including as a standalone).
Where can one affect the context in which a shell command is executing?
thanks,
Ben
On 20/01/2015 19:12, Bob Sneidar wrote:
I suspect whatever system you are connecting to has modified in some way how it
encrypts data using SSL. Sounds crazy, but Microsoft recently did something to
their TLS in their cloud offerings that summarily prevented an entire series of
Konica brand copiers from sending email through Exchange Online. Other series
Konicas were fine, and other manufacturers didn’t seem to have a problem
either. I was the only one saying Microsoft had made changes to their TLS. No
one would listen, citing all the other copiers that still worked.
Finally Konica released a bulletin telling us to install special firmware and
make some changes in the security settings on the affected machines. What
settings you ask? Why, the TLS settings of course!
Bob S
On Jan 20, 2015, at 10:59 , Ben Rubinstein <benr...@cogapp.com> wrote:
An app built in LC, sitting on an old box (PPC Mac Mini running 10.4.11) has
for several years happily been running a few times a day to perform a batch job
involving retrieve some data from a remote system, processing it, and pushing a
report to a new location.
Recently, it's not been updating correctly, and investigation has shown that
the cause is a failure to retrieve the remote data.
The remote system (a third-party SaaS product) has a REST interface, accessed
with simple basic authentication over HTTPS. I'm not aware that anything has
changed in their API recently.
When I first wrote this app, I found that LC didn't correctly deal with the SSL
portion (I forget the details); so I recoded it to use the shell function to
invoke curl to retrieve each element.
This has worked fine for a long time. But now the shell command is returning
code 35, which according to man curl is:
35 SSL connect error. The SSL handshaking failed.
So the weird thing is:
- if I run this app on my dev machine (Intel Mac running 10.8.5), it works
fine, happily invoking curl and getting the result
- if I run the curl command in Terminal on the target machine, it works fine
and retrieves the data
- if I create a shell script to run the curl command on the target machine, and
invoke that shell script in Terminal, it works fine and retrieves the data
- if I modify the app to use 'shell' to run that shell script, instead of
calling curl directly, it fails with code 35 again.
So curl, and shell, are happy on that machine; but using shell in an LC app to
either invoke curl directly, or run a batch script which invokes curl, makes
SSL fail.
I've marked this possibly OT because I don't think it's necessarily an LC
problem. I get the same result with a version of the app built in 2011 from LC
4.6.4 as with one built now with LC 6.5.2. But then again, I'm not aware that
anything has changed on the machine where this runs.
Something must have changed; my guess is that it is something in the setup of
the remote service. But the nature of that change doesn't disturb curl or
shell running under Terminal on my target machine; nor when invoked from LC on
my dev machine.
I'm guessing it must be something to do with the environment in which the shell
command operates when invoked from LC, as opposed to launching a terminal
window. This goes considerably outside my knowledge area, so I'm appealing for
suggestions as to where to investigate...
TIA
Ben
_______________________________________________
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
