CURL won't run via "SHELL"

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

CURL won't run via "SHELL"

Jerad Hoff-2
The non-profit here uses Twilio to send out emergency notifications when we need to get teams out in the field. It’s a phenomenal platform that while extraordinarily powerful, yet it still maintains a very simple interface I can trigger (and understand) with Lasso 8.5.

Something like this fires off a text message:

[Include_URL: 'https://api.twilio.com/2010-04-01/Accounts/XXX/Messages', -Username='XXX', -Password='XXX', -POSTParams=(Array: 'From'='+15555555555', 'To'='+ 15555555555', 'Body'=($NOTIFY_BODY)), -NoData]

Loop that through a bunch of records and bam, everyone who needs to know about something is in the know.

Unfortunately Twilio will no longer accept TLS 1.0 connections anymore and that means I have to drop using Include_URL. Bummer, I know.

So I found a great tag on TagSwap called “SHELL” written by Jason Huck that I think I can use in combination with CURL to replicate the Include_URL functionality*. So this:

[INLINE: -username=‘user', -password=‘pwd', -nothing]
        [SHELL: '/usr/local/bin/curl -V']
[/INLINE]

Produces this:

curl 7.60.0 (x86_64-apple-darwin10.8.0) libcurl/7.60.0 OpenSSL/1.1.0h zlib/1.2.3 Release-Date: 2018-05-16 Protocols: http https blah blah blah

But for some reason when I actually attempt to reach out to a web server, everything falls apart:

[INLINE: -username=‘user', -password=‘pwd', -nothing]
        [SHELL: '/usr/local/bin/curl https://www.apple.com/' <https://www.apple.com/'>]
[/INLINE]

Produces gibberish:

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 could not lookup DNS configuration info service: (ipc/send) invalid destination port 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: www.apple.com

 If I copy and paste that command directly into the server’s command line, it pulls down Apple’s homepage.

Since SHELL relies on OS_Process, I figured I’d try to figure that one out. This:

[Var: 'myProcess' = (OS_Process)]
[$myProcess->(Open: '/usr/local/bin/curl', (Array: '-V'))]
[Encode_HTML: $myProcess->Read]
[$myProcess->Close]

Works as expected, however:

[Var: 'myProcess' = (OS_Process)]
[$myProcess->(Open: '/usr/local/bin/curl', (Array: 'https://www.apple.com/'))]
[Encode_HTML: $myProcess->Read]
[$myProcess->Close]

Returns a page devoid of any data at all. I pointed it to my own server and no HTTP or HTTPS requests are coming through (tried both). My guess is that it’s bombing the same way as using the SHELL tag, but at least the tag gives out some kind of output that shows CURL was called, but something went wrong.

It’s a bit tough to troubleshoot since everything is going on behind the scenes. Any ideas or guidance would be greatly appreciated.

Thanks,

  - Jerad



* So if you recall previous emails about CURL, I was having issues because we have an old 10.6 server. I tried installing 8.5, 8.6, and 9 on a test machine running High Sierra and I could never get the install working. Since apparently I can’t move to a newer OS, I was stuck trying to update the individual pieces of software on the old server. Surprising the heck out of me, I managed to compile and build the latest version of OpenSSL and then compile and build a version of CURL that is pointed at the new OpenSSL. Because both programs install their stuff in places Apple doesn’t, there wasn’t any risk to corrupting the current server configuration.

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

stevepiercy
The curl error message is not very clear:

     curl: (6) Could not resolve host: www.apple.com

It actually means that you are using an old version of SSL, not
TLS v1.2.

Try this, which is verbose mode, using TLS v1.2, suppressing
output from the response:

     curl -v --tlsv1.2 https://www.apple.com/ > /dev/null

If that fails, then your version of curl and/or OS does not
support TLS v1.2.

If it passes, then tighten up the code, get ride of unnecessary
colons and brackets to save typing and make it readable.

     shell('/usr/local/bin/curl --tlsv1.2 https://www.apple.com/');

Or:

     local('myos') = os_process('/usr/local/bin/curl',
array('--tlsv1.2', 'https://www.apple.com/'));
     #myos->read;
     #myos->readerror;

A lot of the stuff you can't figure out is either in the curl
manual or a quick visit to Stack Overflow.

https://curl.haxx.se/docs/manpage.html
https://stackoverflow.com/search?q=curl%3A+%286%29+Could+not+resolve+host%3A

Finally, if you can't upgrade your current environment, I'd spin
up a server that runs a modern OS and language, and use that as
a proxy to Twilio.  For $5/month you could have a server running
a simple Pyramid app that receives the request and acts as a
proxy to Twilio.  Or even better, use lambdas on AWS with
Python's `requests` library and go "serverless", and that would
probably be within the "free tier".  It's a lot cheaper than
paying license fees.

https://docs.aws.amazon.com/lambda/latest/dg/welcome.html

--steve


On 5/23/18 at 12:07 AM, [hidden email] (Jerad Hoff) pronounced:

>The non-profit here uses Twilio to send out emergency
>notifications when we need to get teams out in the field.
>It’s a phenomenal platform that while extraordinarily
>powerful, yet it still maintains a very simple interface I can
>trigger (and understand) with Lasso 8.5.
>Something like this fires off a text message:
>
>[Include_URL:
>'https://api.twilio.com/2010-04-01/Accounts/XXX/Messages',
>-Username='XXX', -Password='XXX', -POSTParams=(Array:
>'From'='+15555555555', 'To'='+ 15555555555',
>'Body'=($NOTIFY_BODY)), -NoData]
>
>Loop that through a bunch of records and bam, everyone who
>needs to know about something is in the know.
>
>Unfortunately Twilio will no longer accept TLS 1.0 connections
>anymore and that means I have to drop using Include_URL.
>Bummer, I know.
>
>So I found a great tag on TagSwap called “SHELL” written by
>Jason Huck that I think I can use in combination with CURL to
>replicate the Include_URL functionality*. So this:
>
>[INLINE: -username=‘user', -password=‘pwd', -nothing]
>[SHELL: '/usr/local/bin/curl -V']
>[/INLINE]
>
>Produces this:
>
>curl 7.60.0 (x86_64-apple-darwin10.8.0) libcurl/7.60.0
>OpenSSL/1.1.0h zlib/1.2.3 Release-Date: 2018-05-16 Protocols:
>http https blah blah blah
>
>But for some reason when I actually attempt to reach out to a
>web server, everything falls apart:
>
>[INLINE: -username=‘user', -password=‘pwd', -nothing]
>[SHELL: '/usr/local/bin/curl https://www.apple.com/' <https://www.apple.com/'>]
>[/INLINE]
>
>Produces gibberish:
>
>% Total % Received % Xferd Average Speed Time Time Time Current
>Dload Upload Total Spent Left Speed 0 0 could not lookup DNS
>configuration info service: (ipc/send) invalid destination port
>0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not
>resolve host: www.apple.com
>
>If I copy and paste that command directly into the server’s
>command line, it pulls down Apple’s homepage.
>
>Since SHELL relies on OS_Process, I figured I’d try to figure that one out. This:
>
>[Var: 'myProcess' = (OS_Process)]
>[$myProcess->(Open: '/usr/local/bin/curl', (Array: '-V'))]
>[Encode_HTML: $myProcess->Read]
>[$myProcess->Close]
>
>Works as expected, however:
>
>[Var: 'myProcess' = (OS_Process)]
>[$myProcess->(Open: '/usr/local/bin/curl', (Array: 'https://www.apple.com/'))]
>[Encode_HTML: $myProcess->Read]
>[$myProcess->Close]
>
>Returns a page devoid of any data at all. I pointed it to my
>own server and no HTTP or HTTPS requests are coming through
>(tried both). My guess is that it’s bombing the same way as
>using the SHELL tag, but at least the tag gives out some kind
>of output that shows CURL was called, but something went wrong.
>
>It’s a bit tough to troubleshoot since everything is going on
>behind the scenes. Any ideas or guidance would be greatly appreciated.
>
>Thanks,
>
>- Jerad
>
>
>
>* So if you recall previous emails about CURL, I was having
>issues because we have an old 10.6 server. I tried installing
>8.5, 8.6, and 9 on a test machine running High Sierra and I
>could never get the install working. Since apparently I can’t
>move to a newer OS, I was stuck trying to update the individual
>pieces of software on the old server. Surprising the heck out
>of me, I managed to compile and build the latest version of
>OpenSSL and then compile and build a version of CURL that is
>pointed at the new OpenSSL. Because both programs install their
>stuff in places Apple doesn’t, there wasn’t any risk to
>corrupting the current server configuration.
>#############################################################
>
>This message is sent to you because you are subscribed to
>the mailing list Lasso [hidden email]
>Official list archives available at http://www.lassotalk.com
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<[hidden email]>               <http://www.stevepiercy.com/>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Da'oud Rashid
Hi Jerad,

I noticed that you’re using a newer version of curl (7.60), did you overwrite Mac OS X 10.8’s default version of curl? I’m not sure if that will work, but you can try explicitly setting the following options for the request:

Local(‘curlOptions’ = Array('--trace-ascii’, 'absolute/path/to/traceFile.txt’, '--tlsv1.2’));

The trace file will let you see what happens with the request. Forcing TLS 1.2 has also helped me resolve issues with blank server responses.

You may also need to explicitly set the following options:

#curlOptions->Insert('-X’);
#curlOptions->Insert(‘POST’);
#curlOptions->Insert('-H’);
#curlOptions->Insert('Content-Type:application/x-www-form-urlencoded’);

It looks like you also need the following for authentication:

#curlOptions->Insert(‘-u’, 'ACCOUNT_SID:AUTH_TOKEN’);

A complete solution would look something like the following (note this is not tested, but based on some code I use with PayPal):

[ //Lasso

local(
        'curl' = Null,
        'paramsToSend' = Array('Body' = 'text to send', 'From' = 'sending_number', 'To' = 'receiving_number'),
        'curlOptions' = Array,
        'requestParams' = String,
        'response' = String,
        'error' = String
);

#curlOptions->Insert('--trace-ascii');
#curlOptions->Insert('absolute/path/to/traceFile.txt');
#curlOptions->Insert('--tlsv1.2’);

// curl's manual says the following should be implied by sending the params using the -d option.
// I've left them in, as I had trouble getting my requests to work without them.

#curlOptions->Insert('-X’);
#curlOptions->Insert('POST’);
#curlOptions->Insert('-H');
#curlOptions->Insert('Content-Type:application/x-www-form-urlencoded’);

// You need to also include the following to authenticate correctly with Twilio:
#curlOptions->Insert(‘-u’, 'ACCOUNT_SID:AUTH_TOKEN’);

#curlOptions->Insert('https://api.twilio.com/2010-04-01/Accounts/ACCOUNT_SID/Messages');

// Prepare the params to send
Loop(#paramsToSend->Size);
        #requestParams += (#requestParams?'&') + Encode_URL(#paramsToSend->Get(LoopCount)->First) + '=' + Encode_URL(#paramsToSend->Get(LoopCount)->Second);
/Loop;

#curlOptions->Insert('-d');
#curlOptions->Insert(#requestParams);

// This code runs on Mac OS X 10.11 (which also lacks TLS 1.2 support).
// Note the use of curl 7.55.1, installed using Homebrew.
// I had difficulties with curl 7.57, but they may have been resolved with the 7.60 release

#curl = OS_Process('/usr/local/Cellar/curl/7.55.1/bin/curl', #curlOptions);

#response = String(#curl->read);
#error = String(#curl->readError);
#curl->close;

// Do stuff with response or error here

]

Hope this helps!

Kind regards,
Da’oud

> On 23 May 2018, at 09:30, Steve Piercy - Website Builder <[hidden email]> wrote:
>
> The curl error message is not very clear:
>
>    curl: (6) Could not resolve host: www.apple.com
>
> It actually means that you are using an old version of SSL, not TLS v1.2.
>
> Try this, which is verbose mode, using TLS v1.2, suppressing output from the response:
>
>    curl -v --tlsv1.2 https://www.apple.com/ > /dev/null
>
> If that fails, then your version of curl and/or OS does not support TLS v1.2.
>
> If it passes, then tighten up the code, get ride of unnecessary colons and brackets to save typing and make it readable.
>
>    shell('/usr/local/bin/curl --tlsv1.2 https://www.apple.com/');
>
> Or:
>
>    local('myos') = os_process('/usr/local/bin/curl', array('--tlsv1.2', 'https://www.apple.com/'));
>    #myos->read;
>    #myos->readerror;
>
> A lot of the stuff you can't figure out is either in the curl manual or a quick visit to Stack Overflow.
>
> https://curl.haxx.se/docs/manpage.html
> https://stackoverflow.com/search?q=curl%3A+%286%29+Could+not+resolve+host%3A
>
> Finally, if you can't upgrade your current environment, I'd spin up a server that runs a modern OS and language, and use that as a proxy to Twilio.  For $5/month you could have a server running a simple Pyramid app that receives the request and acts as a proxy to Twilio.  Or even better, use lambdas on AWS with Python's `requests` library and go "serverless", and that would probably be within the "free tier".  It's a lot cheaper than paying license fees.
>
> https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
>
> --steve
>
>
> On 5/23/18 at 12:07 AM, [hidden email] (Jerad Hoff) pronounced:
>
>> The non-profit here uses Twilio to send out emergency notifications when we need to get teams out in the field. It’s a phenomenal platform that while extraordinarily powerful, yet it still maintains a very simple interface I can trigger (and understand) with Lasso 8.5.
>> Something like this fires off a text message:
>>
>> [Include_URL: 'https://api.twilio.com/2010-04-01/Accounts/XXX/Messages', -Username='XXX', -Password='XXX', -POSTParams=(Array: 'From'='+15555555555', 'To'='+ 15555555555', 'Body'=($NOTIFY_BODY)), -NoData]
>>
>> Loop that through a bunch of records and bam, everyone who needs to know about something is in the know.
>>
>> Unfortunately Twilio will no longer accept TLS 1.0 connections anymore and that means I have to drop using Include_URL. Bummer, I know.
>>
>> So I found a great tag on TagSwap called “SHELL” written by Jason Huck that I think I can use in combination with CURL to replicate the Include_URL functionality*. So this:
>>
>> [INLINE: -username=‘user', -password=‘pwd', -nothing]
>> [SHELL: '/usr/local/bin/curl -V']
>> [/INLINE]
>>
>> Produces this:
>>
>> curl 7.60.0 (x86_64-apple-darwin10.8.0) libcurl/7.60.0 OpenSSL/1.1.0h zlib/1.2.3 Release-Date: 2018-05-16 Protocols: http https blah blah blah
>>
>> But for some reason when I actually attempt to reach out to a web server, everything falls apart:
>>
>> [INLINE: -username=‘user', -password=‘pwd', -nothing]
>> [SHELL: '/usr/local/bin/curl https://www.apple.com/' <https://www.apple.com/'>]
>> [/INLINE]
>>
>> Produces gibberish:
>>
>> % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 could not lookup DNS configuration info service: (ipc/send) invalid destination port 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: www.apple.com
>>
>> If I copy and paste that command directly into the server’s command line, it pulls down Apple’s homepage.
>>
>> Since SHELL relies on OS_Process, I figured I’d try to figure that one out. This:
>>
>> [Var: 'myProcess' = (OS_Process)]
>> [$myProcess->(Open: '/usr/local/bin/curl', (Array: '-V'))]
>> [Encode_HTML: $myProcess->Read]
>> [$myProcess->Close]
>>
>> Works as expected, however:
>>
>> [Var: 'myProcess' = (OS_Process)]
>> [$myProcess->(Open: '/usr/local/bin/curl', (Array: 'https://www.apple.com/'))]
>> [Encode_HTML: $myProcess->Read]
>> [$myProcess->Close]
>>
>> Returns a page devoid of any data at all. I pointed it to my own server and no HTTP or HTTPS requests are coming through (tried both). My guess is that it’s bombing the same way as using the SHELL tag, but at least the tag gives out some kind of output that shows CURL was called, but something went wrong.
>>
>> It’s a bit tough to troubleshoot since everything is going on behind the scenes. Any ideas or guidance would be greatly appreciated.
>>
>> Thanks,
>>
>> - Jerad
>>
>>
>>
>> * So if you recall previous emails about CURL, I was having issues because we have an old 10.6 server. I tried installing 8.5, 8.6, and 9 on a test machine running High Sierra and I could never get the install working. Since apparently I can’t move to a newer OS, I was stuck trying to update the individual pieces of software on the old server. Surprising the heck out of me, I managed to compile and build the latest version of OpenSSL and then compile and build a version of CURL that is pointed at the new OpenSSL. Because both programs install their stuff in places Apple doesn’t, there wasn’t any risk to corrupting the current server configuration.
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Steve Piercy              Website Builder              Eugene, OR
> <[hidden email]>               <http://www.stevepiercy.com/>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
> the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Jerad Hoff-2
Thank you guys for responding! I appreciate the help.

I did not overwrite the existing OpenSSL or CURL installations.

The old locations:

/usr/bin/openssl
/usr/bin/curl

New locations:

/usr/local/bin/openssl
/usr/local/bin/curl

When I compiled curl, I had to point to the new openssl locations (which took awhile to figure out, I kept getting mismatch version numbers for the header and library), I used this:

CPPFLAGS="-I/usr/local/include/openssl" LDFLAGS="-L/usr/local/lib" ./configure --with-ssl=/usr/local/ssl


When I’m on the command line of the server, the following works just fine with Twilio:

/usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/ACCOUNT_SID/Messages \
--data-urlencode “Body=Hi mom." \
--data-urlencode "From=+15555555555" \
--data-urlencode "To=+15555555555" \
-u ACCOUNT_SID: AUTH_TOKEN

Using port 8443 means I have to be using TLS 1.2 or it won’t work (and it does). Works 100% of the time from the command line, I get the text message without issue. I was actually a bit excited, I figured I’d break the server or something trying to get CURL updated to use TLS 1.2. I figured that was the hard part because Lasso just executes shell commands right? Guess not.

Yet when I try to use Lasso to execute the exact same command:

[SHELL: '/usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/ACCOUNT_SID/Messages --data-urlencode “Body=Hi mom." --data-urlencode "From=+ 15555555555" --data-urlencode "To=+ 15555555555" -u ACCOUNT_SID: AUTH_TOKEN’]

I get this gibberish that CURL can’t resolve the host:

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Scould not lookup DNS configuration info service: (ipc/send) invalid destination port pent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: api.twilio.com <http://api.twilio.com/>

I tried adding —verbose, which was interesting because I basically get the same gibberish, but it starts with telling me that I don’t need the -X POST because it’s inferred (I don’t get that error when I type this out in the command line). I did try removing the -X POST just in case, all that did is give me the usual gibberish again.

I tried replacing the hostname with the IP address of the server, that finally changed the error message to where it was hinting there was a TLS 1.2 issue again. I added the -k flag which ignores certificate issues and suddenly the code works as expected. I’m not sure why it works from the command line when I type it in but gives an error when lasso does it, but I do know it’s using the new CURL because the old version of curl still gives a protocol error from Twilio, even with the -k flag.

Using -k is obviously not ideal. I’m going to experiment with the —trace-ascii command that was suggested to see if I can find out what the difference is between when lasso executes a shell command and when I do.

Thanks again guys! With Lasso being a dead product, I really appreciate the fact there are still folks like you hanging around to help out non-programmers like me. Oh, and sorry I’m still an old bracket guy, I never moved to LassoScript. I apologize if it makes your head hurt reading old code like that...

  - Jerad


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Da'oud Rashid
Hi Jerad,

No worries at all, I’m happy to try and help (and I’m sorry my suggestions didn’t solve the issue).

Good luck!

Kind regards,
Da'oud

> On 23 May 2018, at 15:34, Jerad Hoff <[hidden email]> wrote:
>
> Thank you guys for responding! I appreciate the help.
>
> I did not overwrite the existing OpenSSL or CURL installations.
>
> The old locations:
>
> /usr/bin/openssl
> /usr/bin/curl
>
> New locations:
>
> /usr/local/bin/openssl
> /usr/local/bin/curl
>
> When I compiled curl, I had to point to the new openssl locations (which took awhile to figure out, I kept getting mismatch version numbers for the header and library), I used this:
>
> CPPFLAGS="-I/usr/local/include/openssl" LDFLAGS="-L/usr/local/lib" ./configure --with-ssl=/usr/local/ssl
>
>
> When I’m on the command line of the server, the following works just fine with Twilio:
>
> /usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/ACCOUNT_SID/Messages \
> --data-urlencode “Body=Hi mom." \
> --data-urlencode "From=+15555555555" \
> --data-urlencode "To=+15555555555" \
> -u ACCOUNT_SID: AUTH_TOKEN
>
> Using port 8443 means I have to be using TLS 1.2 or it won’t work (and it does). Works 100% of the time from the command line, I get the text message without issue. I was actually a bit excited, I figured I’d break the server or something trying to get CURL updated to use TLS 1.2. I figured that was the hard part because Lasso just executes shell commands right? Guess not.
>
> Yet when I try to use Lasso to execute the exact same command:
>
> [SHELL: '/usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/ACCOUNT_SID/Messages --data-urlencode “Body=Hi mom." --data-urlencode "From=+ 15555555555" --data-urlencode "To=+ 15555555555" -u ACCOUNT_SID: AUTH_TOKEN’]
>
> I get this gibberish that CURL can’t resolve the host:
>
> % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Scould not lookup DNS configuration info service: (ipc/send) invalid destination port pent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: api.twilio.com <http://api.twilio.com/>
>
> I tried adding —verbose, which was interesting because I basically get the same gibberish, but it starts with telling me that I don’t need the -X POST because it’s inferred (I don’t get that error when I type this out in the command line). I did try removing the -X POST just in case, all that did is give me the usual gibberish again.
>
> I tried replacing the hostname with the IP address of the server, that finally changed the error message to where it was hinting there was a TLS 1.2 issue again. I added the -k flag which ignores certificate issues and suddenly the code works as expected. I’m not sure why it works from the command line when I type it in but gives an error when lasso does it, but I do know it’s using the new CURL because the old version of curl still gives a protocol error from Twilio, even with the -k flag.
>
> Using -k is obviously not ideal. I’m going to experiment with the —trace-ascii command that was suggested to see if I can find out what the difference is between when lasso executes a shell command and when I do.
>
> Thanks again guys! With Lasso being a dead product, I really appreciate the fact there are still folks like you hanging around to help out non-programmers like me. Oh, and sorry I’m still an old bracket guy, I never moved to LassoScript. I apologize if it makes your head hurt reading old code like that...
>
>  - Jerad
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Jerad Hoff-2
I appreciated the note, it got me thinking and headed in the right direction. It’s interesting, I failed to notice that in my testing, I forgot I’d replaced the api.twilio.com <http://api.twilio.com/> domain name with the IP. Today, after testing a few different pieces of code from URL_Include to the SHELL tag, I noticed the IP was still in there and switched it back to the domain name. It instantly started failing again, saying it can’t resolve the host. I’ll leave the IP in there for now, but man does that leave me hanging if they update their IP.

For fun, I did do [SHELL: ‘nslookup api.twilio.com <http://api.twilio.com/>’] and it came back with the full result of information. It’s just CURL that apparently can’t figure out DNS when being called via lasso.

The way lasso executes programs via the command line is definitely different than typing it in yourself. My best guess is it has something to do with environmental variables - the lasso user doesn’t have a $HOME or anything like a “normal” user on the system. It is just a guess though, but I don’t think it’s my new versions of OpenSSL/CURL because if I use the “old” CURL via lasso, I get the same DNS issue. Maybe it’s something unique to Mac OS X 10.6?

Thanks again!


> On May 23, 2018, at 2:16 PM, Da'oud Rashid <[hidden email] <mailto:[hidden email]>> wrote:
>
> Hi Jerad,
>
> No worries at all, I’m happy to try and help (and I’m sorry my suggestions didn’t solve the issue).
>
> Good luck!
>
> Kind regards,
> Da'oud

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

stevepiercy
What is the curl command you use?

What is the output of the curl command?

Can you turn off HTML formatting before sending mail to the
list?  This is invalid syntax and curly quotes are evil:

>[SHELL: ‘nslookup api.twilio.com <http://api.twilio.com/>’]

--steve


On 5/24/18 at 12:06 AM, [hidden email] (Jerad Hoff) pronounced:

>I appreciated the note, it got me thinking and headed in the
>right direction. It’s interesting, I failed to notice that in
>my testing, I forgot I’d replaced the api.twilio.com
><http://api.twilio.com/> domain name with the IP. Today, after
>testing a few different pieces of code from URL_Include to the
>SHELL tag, I noticed the IP was still in there and switched it
>back to the domain name. It instantly started failing again,
>saying it can’t resolve the host. I’ll leave the IP in
>there for now, but man does that leave me hanging if they
>update their IP.
>
>For fun, I did do [SHELL: ‘nslookup api.twilio.com
><http://api.twilio.com/>’] and it came back with the full
>result of information. It’s just CURL that apparently can’t
>figure out DNS when being called via lasso.
>
>The way lasso executes programs via the command line is
>definitely different than typing it in yourself. My best guess
>is it has something to do with environmental variables - the
>lasso user doesn’t have a $HOME or anything like a
>“normal” user on the system. It is just a guess though, but
>I don’t think it’s my new versions of OpenSSL/CURL because
>if I use the “old” CURL via lasso, I get the same DNS
>issue. Maybe it’s something unique to Mac OS X 10.6?
>
>Thanks again!
>
>
>>On May 23, 2018, at 2:16 PM, Da'oud Rashid <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>Hi Jerad,
>>
>>No worries at all, I’m happy to try and help (and I’m sorry my suggestions didn’t solve
>the issue).
>>
>>Good luck!
>>
>>Kind regards,
>>Da'oud
>
>#############################################################
>
>This message is sent to you because you are subscribed to
>the mailing list Lasso [hidden email]
>Official list archives available at http://www.lassotalk.com
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<[hidden email]>               <http://www.stevepiercy.com/>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Jerad Hoff-2
Sorry about the formatting.

Here is the command I use:

[SHELL: '/usr/local/bin/curl -k -X POST https://api.twilio.com:8443/2010-04-01/Accounts/UID/Calls --data-urlencode "Url=https://myserver.com/call_alert.lasso?ID=531&STUFF=111111&FILE=Test.mp3" --data-urlencode "From=+15555555555" --data-urlencode "To=+ 15555555555" -u UID:KEY’]

I get the dreaded CURL curl: (6) Couldn't resolve host error. If I copy and paste the above into the command line directly, it works as expected. If I change the domain name to the IP address of the target server, it works in lasso (it also works directly in the command line). Here is the output in its raw glory:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0   could not lookup DNS configuration info service: (ipc/send) invalid destination port
  0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Could not resolve host: api.twilio.com
* Closing connection 0
curl: (6) Could not resolve host: api.twilio.com

So I just noticed the" destination port" part of the error. If I remove the special testing port and let it default to 80, it works with the domain name (the special port is to test against Twilio’s upcoming TLS 1.2 requirement). This makes me feel a bit better than when Twilio switches over their service to default to TLS 1.2, I’ll be able to change my code back to using a domain name instead of an IP address. It still doesn’t answer why if I copy and paste the command into a terminal window (ssh’d into the lasso server) it works fine, run it from Lasso and I can’t use the domain name.

Thanks!

  - Jerad

> On May 24, 2018, at 12:40 AM, Steve Piercy - Website Builder <[hidden email]> wrote:
>
> What is the curl command you use?
>
> What is the output of the curl command?
>
> Can you turn off HTML formatting before sending mail to the list?  This is invalid syntax and curly quotes are evil:
>
>> [SHELL: ‘nslookup api.twilio.com <http://api.twilio.com/>’]
>
> --steve


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

stevepiercy
If you want to force TLS v1.2 in the curl request, use the
argument `--tlsv1.2`.

https://curl.haxx.se/docs/manpage.html#--tlsv12

Without it, the request may default to a lesser protocol and
fail with exit code 6 or other, depending on the server to which
the request is made and its support for TLS protocols.

Do not use `-k`.  This will avoid successful negotiation and is
wrong, unless you are within a company network's VPN and using
self-signed certificates on the remote server.

Include the `-v` argument for more information.

The output is never gibberish.  It always has meaning, although
it may be misleading or not understandable.  I've snipped out
the progress meter and other information below.

My non-macOS curl was installed via brew, so its location may be different.

$ /usr/local/Cellar/curl/7.55.1/bin/curl  --tlsv1.2 -v
https://api.twilio.com/2010-04-01/Accounts/UID/Calls > /dev/null
Trying 52.22.195.204...
* TCP_NODELAY set
* Connected to api.twilio.com (52.22.195.204) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
<snip>
>User-Agent: curl/7.55.1

The output reveals important information:
* TLS version and cypher used in the connection
* curl version in the User-Agent string

Finally, as far as the [shell] command, there is no Lasso
munging of it.  It issues the literal command.  If you see
differences in the output, then you should double-check your copy-pasta.

--steve



On 5/24/18 at 7:16 AM, [hidden email] (Jerad Hoff) pronounced:

>Sorry about the formatting.
>
>Here is the command I use:
>
>[SHELL: '/usr/local/bin/curl -k -X POST
>https://api.twilio.com:8443/2010-04-01/Accounts/UID/Calls 
>--data-urlencode
>"Url=https://myserver.com/call_alert.lasso?ID=531&STUFF=111111&FILE=Test.mp3"
>--data-urlencode "From=+15555555555" --data-urlencode "To=+
>15555555555" -u UID:KEY’]
>
>I get the dreaded CURL curl: (6) Couldn't resolve host error.
>If I copy and paste the above into the command line directly,
>it works as expected. If I change the domain name to the IP
>address of the target server, it works in lasso (it also works
>directly in the command line). Here is the output in its raw glory:
>
>% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>Dload  Upload   Total   Spent    Left  Speed
>
>0   could not lookup DNS configuration info service: (ipc/send) invalid destination port
>0    0     0    0     0      0      0 --:--:-- --:--:--
>--:--:--     0* Could not resolve host: api.twilio.com
>* Closing connection 0
>curl: (6) Could not resolve host: api.twilio.com
>
>So I just noticed the" destination port" part of the error. If
>I remove the special testing port and let it default to 80, it
>works with the domain name (the special port is to test against
>Twilio’s upcoming TLS 1.2 requirement). This makes me feel a
>bit better than when Twilio switches over their service to
>default to TLS 1.2, I’ll be able to change my code back to
>using a domain name instead of an IP address. It still
>doesn’t answer why if I copy and paste the command into a
>terminal window (ssh’d into the lasso server) it works fine,
>run it from Lasso and I can’t use the domain name.
>
>Thanks!
>
>- Jerad
>
>>On May 24, 2018, at 12:40 AM, Steve Piercy - Website Builder <[hidden email]> wrote:
>>
>>What is the curl command you use?
>>
>>What is the output of the curl command?
>>
>>Can you turn off HTML formatting before sending mail to the list?  This is invalid syntax
>and curly quotes are evil:
>>
>>> [SHELL: ‘nslookup api.twilio.com <http://api.twilio.com/>’]
>>
>>--steve
>
>
>#############################################################
>
>This message is sent to you because you are subscribed to
>the mailing list Lasso [hidden email]
>Official list archives available at http://www.lassotalk.com
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<[hidden email]>               <http://www.stevepiercy.com/>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Jerad Hoff-2
I have quadruple checked my copy and paste. They are 100% identical. It’s definitely strange.

This works (copied and pasted out of this email in fact to double check):

/usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/UID/Messages --data-urlencode "Body=Holy crap this worked." --data-urlencode "From=+15555555555" --data-urlencode "To=+15555555555" -u UID:KEY

I get the standard XML output from Twilio and I get the text message.

This does not:

[SHELL: '/usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/UID/Messages --data-urlencode "Body=Holy crap this worked." --data-urlencode "From=+15555555555" --data-urlencode "To=+15555555555" -u UID:KEY’]

I get this output:

 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed

 0   could not lookup DNS configuration info service: (ipc/send) invalid destination port
 0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: api.twilio.com

Exact, and I mean exact same command being run by me in the command line and what’s being run in the SHELL tag. Works for me, but not when Lasso does it. The only way to get the command to work when being executed by Lasso is to include the -k flag, which as you noted, is not ideal. Like I said, very strange.

 - Jerad

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

stevepiercy
Make sure that you are loading the file that you edit.  We've
all done that.

I think that shell and os_process truncate information that you
need to troubleshoot.  To get that information, on command line:

>If you want to force TLS v1.2 in the curl request, use the argument `--tlsv1.2`.
>
>https://curl.haxx.se/docs/manpage.html#--tlsv12
>
>Without it, the request may default to a lesser protocol and fail with exit code 6 or other, depending on the server to which the request is made and its support for TLS protocols.
>
>Include the `-v` argument for more information.

Like so, and toggle the port 8443 on and off.

curl -v --tlsv1.2 -X POST
'https://api.twilio.com:8443/2010-04-01/Accounts/YOUR_ACCOUNT_SID/Messages.json' 
--data-urlencode 'To=TO_PHONE_NUMBER' --data-urlencode
'From=FROM_PHONE_NUMBER' --data-urlencode 'Body=Your system is
ready for the upcoming change to the Twilio API SSL certificate.
No further action is needed.' -u YOUR_ACCOUNT_SID:AuthToken

Finally, you might not have the root certificate:

https://support.twilio.com/hc/en-us/articles/226478767-Monitoring-Updates-to-Twilio-REST-API-SSL-Certificates

     If your command fails, then outside of syntax errors, you
are likely
     missing our new root certificate.  We do not recommend pinning
     certificates.  If you or your organization are pinning root
     certificates, please ensure the DigiCert Global Root CA is
available in
     your local trust store.

Check your Applications > Utilities > Keychain Access and look
under Certificates for the DigiCert Global Root CA.

--steve


On 5/25/18 at 1:31 AM, [hidden email] (Jerad Hoff) pronounced:

>I have quadruple checked my copy and paste. They are 100%
>identical. It’s definitely strange.
>
>This works (copied and pasted out of this email in fact to double check):
>
>/usr/local/bin/curl -X POST
>https://api.twilio.com:8443/2010-04-01/Accounts/UID/Messages 
>--data-urlencode "Body=Holy crap this worked." --data-urlencode
>"From=+15555555555" --data-urlencode "To=+15555555555" -u UID:KEY
>
>I get the standard XML output from Twilio and I get the text message.
>
>This does not:
>
>[SHELL: '/usr/local/bin/curl -X POST
>https://api.twilio.com:8443/2010-04-01/Accounts/UID/Messages 
>--data-urlencode "Body=Holy crap this worked." --data-urlencode
>"From=+15555555555" --data-urlencode "To=+15555555555" -u UID:KEY’]
>
>I get this output:
>
>% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>Dload  Upload   Total   Spent    Left  Speed
>
>0   could not lookup DNS configuration info service: (ipc/send) invalid destination port
>0    0     0    0     0      0      0 --:--:-- --:--:--
>--:--:--     0curl: (6) Could not resolve host: api.twilio.com
>
>Exact, and I mean exact same command being run by me in the
>command line and what’s being run in the SHELL tag. Works for
>me, but not when Lasso does it. The only way to get the command
>to work when being executed by Lasso is to include the -k flag,
>which as you noted, is not ideal. Like I said, very strange.
>
>- Jerad
>
>#############################################################
>
>This message is sent to you because you are subscribed to
>the mailing list Lasso [hidden email]
>Official list archives available at http://www.lassotalk.com
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<[hidden email]>               <http://www.stevepiercy.com/>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Trevor Borgmeier
In reply to this post by Jerad Hoff-2
As Steve mentioned, you really shouldn't use the -k flag.

I think the difference you are experiencing between you running it on
the command line and lasso running it is that you are running it as
different users.

The user you run it as is using a cacert.pem file that works, and lasso
isn't.  It could be because lasso doesn't have permission to read the
cacert.pem file, or because it isn't finding it.

You can download a cacert.pem file here:
https://curl.haxx.se/docs/caextract.html

And you can test assigning it using the --with-ca-bundle option.
https://curl.haxx.se/docs/sslcerts.html

-Trevor




On 5/25/18 3:31 AM, Jerad Hoff wrote:

> I have quadruple checked my copy and paste. They are 100% identical. It’s definitely strange.
>
> This works (copied and pasted out of this email in fact to double check):
>
> /usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/UID/Messages --data-urlencode "Body=Holy crap this worked." --data-urlencode "From=+15555555555" --data-urlencode "To=+15555555555" -u UID:KEY
>
> I get the standard XML output from Twilio and I get the text message.
>
> This does not:
>
> [SHELL: '/usr/local/bin/curl -X POST https://api.twilio.com:8443/2010-04-01/Accounts/UID/Messages --data-urlencode "Body=Holy crap this worked." --data-urlencode "From=+15555555555" --data-urlencode "To=+15555555555" -u UID:KEY’]
>
> I get this output:
>
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                  Dload  Upload   Total   Spent    Left  Speed
>
>   0   could not lookup DNS configuration info service: (ipc/send) invalid destination port
>   0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: api.twilio.com
>
> Exact, and I mean exact same command being run by me in the command line and what’s being run in the SHELL tag. Works for me, but not when Lasso does it. The only way to get the command to work when being executed by Lasso is to include the -k flag, which as you noted, is not ideal. Like I said, very strange.
>
>   - Jerad
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>    the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


ɹǝıǝɯƃɹoq ɹoʌǝɹʇ

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Jerad Hoff-2
In reply to this post by stevepiercy

> On May 25, 2018, at 3:25 AM, Steve Piercy - Website Builder <[hidden email]> wrote:
>
> Make sure that you are loading the file that you edit.  We've all done that.

Good point, but am editing the correct file (happens to the best of us).

> I think that shell and os_process truncate information that you need to troubleshoot.  To get that information, on command line:
>
>> If you want to force TLS v1.2 in the curl request, use the argument `--tlsv1.2`.
>>
>> https://curl.haxx.se/docs/manpage.html#--tlsv12
>>
>> Without it, the request may default to a lesser protocol and fail with exit code 6 or other, depending on the server to which the request is made and its support for TLS protocols.
>>
>> Include the `-v` argument for more information.

The —tlsv1.2 flag doesn’t seem to make a different (and isn’t required when I manually type the command in the terminal).

> Like so, and toggle the port 8443 on and off.
>
> curl -v --tlsv1.2 -X POST 'https://api.twilio.com:8443/2010-04-01/Accounts/YOUR_ACCOUNT_SID/Messages.json' --data-urlencode 'To=TO_PHONE_NUMBER' --data-urlencode 'From=FROM_PHONE_NUMBER' --data-urlencode 'Body=Your system is ready for the upcoming change to the Twilio API SSL certificate. No further action is needed.' -u YOUR_ACCOUNT_SID:AuthToken

This works perfect from terminal. Errors when done from lasso.

> Finally, you might not have the root certificate:
>
> https://support.twilio.com/hc/en-us/articles/226478767-Monitoring-Updates-to-Twilio-REST-API-SSL-Certificates
>
>   If your command fails, then outside of syntax errors, you are likely
>   missing our new root certificate.  We do not recommend pinning
>   certificates.  If you or your organization are pinning root
>   certificates, please ensure the DigiCert Global Root CA is available in
>   your local trust store.
>
> Check your Applications > Utilities > Keychain Access and look under Certificates for the DigiCert Global Root CA.

If the certificate was missing, wouldn’t I be having problems when using the terminal program to run CURL? I do have the root CA listed in Keychain, but I tried downloading the .pem file from CURL and used the —caert flag but it still won’t connect. As you noted, lasso isn’t sharing the information from -v so it’s hard to know what’s failing.

Thanks for the help!

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

Jerad Hoff-2
In reply to this post by Trevor Borgmeier
I’ve been using the —cacert flag, not —with-ca-bundle   I’ll try that and report back.

> On May 25, 2018, at 7:43 AM, Trevor Borgmeier <[hidden email] <mailto:[hidden email]>> wrote:
>
> As Steve mentioned, you really shouldn't use the -k flag.
>
> I think the difference you are experiencing between you running it on the command line and lasso running it is that you are running it as different users.
>
> The user you run it as is using a cacert.pem file that works, and lasso isn't.  It could be because lasso doesn't have permission to read the cacert.pem file, or because it isn't finding it.
>
> You can download a cacert.pem file here:
> https://curl.haxx.se/docs/caextract.html <https://curl.haxx.se/docs/caextract.html>
>
> And you can test assigning it using the --with-ca-bundle option.
> https://curl.haxx.se/docs/sslcerts.html <https://curl.haxx.se/docs/sslcerts.html>
>
> -Trevor

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CURL won't run via "SHELL"

stevepiercy
In reply to this post by Jerad Hoff-2
On 5/26/18 at 5:29 PM, [hidden email] (Jerad Hoff) pronounced:

>>> If you want to force TLS v1.2 in the curl request, use the argument `--tlsv1.2`.
>>>   https://curl.haxx.se/docs/manpage.html#--tlsv12
>>>   Without it, the request may default to a lesser protocol
>>>and fail with exit code 6 or other,
>depending on the server to which the request is made and its support for TLS protocols.
>>>   Include the `-v` argument for more information.
>
>The —tlsv1.2 flag doesn’t seem to make a different (and
>isn’t required when I manually type the command in the terminal).

Please paste the complete output with both -v and --tlsv1.2
arguments.  This is the only way to allow anyone else to
interpret what you are seeing.  It's possible you missed
something or have misinterpreted the output.

>>Finally, you might not have the root certificate:
>>
>>
>https://support.twilio.com/hc/en-us/articles/226478767-Monitoring-Updates-to-Twilio-REST-API-SSL-
>Certificates
>>
>>If your command fails, then outside of syntax errors, you are likely
>>missing our new root certificate.  We do not recommend pinning
>>certificates.  If you or your organization are pinning root
>>certificates, please ensure the DigiCert Global Root CA is available in
>>your local trust store.
>>
>>Check your Applications > Utilities > Keychain Access and look under Certificates for the
>DigiCert Global Root CA.
>
>If the certificate was missing, wouldn’t I be having problems
>when using the terminal program to run CURL? I do have the root
>CA listed in Keychain, but I tried downloading the .pem file
>from CURL and used the —caert flag but it still won’t
>connect. As you noted, lasso isn’t sharing the information
>from -v so it’s hard to know what’s failing.

As Trevor mentioned, the root certificate might not be installed
for all users including the `lasso` user, or permissions might
otherwise disallow it being read.  You can, however, `su lasso`
(or whatever username is designated for Lasso on your OS), and
then try running the command as the lasso user in Terminal.  
This should let you see what Lasso itself obscures from view.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<[hidden email]>               <http://www.stevepiercy.com/>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>