Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gustaf N. <ne...@wu...> - 2019-12-12 17:11:11
|
Dear all, There is a major rework Let's Encrypt ACME client for NaviServer on bitbucket [1] to support ACME v2. ACME (the Automated Certificate Management Environment, [2]) is the protocol used for certificate management on letsencrypt.org. The API version v was released on 2016 but was updated in 2018. ACME v2 is not backwards compatible with v1. Let's Encrypt announced in March 2018 to drop the support of ACME v1 in several steps [3]: - Nov 2019: End of account registrations via ACME v1 - Jun 2020: End of new domain registrations via ACME v1 - Jun 2021: EOL ACME v1 certificate issuing The new version uses the crypto functions solely from OpenSSL, it uses the NaviServer crypto builtins and as well the "openssl" binary (the usage of tcllib pki was dropped). To avoid potential troubles, use the new version of the module with a recent version of NaviServer (currently the tip version form bitbucket) or with NaviServer 4.99.19 when this is released. Unfortunately, i was hit by account registrations issue two days ago, so i had to implement v2 to be able to get new certificates. Please update, if you are hit by similar issues. -g [1] https://bitbucket.org/naviserver/letsencrypt/src/default/ [2] https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment [3] https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 |
|
From: <iu...@iu...> - 2019-11-19 15:35:46
|
<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>Hi Gustaf,</div><div>Does tip mean the latest?</div><div><br></div><div>I thought the tip version of Naviserver was 4.99.18. At least that .18 is available on sourceforge to download</div><div><a href="https://sourceforge.net/projects/naviserver">https://sourceforge.net/projects/naviserver</a>/<br></div><div><br></div><div>Best wishes,</div><div>I<br></div><div><br></div> <blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;"> <div id="wmQuoteWrapper"> -------- Original Message --------<br> Subject: Re: [naviserver-devel] Converting a CURL call to a ns_http call<br> From: Gustaf Neumann <<a href="mailto:ne...@wu...">ne...@wu...</a>><br> Date: Tue, November 19, 2019 3:35 am<br> To: <a href="mailto:nav...@li...">nav...@li...</a><br> <br> <div class="moz-cite-prefix">On 17.11.19 18:00, Iuri Sampaio wrote:<br> </div> <blockquote type="cite" cite="mid:D08...@iu..."> <div class=""> <div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Do you still get successful results ? </span><a target="_blank" href="https://iurix.com/paypal-get-token" class="" moz-do-not-send="true">https://iurix.com/paypal-get-token</a></div> </div> </blockquote> <div>No sure, what you want me to test. The site above runs for me into a timeout.</div> <div>Running with the tip version leads now own <a target="_blank" class="moz-txt-link-freetext" href="https://api.sandbox.paypal.com/v1/oauth2/token">https://api.sandbox.paypal.com/v1/oauth2/token</a> to 401 (Client Authentication failed),<br> running with 4.99.18 leads to a 400 error status. So, as suggested previously, you should use the tip version of NaviServer,<br> there were many changes around ns_http since the last release.</div> <div>all the best</div> <div>-gn<br> </div> <hr><hr>_______________________________________________<br> naviserver-devel mailing list<br> <a href="mailto:nav...@li...">nav...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/naviserver-devel">https://lists.sourceforge.net/lists/listinfo/naviserver-devel</a><br> </div> </blockquote></span></body></html> |
|
From: Gustaf N. <ne...@wu...> - 2019-11-19 10:35:18
|
On 17.11.19 18:00, Iuri Sampaio wrote: > Do you still get successful results ? > https://iurix.com/paypal-get-token <https://iurix.com/paypal-get-token> No sure, what you want me to test. The site above runs for me into a timeout. Running with the tip version leads now own https://api.sandbox.paypal.com/v1/oauth2/token to 401 (Client Authentication failed), running with 4.99.18 leads to a 400 error status. So, as suggested previously, you should use the tip version of NaviServer, there were many changes around ns_http since the last release. all the best -gn |
|
From: Iuri S. <iu...@iu...> - 2019-11-17 17:00:41
|
The end of SSL request seems fine, except for 2 evidences that caught my attention i. the long loop of ssl connect on sock 28; > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 ii. the end of logging has an error [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskCallback task 0x7f6a40458f70 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 128 error (null) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: NS_SOCK_INIT done iii. api.sandbox.papal.com <http://api.sandbox.papal.com/> still rejects ns_http connections but allow curl and Postman. That’s very weird. [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) Do you still get successful results ? https://iurix.com/paypal-get-token <https://iurix.com/paypal-get-token> > On Nov 17, 2019, at 13:53, Iuri Sampaio <iu...@iu...> wrote: > > As indicated in the log, I’ve edited /etc/hosts, and assigned 173.0.82.78 to api.sandbox.paypal.com <http://api.sandbox.paypal.com/> > but nothing has changed. > > > > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: 0x7f6a40060f10 REUSE sql > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Notice: HRLLO WORLD! > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): connect to [api.sandbox.paypal.com <http://api.sandbox.paypal.com/>]:443 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: SockConnect to api.sandbox.paypal.com <http://api.sandbox.paypal.com/>: try address <173.0.82.78> async 1 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/N > > > > ##### > ## logs ends with the following messages > ##### > > > > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 80 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskCallback task 0x7f6a40458f70 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 128 error (null) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: NS_SOCK_INIT done > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: run task with revents 04 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): RunTask: revents 0: 4, task flags 000c > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 02 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_WRITE sendSpoolMode 0 fd 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc NS_SOCK_WRITE will send dsptr 0x7f6a403cd900 next 0x7f6a403cd900 len 485 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskSend sent 485 bytes (of 485) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc all data sent, switch to read reply > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskCallback task 0x7f6a40458f70 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 2 error (null) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: run task with revents 01 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): RunTask: revents 0: 1, task flags 000c > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 01 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_READ > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv received 81 bytes (buffer size 16384) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv got 81 bytes > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv got 81 bytes spoolFd 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv appends 81 bytes to buffer > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpAppendBuffer: got 81 bytes flags 000000 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv appends 81 bytes to buffer (replyHeaderSize 0) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckHeader replyHeaderSize 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckHeader we have EOH 0x7f6a403cd94d > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckHeader SETTING replyHeaderSize 81 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckSpool replyHeaderSize 81 status 0 httpPtr->replyHeaders 0x7f6a405bec90 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckSpool replyHeaderSize 81 status 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): ProcessReplyHeaderFields 0x7f6a405bec90 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckSpool have content-length 0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 1 error (null) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: run task with revents 01 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): RunTask: revents 0: 1, task flags 000c > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 01 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_READ > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv received 0 bytes (buffer size 16384) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv got 0 bytes > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 1 httpPtr->finalSockState 1 error (null) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: NS_SOCK_DONE done > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 10 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_DONE doneCallback <(null)> > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_DONE no sock callback > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 1 httpPtr->finalSockState 16 error (null) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpClose 0x7f6a405c3a20 FREE TASK 0x7f6a40458f70 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: freeconn ns:tcltrace ::xo::freeconn > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: deallocate nsproxy:cleanup a:(nil) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: deallocate nsdb:releasehandles a:(nil) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: deallocate ns:tcltrace ns_cleanup > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: Ns_ConnClose 0x559c71ed4b10 stream 000000 chunk 000000 via writer 000000 sockPtr 0x7f6a3c0034c0 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): NsSockClose sockPtr 0x7f6a3c0034c0 (5) keep -1 > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): NsSockClose calls RequestFree > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): === RequestFree cleans 0x7f6a3c0036c0 (avail 0 keep 1 length 0 contentLength 0) > [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): RequestFree does not call Ns_ResetRequest on 0x7f6a3c0036c8 > [17/Nov/2019:13:49:55][634.7f6a4e629700][-driver:nsssl_v4:0-] Debug(ns:driver): === PollWait returned 1, trigger[0] 1 > > > > >> On Nov 17, 2019, at 13:47, Iuri Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote: >> >> NS has been updated to .18 >> I’ve set logging as recommended. >> >> #ns_logctl severity "Debug(ns:driver)" $debug >> ns_logctl severity Debug(ns:driver) on >> ns_logctl severity Debug(task) on >> >> Logs are still the same >> >> [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Notice: HRLLO WORLD! >> [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug(task): connect to [api.sandbox.paypal.com <http://api.sandbox.paypal.com/>]:443 >> [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: SockConnect to api.sandbox.paypal.com <http://api.sandbox.paypal.com/>: try address <173.0.82.78> async 1 >> [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 >> [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 >> [17/ >> >>> On Nov 17, 2019, at 13:16, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>> wrote: >>> >>> On 17.11.19 17:04, Iuri Sampaio wrote: >>>> NaviServer/4.99.17 >>>> >>>> Should I upgrade it? >>> yes. There are fixes for partly configured IPv6 setups in the 4.99.18 release >>> (read the NEWS file). >>> I would recommend to use the tip version (the same i have used). >>> ... and set logging as recommended in my last mail. >>> -g >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... <mailto:nav...@li...> >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel> >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... <mailto:nav...@li...> >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Iuri S. <iu...@iu...> - 2019-11-17 16:53:24
|
As indicated in the log, I’ve edited /etc/hosts, and assigned 173.0.82.78 to api.sandbox.paypal.com <http://api.sandbox.paypal.com/> but nothing has changed. [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: 0x7f6a40060f10 REUSE sql [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Notice: HRLLO WORLD! [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): connect to [api.sandbox.paypal.com]:443 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: SockConnect to api.sandbox.paypal.com: try address <173.0.82.78> async 1 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/N ##### ## logs ends with the following messages ##### [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ssl connect on sock 28 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 80 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskCallback task 0x7f6a40458f70 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 128 error (null) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: NS_SOCK_INIT done [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: run task with revents 04 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): RunTask: revents 0: 4, task flags 000c [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 02 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_WRITE sendSpoolMode 0 fd 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc NS_SOCK_WRITE will send dsptr 0x7f6a403cd900 next 0x7f6a403cd900 len 485 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskSend sent 485 bytes (of 485) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc all data sent, switch to read reply [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskCallback task 0x7f6a40458f70 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 2 error (null) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: run task with revents 01 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): RunTask: revents 0: 1, task flags 000c [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 01 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_READ [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv received 81 bytes (buffer size 16384) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv got 81 bytes [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv got 81 bytes spoolFd 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv appends 81 bytes to buffer [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpAppendBuffer: got 81 bytes flags 000000 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv appends 81 bytes to buffer (replyHeaderSize 0) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckHeader replyHeaderSize 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckHeader we have EOH 0x7f6a403cd94d [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckHeader SETTING replyHeaderSize 81 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckSpool replyHeaderSize 81 status 0 httpPtr->replyHeaders 0x7f6a405bec90 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckSpool replyHeaderSize 81 status 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): ProcessReplyHeaderFields 0x7f6a405bec90 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_HttpCheckSpool have content-length 0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 0 httpPtr->finalSockState 1 error (null) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: run task with revents 01 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): RunTask: revents 0: 1, task flags 000c [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 01 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_READ [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv received 0 bytes (buffer size 16384) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpTaskRecv got 0 bytes [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 1 httpPtr->finalSockState 1 error (null) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): Ns_TaskRun 28: NS_SOCK_DONE done [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpProc operation 10 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_DONE doneCallback <(null)> [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): NS_SOCK_DONE no sock callback [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): taskDone 1 httpPtr->finalSockState 16 error (null) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(task): HttpClose 0x7f6a405c3a20 FREE TASK 0x7f6a40458f70 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: freeconn ns:tcltrace ::xo::freeconn [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: deallocate nsproxy:cleanup a:(nil) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: deallocate nsdb:releasehandles a:(nil) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: ns:interptrace[iurix]: deallocate ns:tcltrace ns_cleanup [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug: Ns_ConnClose 0x559c71ed4b10 stream 000000 chunk 000000 via writer 000000 sockPtr 0x7f6a3c0034c0 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): NsSockClose sockPtr 0x7f6a3c0034c0 (5) keep -1 [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): NsSockClose calls RequestFree [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): === RequestFree cleans 0x7f6a3c0036c0 (avail 0 keep 1 length 0 contentLength 0) [17/Nov/2019:13:49:55][634.7f6a4f62b700][-conn:iurix:0:44-] Debug(ns:driver): RequestFree does not call Ns_ResetRequest on 0x7f6a3c0036c8 [17/Nov/2019:13:49:55][634.7f6a4e629700][-driver:nsssl_v4:0-] Debug(ns:driver): === PollWait returned 1, trigger[0] 1 > On Nov 17, 2019, at 13:47, Iuri Sampaio <iu...@iu...> wrote: > > NS has been updated to .18 > I’ve set logging as recommended. > > #ns_logctl severity "Debug(ns:driver)" $debug > ns_logctl severity Debug(ns:driver) on > ns_logctl severity Debug(task) on > > Logs are still the same > > [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Notice: HRLLO WORLD! > [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug(task): connect to [api.sandbox.paypal.com <http://api.sandbox.paypal.com/>]:443 > [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: SockConnect to api.sandbox.paypal.com <http://api.sandbox.paypal.com/>: try address <173.0.82.78> async 1 > [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 > [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 > [17/ > >> On Nov 17, 2019, at 13:16, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>> wrote: >> >> On 17.11.19 17:04, Iuri Sampaio wrote: >>> NaviServer/4.99.17 >>> >>> Should I upgrade it? >> yes. There are fixes for partly configured IPv6 setups in the 4.99.18 release >> (read the NEWS file). >> I would recommend to use the tip version (the same i have used). >> ... and set logging as recommended in my last mail. >> -g >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... <mailto:nav...@li...> >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Iuri S. <iu...@iu...> - 2019-11-17 16:47:47
|
NS has been updated to .18 I’ve set logging as recommended. #ns_logctl severity "Debug(ns:driver)" $debug ns_logctl severity Debug(ns:driver) on ns_logctl severity Debug(task) on Logs are still the same [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Notice: HRLLO WORLD! [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug(task): connect to [api.sandbox.paypal.com]:443 [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: SockConnect to api.sandbox.paypal.com: try address <173.0.82.78> async 1 [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:13:44:50][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/Nov/2019:13:44:51][634.7f6a4ee2a700][-conn:iurix:1:9-] Debug: ssl connect on sock 28 [17/ > On Nov 17, 2019, at 13:16, Gustaf Neumann <ne...@wu...> wrote: > > On 17.11.19 17:04, Iuri Sampaio wrote: >> NaviServer/4.99.17 >> >> Should I upgrade it? > yes. There are fixes for partly configured IPv6 setups in the 4.99.18 release > (read the NEWS file). > I would recommend to use the tip version (the same i have used). > ... and set logging as recommended in my last mail. > -g > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Gustaf N. <ne...@wu...> - 2019-11-17 16:17:12
|
On 17.11.19 17:04, Iuri Sampaio wrote: > NaviServer/4.99.17 > > Should I upgrade it? yes. There are fixes for partly configured IPv6 setups in the 4.99.18 release (read the NEWS file). I would recommend to use the tip version (the same i have used). ... and set logging as recommended in my last mail. -g |
|
From: Iuri S. <iu...@iu...> - 2019-11-17 16:04:49
|
Gustaf, Despite the immense frustration for having wasted hours debugging a script, which is properly written, I’m glad you got successful results. At least now we know the problem can be in the environment. I’ve changed servers to evaluate and mitigate environment problems. https://iurix.com/paypal-get-token <https://iurix.com/paypal-get-token> I literally copied and pasted the TCL script . *** I’m going to renew those token later, after we solve this situation. ns_log Notice "HRLLO WORLD!" set h [ns_set create] ns_set update $h Authorization "Basic QWJCN2VaRzJVeUJsb1JlVG8tUWRvRnhmMzZnZlNKbmQ1REpEbEllQ2FjZHgzdDJwMEs1aTZXUVNwTHRNVDdYT2JtUVBQREowLTZQblJLUTI6RUpmRG8zeEw2cFBhWXpKOGdRMERjeUV2Y2RSTU0tX2pGMElIZVdJc185SUJkbXF0UkN3QWRYRXloRTBkM1lNT0JIb2t\ 2STkzWXd0Q2tpSkY=" ns_set update $h "Accept" "application/json" ns_set update $h "Accept-Language" "en_US" ns_set update $h "Content-Type" "application/json" ns_http run -method POST -headers $h -body grant_type=client_credentials https://api.sandbox.paypal.com/v1/oauth2/token Regarding debugging, there’s a parameter within NS config file, from OACS installation scripts. I’ve switched set debug true within config-acs.tcl. The chunks which caught my attentions were Potential causes: 1. SSL certificate is from certbot Would that be the problem? 2. Naviserver installation NaviServer/4.99.17 NS initialization seems fine. See OACS bootstrap logs bellow Should I upgrade it? 3. OpenACS bootstraling process (i). Running https://iurix.com/paypal-get-token <https://iurix.com/paypal-get-token>, with debug parameter assigned as false, it returns [17/Nov/2019:13:00:36][20678.7f7eaaa08700][-conn:iurix:0:0-] Notice: HRLLO WORLD! [17/Nov/2019:13:00:36][20678.7f7eaaa08700][-conn:iurix:0:0-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) With debug parameter assigned as true, it returns an endless loop related to ssl socket [17/Nov/2019:12:54:31][20462.7fedd2125700][-conn:iurix:0:30-] Debug: SockConnect to api.sandbox.paypal.com: try address <173.0.82.78> [17/Nov/2019:12:54:31][20462.7fedd2125700][-conn:iurix:0:30-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:12:54:31][20462.7fedd2125700][-conn:iurix:0:30-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:12:54:31][20462.7fedd2125700][-conn:iurix:0:30-] Debug: ssl connect on sock 30 [17/Nov/2019:12:54:31][20462.7fedd2125700][-conn:iurix:0:30-] Debug: ssl connect on sock 30 [1 (ii.a). Debug: ssl connect on sock 30 [17/Nov/2019:12:45:04][20462.7fedd1924700][-conn:iurix:1:2-] Notice: HRLLO WORLD! [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: ns:interptrace[iurix]: allocate ns:tcltrace ns_init [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: Running scheduled proc search::indexer... [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Notice: dbdrv: opening database 'postgres:localhost::dbname=iurix' [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Notice: nsdbpg: Opening dbname=iurix on localhost, port [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Notice: nsdbpg(postgres): Opened connection to localhost::dbname=iurix. [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: 0x7fed9402eb40 convert type none to sql < select acs_sc_binding__exists_p(:contract,:impl) > [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: SockConnect to api.sandbox.paypal.com: try address <173.0.82.78> [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: Ns_SockBind called with: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: trying to bind on: SockAddr family AF_INET, ip 0.0.0.0, port 0 [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: 0x7fed9402e510 convert type none to sql < select object_id, event_date, event from search_observer_queue order by event_date asc > [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: Done running scheduled proc search::indexer. [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: ns:interptrace[iurix]: deallocate nsproxy:cleanup a:(nil) [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: ns:interptrace[iurix]: deallocate nsdb:releasehandles a:(nil) [17/Nov/2019:12:45:05][20462.7feda37fe700][-sched:11-] Debug: ns:interptrace[iurix]: deallocate ns:tcltrace ns_cleanup [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924700][-conn:iurix:1:2-] Debug: ssl connect on sock 30 [17/Nov/2019:12:45:05][20462.7fedd1924 ... (ii). Plus a few more failures related to cookies (ii.b). More failures related to cookies [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: __ad_verify_signature: Getting token_id 759, value 4BC6F6191B5CEE67AB67BF24BA73AC2C7D29C276 ; [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: __ad_verify_signature: Expire_Time is 1573956591 (compare to 1574004188), hash is 219DD9C5066AC83896DB148F4DAF6F37B11DB8FF [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: __ad_verify_signature: Hash matches - Hash check OK [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: __ad_verify_signature: Expiration time (1573956591) less than or equal to current time (1574004188) - Expiration check FAILED [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: ad_get_signed_cookie: Verification of cookie ad_session_id FAILED [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS: Not a valid session cookie, looking for login cookie 'Cookie could not be authenticated.' [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS= sec_login_handler: enter [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS= sec_setup_session: enter [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS= empty session_id [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS= newly allocated session 342530002 [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS= about to generate session id cookie [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: Security: 1574004188 sec_generate_session_id_cookie setting session_id=342530002, user_id=0, login_level=0 [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: Security: Getting token_id 472, value E229479F72476418E5A43FEDE204EA7AF6FCFF7C [17/Nov/2019:12:23:08][28463.7fe986cd4700][-conn:evex:0:1-] Debug: OACS= done generating session id cookie #### 3. OpenACS bootstrapping process #### ^[[0;32m[17/Nov/2019:12:42:18][7106.7f76755ec700][-sched:22-] ^[[0m^[[0;39mNotice: nsdb: closing old handle in pool 'pool1'^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsmain: NaviServer/4.99.17 (tar-4.99.17) starting^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsmain: security info: uid=1002, euid=1002, gid=1002, egid=1002^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsmain: Tcl version: 8.6.8^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsmain: max files: soft limit 4096, hard limit 4096^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[1;39mWarning: nsmain: rl_cur (4096) > FD_SETSIZE (1024), select() calls should not be used^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: pool default: queueLength 90 low water 9 high water 90^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsd/init.tcl[iurix]: booting virtual server: Tcl system encoding: "utf-8"^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module nslog from file /usr/local/ns/bin/nslog.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nslog: opened '/var/www/iurix/log//access.log'^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module nsdb from file /usr/local/ns/bin/nsdb.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module ns/db/driver/postgres from file /usr/local/ns/bin/nsdbpg.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsdbpg: version 2.3 loaded, based on PostgreSQL 9.6.10 and libbpq 90611^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: dbinit: set LogMinDuration for pool pool1 over 0.01 to 0.010000^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: dbinit: set LogMinDuration for pool pool2 over 0.01 to 0.010000^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module nsproxy from file /usr/local/ns/bin/nsproxy.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module nssock_v4 from file /usr/local/ns/bin/nssock.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mDebug(ns:driver): DriverInit server <iurix> threadName nssock_v4:0 proto http port 80^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nssock_v4:0: enable 0 spooler thread(s) ^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nssock_v4:0: enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=8192 bytes, HTML streaming 0^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module nsssl_v4 from file /usr/local/ns/bin/nsssl.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mDebug(ns:driver): DriverInit server <iurix> threadName nsssl_v4:0 proto https port 443^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsssl_v4:0: enable 0 spooler thread(s) ^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsssl_v4:0: enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=16384 bytes, HTML streaming 0^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: OpenSSL OpenSSL 1.1.0j 20 Nov 2018 initialized^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsssl: disabling SSLv2^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nsssl: version 2.1 loaded, based on OpenSSL 1.1.0j 20 Nov 2018^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: modload: loading module libthread from file /usr/local/ns/lib/thread2.8.2/libthread2.8.2.so^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;34mDebug: nsd/init.tcl: loading /usr/local/ns/tcl/init.tcl^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;34mDebug: nsd/init.tcl: loading /usr/local/ns/tcl/aolserver-openacs.tcl^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: nx::serializer version 2.2^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: XOTcl 2.2.0 loaded featuring: memcount 0 profile 0 memtrace 0 assertions 1 dtrace 0 development 0^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;39mNotice: Using ns_cache based on NX 2.2.0^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;34mDebug: nsd/init.tcl: loading /usr/local/ns/tcl/cache.tcl^[[0m ^[[0;32m[17/Nov/2019:12:43:03][20368.7f8659e5b700][-main-] ^[[0m^[[0;34mDebug: nsd/init.tcl: loading /usr/local/ns/tcl/charsets.tcl^[[0m > On Nov 17, 2019, at 06:58, Gustaf Neumann <ne...@wu...> wrote: > > On 17.11.19 00:00, Iuri Sampaio wrote: >> I was expecting to get the same thing with ns_http. However, when I ran https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token> status returns 0 and body returns null. It’;s available at ttps://evex.co/paypal-checkout <ttps://evex.co/paypal-checkout>Hi Iuri, > > not sure, what might be wrong on your side, it is working for me (see below). > I've tried this under maxOS and Linux. Maybe a problem with versions? > If you see this failing as well with the tip version of NaviServer (which i was testing with) > you can turn on debugging on the task level with > > ns_logctl severity Debug(task) on > > or if this is not sufficient on the driver level > > ns_logctl severity Debug(ns:driver) on > all the best > > -gn > PS: You should probably alter your credentials on api.sandbox.paypal.com > > > % set h [ns_set create] > % ns_set update $h Authorization "Basic QWJCN2VaRzJVeUJsb1JlVG8tUWRvRnhmMzZnZlNKbmQ1REpEbEllQ2FjZHgzdDJwMEs1aTZXUVNwTHRNVDdYT2JtUVBQREowLTZQblJLUTI6RUpmRG8zeEw2cFBhWXpKOGdRMERjeUV2Y2RSTU0tX2pGMElIZVdJc185SUJkbXF0UkN3QWRYRXloRTBkM1lNT0JIb2t2STkzWXd0Q2tpSkY=" > % ns_set update $h "Accept" "application/json" > % ns_set update $h "Accept-Language" "en_US" > % ns_set update $h "Content-Type" "application/json" > % ns_http run -method POST -headers $h -body grant_type=client_credentials https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token> > > status 200 time 1:503938 headers d13 body {{"scope":"https://uri.paypal.com/services/invoicing https://uri.paypal.com/services/disputes/read-buyer https://uri.paypal.com/services/payments/realtimepayment https://uri.paypal.com/services/disputes/update-seller https://uri.paypal.com/services/payments/payment/authcapture openid https://uri.paypal.com/services/disputes/read-seller https://uri.paypal.com/services/payments/refund https://api.paypal.com/v1/vault/credit-card https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.* https://uri.paypal.com/services/subscriptions https://uri.paypal.com/services/applications/webhooks" <https://uri.paypal.com/services/invoicinghttps://uri.paypal.com/services/disputes/read-buyerhttps://uri.paypal.com/services/payments/realtimepaymenthttps://uri.paypal.com/services/disputes/update-sellerhttps://uri.paypal.com/services/payments/payment/authcaptureopenidhttps://uri.paypal.com/services/disputes/read-sellerhttps://uri.paypal.com/services/payments/refundhttps://api.paypal.com/v1/vault/credit-cardhttps://api.paypal.com/v1/payments/.*https://uri.paypal.com/payments/payoutshttps://api.paypal.com/v1/vault/credit-card/.*https://uri.paypal.com/services/subscriptionshttps://uri.paypal.com/services/applications/webhooks>,"access_token":"A21AAHMkTt1pYmD_syssLe1hHdsndPOP8WU60PHmfAcCrol39OoB3rP9vIwbIBPZzHF1jlp9_Mnu1t8NN4oA096PJzLdP6Msw","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":32400,"nonce":"2019-11-17T09:42:14ZFs7vTotrg8oVWwjwsFg7k9pSpMvwCc3-nCaKUrtltuE"}} https {sslversion TLSv1.2 cipher AES256-SHA256} > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Gustaf N. <ne...@wu...> - 2019-11-17 09:58:25
|
On 17.11.19 00:00, Iuri Sampaio wrote: > I was expecting to get the same thing with ns_http. However, when I > ran https://api.sandbox.paypal.com/v1/oauth2/token > <https://api.sandbox.paypal.com/v1/oauth2/token> status returns 0 and > body returns null. It’;s available at ttps://evex.co/paypal-checkout > <ttps://evex.co/paypal-checkout> Hi Iuri, not sure, what might be wrong on your side, it is working for me (see below). I've tried this under maxOS and Linux. Maybe a problem with versions? If you see this failing as well with the tip version of NaviServer (which i was testing with) you can turn on debugging on the task level with ns_logctl severity Debug(task) on or if this is not sufficient on the driver level ns_logctl severity Debug(ns:driver) on all the best -gn PS: You should probably alter your credentials on api.sandbox.paypal.com % set h [ns_set create] % ns_set update $h Authorization "Basic QWJCN2VaRzJVeUJsb1JlVG8tUWRvRnhmMzZnZlNKbmQ1REpEbEllQ2FjZHgzdDJwMEs1aTZXUVNwTHRNVDdYT2JtUVBQREowLTZQblJLUTI6RUpmRG8zeEw2cFBhWXpKOGdRMERjeUV2Y2RSTU0tX2pGMElIZVdJc185SUJkbXF0UkN3QWRYRXloRTBkM1lNT0JIb2t2STkzWXd0Q2tpSkY=" % ns_set update $h "Accept" "application/json" % ns_set update $h "Accept-Language" "en_US" % ns_set update $h "Content-Type" "application/json" % ns_http run -method POST -headers $h -body grant_type=client_credentials https://api.sandbox.paypal.com/v1/oauth2/token status 200 time 1:503938 headers d13 body {{"scope":"https://uri.paypal.com/services/invoicing https://uri.paypal.com/services/disputes/read-buyer https://uri.paypal.com/services/payments/realtimepayment https://uri.paypal.com/services/disputes/update-seller https://uri.paypal.com/services/payments/payment/authcapture openid https://uri.paypal.com/services/disputes/read-seller https://uri.paypal.com/services/payments/refund https://api.paypal.com/v1/vault/credit-card https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.* https://uri.paypal.com/services/subscriptions https://uri.paypal.com/services/applications/webhooks","access_token":"A21AAHMkTt1pYmD_syssLe1hHdsndPOP8WU60PHmfAcCrol39OoB3rP9vIwbIBPZzHF1jlp9_Mnu1t8NN4oA096PJzLdP6Msw","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":32400,"nonce":"2019-11-17T09:42:14ZFs7vTotrg8oVWwjwsFg7k9pSpMvwCc3-nCaKUrtltuE"}} https {sslversion TLSv1.2 cipher AES256-SHA256} |
|
From: Iuri S. <iu...@iu...> - 2019-11-16 23:03:25
|
Btw, the very same request works fine not only on CURL but also on Postman.
For instance, that’s the response CURL and Postman return
{
"scope": "https://uri.paypal.com/services/invoicing https://uri.paypal.com/services/disputes/read-buyer https://uri.paypal.com/services/payments/realtimepayment https://uri.paypal.com/services/disputes/update-seller https://uri.paypal.com/services/payments/payment/authcapture openid https://uri.paypal.com/services/disputes/read-seller https://uri.paypal.com/services/payments/refund https://api.paypal.com/v1/vault/credit-card https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.* https://uri.paypal.com/services/subscriptions https://uri.paypal.com/services/applications/webhooks",
"access_token": "A21AAGnfdsdsdsdFEFERFERgbh-nvewEw3uM4llmAoRwLc9Wkh4wpkVHTQ4-ehe_F-bdgW3Z5EinJgbrmK3Eu4ffds-YPWQ",
"token_type": "Bearer",
"app_id": "APP-W28fGERGERGERGERGREGE3T",
"expires_in": 31623,
"nonce": "2019-11-16T22:13:00Zb0kTBXRvIaKfKQ0AM3T6Q4e4RUih0srGp6GSlBENIeI"
}
> On Nov 16, 2019, at 20:00, Iuri Sampaio <iu...@iu...> wrote:
>
> I’ve just ran the sample you suggested. Results returned successfully. (i)
> Meaning body returned content within. Meaning Authorization headers were properly converted to base64 and authentication worked just fine
>
>
> Also, in the CURL command, running it in the command line prompt, body returns a JSON within a bunch of tokens and auth responses.
>
> I was expecting to get the same thing with ns_http. However, when I ran https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token> status returns 0 and body returns null. It’;s available at ttps://evex.co/paypal-checkout <ttps://evex.co/paypal-checkout>
>
> Log are bellow
>
>
> (i). https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/>
>
> [16/Nov/2019:19:50:17][450.7f7a4ffff700][-conn:evex:127:47119-] Notice: HTTP
> status 200 time 0:152605 headers d5 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
> <html>
> <head>
> <title>Basic Authentication test page</title>
> <!-- Changed by: Yves Lafon, 22-Feb-1999 -->
> </head>
>
> <BODY BGCOLOR="white">
> <P>
> <A HREF=".."><IMG SRC="/icons/jigsaw" ALT="Jigsaw" BORDER="0" WIDTH="212"
> HEIGHT="49"></A><IMG SRC="/icons/jigpower.gif" WIDTH="94" HEIGHT="52" ALT="Jigsaw Powered !"
> BORDER="0" ALIGN="Right">
>
> <P>
> <HR>
> <P>Your browser made it!
> </body>
> </html>
> } https {sslversion TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384}
> [16/Nov/2019:19:50:19][450.7f7a7ffff700][::throttle] Notice: === user 106.57.150.57 entered community 633 at 1573944619 reason new
>
>
> (ii).https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>
> [16/Nov/2019:19:59:29][450.7f7a4ffff700][-conn:evex:127:47139-] Notice: HTTP
> status 0 time 0:155545 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256}
> [16/Nov/2019:19:59:29][450.7f7a4ffff700][-conn:evex:127:47139-] Notice: RETURN URL /paypal-checkout *******
>
>
>
> (iii). CURL
>
> curl -v https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token> -H "Accept: application/json" -H "Accept-Language: en_US" -u "AbB7eZG2UyBloReTo-QdoFxf36gfSJnd5DJDlIeCacdx3t2p0K5i6WQSpLtMT7XObmQPPDJ0-6PnRKQ2:EJfDo3xL6pPaYzJ8gQ0DcyEvcdRMM-_jF0IHeWIs_9IBdmqtRCwAdXEyhE0d3YMOBHokvI93YwtCkiJF" -d "grant_type=client_credentials"
> * Trying 173.0.82.78...
> * TCP_NODELAY set
> * Connected to api.sandbox.paypal.com <http://api.sandbox.paypal.com/> (173.0.82.78) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> * successfully set certificate verify locations:
> * CAfile: /etc/ssl/certs/ca-certificates.crt
> CApath: /etc/ssl/certs
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
> * TLSv1.2 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> * TLSv1.2 (IN), TLS handshake, Request CERT (13):
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> * TLSv1.2 (OUT), TLS handshake, Certificate (11):
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> * TLSv1.2 (IN), TLS change cipher, Client hello (1):
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> * SSL connection using TLSv1.2 / AES256-SHA256
> * ALPN, server did not agree to a protocol
> * Server certificate:
> * subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com <http://api.sandbox.paypal.com/>
> * start date: Aug 21 00:00:00 2018 GMT
> * expire date: Aug 20 12:00:00 2020 GMT
> * subjectAltName: host "api.sandbox.paypal.com <http://api.sandbox.paypal.com/>" matched cert's "api.sandbox.paypal.com <http://api.sandbox.paypal.com/>"
> * issuer: C=US; O=DigiCert Inc; CN=DigiCert Global CA G2
> * SSL certificate verify ok.
> * Server auth using Basic with user 'AbB7eZG2UyBloReTo-QdoFxf36gfSJnd5DJDlIeCacdx3t2p0K5i6WQSpLtMT7XObmQPPDJ0-6PnRKQ2'
> > POST /v1/oauth2/token HTTP/1.1
> > Host: api.sandbox.paypal.com <http://api.sandbox.paypal.com/>
> > Authorization: Basic QWJCN2VaRzJVeUJsb1JlVG8tUWRvRnhmMzZnZlNKbmQ1REpEbEllQ2FjZHgzdDJwMEs1aTZXUVNwTHRNVDdYT2JtUVBQREowLTZQblJLUTI6RUpmRG8zeEw2cFBhWXpKOGdRMERjeUV2Y2RSTU0tX2pGMElIZVdJc185SUJkbXF0UkN3QWRYRXloRTBkM1lNT0JIb2t2STkzWXd0Q2tpSkY=
> > User-Agent: curl/7.52.1
> > Accept: application/json
> > Accept-Language: en_US
> > Content-Length: 29
> > Content-Type: application/x-www-form-urlencoded
> >
> * upload completely sent off: 29 out of 29 bytes
> < HTTP/1.1 200 OK
> < Cache-Control: max-age=0, no-cache, no-store, must-revalidate
> < Content-Length: 918
> < Content-Type: application/json
> < Date: Sat, 16 Nov 2019 22:58:32 GMT
> < Paypal-Debug-Id: 9c14dc56c49a9
> < X-Paypal-Token-Service: IAAS
> <
> * Curl_http_done: called premature == 0
> * Connection #0 to host api.sandbox.paypal.com <http://api.sandbox.paypal.com/> left intact
> {"scope":"https://uri.paypal.com/services/invoicing <https://uri.paypal.com/services/invoicing> https://uri.paypal.com/services/disputes/read-buyer <https://uri.paypal.com/services/disputes/read-buyer> https://uri.paypal.com/services/payments/realtimepayment <https://uri.paypal.com/services/payments/realtimepayment> https://uri.paypal.com/services/disputes/update-seller <https://uri.paypal.com/services/disputes/update-seller> https://uri.paypal.com/services/payments/payment/authcapture <https://uri.paypal.com/services/payments/payment/authcapture> openid https://uri.paypal.com/services/disputes/read-seller <https://uri.paypal.com/services/disputes/read-seller> https://uri.paypal.com/services/payments/refund <https://uri.paypal.com/services/payments/refund> https://api.paypal.com/v1/vault/credit-card <https://api.paypal.com/v1/vault/credit-card> https://api.paypal.com/v1/payments <https://api.paypal.com/v1/payments>/.* https://uri.paypal.com/payments/payouts <https://uri.paypal.com/payments/payouts> https://api.paypal.com/v1/vault/credit-card <https://api.paypal.com/v1/vault/credit-card>/.* https://uri.paypal.com/services/subscriptions <https://uri.paypal.com/services/subscriptions> https://uri.paypal.com/services/applications/webhooks <https://uri.paypal.com/services/applications/webhooks>","access_token":"A21AAGnfER4lNk8rnGB4InaKkTbh-nvewEw3uM4llmAoRwLc9Wkh4wpkVHTQ4-ehe_F-bdgW3Z5EinJgbrmK3Eu4ffds-YPWQ","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":29668,"nonce":"2019-11-16T22:13:00Zb0kTBXRvIaKfKQ0AM3T6Q4e4RUih0srGp6GSlBENIeI"}evex@evex:/var/www/evex$
>
>
>
>> On Nov 16, 2019, at 15:56, Iuri Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote:
>>
>> Dear Gustaf,
>> It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5>
>> Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"]
>> I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs.
>> https://evex.co/paypal-checkout <https://evex.co/paypal-checkout>
>>
>>
>> Notice: HTTP
>> status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256}
>>
>>
>>
>> I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned.
>> Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side.
>>
>>
>> Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
>>
>>
>>
>> Best wishes,
>> I
>> [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name.
>> [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
>>
>>
>>
>>
>> [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
>> [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout *******
>>
>>> On Nov 16, 2019, at 15:47, Iuri Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote:
>>>
>>> Dear Gustaf,
>>> It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5>
>>> Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"]
>>> I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs.
>>> https://evex.co/paypal-checkout <https://evex.co/paypal-checkout>
>>>
>>>
>>> Notice: HTTP
>>> status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256}
>>>
>>>
>>> Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
>>>
>>>
>>> I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned.
>>> Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side.
>>>
>>>
>>> Best wishes,
>>> I
>>> [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name.
>>> [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
>>>
>>>
>>>
>>>
>>> [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
>>> [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout *******
>>>
>>>
>>>
>>>
>>>> On Nov 16, 2019, at 08:58, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>> wrote:
>>>>
>>>> Dear Iuri,
>>>>
>>>> Let's start with a simple example: make a GET request to a service, which
>>>> requires basic authentication
>>>> % ns_http run https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/>
>>>> status 401 time 0:513863 headers d11 body {<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>>>> "http://www.w3.org/TR/html4/loose.dtd" <http://www.w3.org/TR/html4/loose.dtd>>
>>>> <html>
>>>> <head>
>>>> ...
>>>>
>>>> NaviServer returns (starting with 4.99.17) for "ns_http run" a Tcl dict with
>>>> the relevant information. The request above returns the HTTP status
>>>> code 401, which means "Unauthorized".
>>>>
>>>> Ok, now add some Authorization. As defined by RFC 7617, one has to add an
>>>> Authorization request header field with user:id:password encoded in base64.
>>>> % set h [ns_set create]
>>>> % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]"
>>>> % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/>
>>>> status 200 time 0:485802 headers d8 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
>>>> <html>
>>>> <head>
>>>> ...
>>>>
>>>> Now we see the status code 200, which means that the Authentication was ok.
>>>> If you still get a status code of 401, probably userid and/or password are not ok.
>>>>
>>>> Hope this helps.
>>>> -gn
>>>>
>>>> On 15.11.19 16:21, Iuri Sampaio wrote:
>>>>> What would be the argument/switch to convert the option -u, from CURL command, to ns_http command?
>>>>>
>>>>> curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \
>>>>> -H "Accept: application/json" \
>>>>> -H "Accept-Language: en_US" \
>>>>> -u "client_id:secret" \
>>>>> -d "grant_type=client_credentials"
>>>>
>>>> _______________________________________________
>>>> naviserver-devel mailing list
>>>> nav...@li... <mailto:nav...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
>>>
>>
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li... <mailto:nav...@li...>
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Iuri S. <iu...@iu...> - 2019-11-16 23:01:12
|
I’ve just ran the sample you suggested. Results returned successfully. (i) Meaning body returned content within. Meaning Authorization headers were properly converted to base64 and authentication worked just fine Also, in the CURL command, running it in the command line prompt, body returns a JSON within a bunch of tokens and auth responses. I was expecting to get the same thing with ns_http. However, when I ran https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token> status returns 0 and body returns null. It’;s available at ttps://evex.co/paypal-checkout <ttps://evex.co/paypal-checkout> Log are bellow (i). https://jigsaw.w3.org/HTTP/Basic/ [16/Nov/2019:19:50:17][450.7f7a4ffff700][-conn:evex:127:47119-] Notice: HTTP status 200 time 0:152605 headers d5 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <html> <head> <title>Basic Authentication test page</title> <!-- Changed by: Yves Lafon, 22-Feb-1999 --> </head> <BODY BGCOLOR="white"> <P> <A HREF=".."><IMG SRC="/icons/jigsaw" ALT="Jigsaw" BORDER="0" WIDTH="212" HEIGHT="49"></A><IMG SRC="/icons/jigpower.gif" WIDTH="94" HEIGHT="52" ALT="Jigsaw Powered !" BORDER="0" ALIGN="Right"> <P> <HR> <P>Your browser made it! </body> </html> } https {sslversion TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384} [16/Nov/2019:19:50:19][450.7f7a7ffff700][::throttle] Notice: === user 106.57.150.57 entered community 633 at 1573944619 reason new (ii).https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token> [16/Nov/2019:19:59:29][450.7f7a4ffff700][-conn:evex:127:47139-] Notice: HTTP status 0 time 0:155545 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256} [16/Nov/2019:19:59:29][450.7f7a4ffff700][-conn:evex:127:47139-] Notice: RETURN URL /paypal-checkout ******* (iii). CURL curl -v https://api.sandbox.paypal.com/v1/oauth2/token -H "Accept: application/json" -H "Accept-Language: en_US" -u "AbB7eZG2UyBloReTo-QdoFxf36gfSJnd5DJDlIeCacdx3t2p0K5i6WQSpLtMT7XObmQPPDJ0-6PnRKQ2:EJfDo3xL6pPaYzJ8gQ0DcyEvcdRMM-_jF0IHeWIs_9IBdmqtRCwAdXEyhE0d3YMOBHokvI93YwtCkiJF" -d "grant_type=client_credentials" * Trying 173.0.82.78... * TCP_NODELAY set * Connected to api.sandbox.paypal.com (173.0.82.78) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Request CERT (13): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / AES256-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com * start date: Aug 21 00:00:00 2018 GMT * expire date: Aug 20 12:00:00 2020 GMT * subjectAltName: host "api.sandbox.paypal.com" matched cert's "api.sandbox.paypal.com" * issuer: C=US; O=DigiCert Inc; CN=DigiCert Global CA G2 * SSL certificate verify ok. * Server auth using Basic with user 'AbB7eZG2UyBloReTo-QdoFxf36gfSJnd5DJDlIeCacdx3t2p0K5i6WQSpLtMT7XObmQPPDJ0-6PnRKQ2' > POST /v1/oauth2/token HTTP/1.1 > Host: api.sandbox.paypal.com > Authorization: Basic QWJCN2VaRzJVeUJsb1JlVG8tUWRvRnhmMzZnZlNKbmQ1REpEbEllQ2FjZHgzdDJwMEs1aTZXUVNwTHRNVDdYT2JtUVBQREowLTZQblJLUTI6RUpmRG8zeEw2cFBhWXpKOGdRMERjeUV2Y2RSTU0tX2pGMElIZVdJc185SUJkbXF0UkN3QWRYRXloRTBkM1lNT0JIb2t2STkzWXd0Q2tpSkY= > User-Agent: curl/7.52.1 > Accept: application/json > Accept-Language: en_US > Content-Length: 29 > Content-Type: application/x-www-form-urlencoded > * upload completely sent off: 29 out of 29 bytes < HTTP/1.1 200 OK < Cache-Control: max-age=0, no-cache, no-store, must-revalidate < Content-Length: 918 < Content-Type: application/json < Date: Sat, 16 Nov 2019 22:58:32 GMT < Paypal-Debug-Id: 9c14dc56c49a9 < X-Paypal-Token-Service: IAAS < * Curl_http_done: called premature == 0 * Connection #0 to host api.sandbox.paypal.com left intact {"scope":"https://uri.paypal.com/services/invoicing https://uri.paypal.com/services/disputes/read-buyer https://uri.paypal.com/services/payments/realtimepayment https://uri.paypal.com/services/disputes/update-seller https://uri.paypal.com/services/payments/payment/authcapture openid https://uri.paypal.com/services/disputes/read-seller https://uri.paypal.com/services/payments/refund https://api.paypal.com/v1/vault/credit-card https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.* https://uri.paypal.com/services/subscriptions https://uri.paypal.com/services/applications/webhooks","access_token":"A21AAGnfER4lNk8rnGB4InaKkTbh-nvewEw3uM4llmAoRwLc9Wkh4wpkVHTQ4-ehe_F-bdgW3Z5EinJgbrmK3Eu4ffds-YPWQ","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":29668,"nonce":"2019-11-16T22:13:00Zb0kTBXRvIaKfKQ0AM3T6Q4e4RUih0srGp6GSlBENIeI"}evex@evex:/var/www/evex$ > On Nov 16, 2019, at 15:56, Iuri Sampaio <iu...@iu...> wrote: > > Dear Gustaf, > It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5> > Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"] > I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs. > https://evex.co/paypal-checkout <https://evex.co/paypal-checkout> > > > Notice: HTTP > status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256} > > > > I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned. > Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side. > > > Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > > > > Best wishes, > I > [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name. > [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > > > > > [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout ******* > >> On Nov 16, 2019, at 15:47, Iuri Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote: >> >> Dear Gustaf, >> It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5> >> Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"] >> I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs. >> https://evex.co/paypal-checkout <https://evex.co/paypal-checkout> >> >> >> Notice: HTTP >> status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256} >> >> >> Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) >> >> >> I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned. >> Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side. >> >> >> Best wishes, >> I >> [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name. >> [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) >> >> >> >> >> [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) >> [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout ******* >> >> >> >> >>> On Nov 16, 2019, at 08:58, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>> wrote: >>> >>> Dear Iuri, >>> >>> Let's start with a simple example: make a GET request to a service, which >>> requires basic authentication >>> % ns_http run https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/> >>> status 401 time 0:513863 headers d11 body {<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >>> "http://www.w3.org/TR/html4/loose.dtd" <http://www.w3.org/TR/html4/loose.dtd>> >>> <html> >>> <head> >>> ... >>> >>> NaviServer returns (starting with 4.99.17) for "ns_http run" a Tcl dict with >>> the relevant information. The request above returns the HTTP status >>> code 401, which means "Unauthorized". >>> >>> Ok, now add some Authorization. As defined by RFC 7617, one has to add an >>> Authorization request header field with user:id:password encoded in base64. >>> % set h [ns_set create] >>> % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]" >>> % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/> >>> status 200 time 0:485802 headers d8 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> >>> <html> >>> <head> >>> ... >>> >>> Now we see the status code 200, which means that the Authentication was ok. >>> If you still get a status code of 401, probably userid and/or password are not ok. >>> >>> Hope this helps. >>> -gn >>> >>> On 15.11.19 16:21, Iuri Sampaio wrote: >>>> What would be the argument/switch to convert the option -u, from CURL command, to ns_http command? >>>> >>>> curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \ >>>> -H "Accept: application/json" \ >>>> -H "Accept-Language: en_US" \ >>>> -u "client_id:secret" \ >>>> -d "grant_type=client_credentials" >>> >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... <mailto:nav...@li...> >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel> >> > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Iuri S. <iu...@iu...> - 2019-11-16 19:06:30
|
Dear Gustaf, It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5> Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"] I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs. https://evex.co/paypal-checkout <https://evex.co/paypal-checkout> Notice: HTTP status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256} Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned. Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side. Best wishes, I [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name. [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout ******* > On Nov 16, 2019, at 08:58, Gustaf Neumann <ne...@wu...> wrote: > > Dear Iuri, > > Let's start with a simple example: make a GET request to a service, which > requires basic authentication > % ns_http run https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/> > status 401 time 0:513863 headers d11 body {<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > "http://www.w3.org/TR/html4/loose.dtd" <http://www.w3.org/TR/html4/loose.dtd>> > <html> > <head> > ... > > NaviServer returns (starting with 4.99.17) for "ns_http run" a Tcl dict with > the relevant information. The request above returns the HTTP status > code 401, which means "Unauthorized". > > Ok, now add some Authorization. As defined by RFC 7617, one has to add an > Authorization request header field with user:id:password encoded in base64. > % set h [ns_set create] > % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]" > % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/> > status 200 time 0:485802 headers d8 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> > <html> > <head> > ... > > Now we see the status code 200, which means that the Authentication was ok. > If you still get a status code of 401, probably userid and/or password are not ok. > > Hope this helps. > -gn > > On 15.11.19 16:21, Iuri Sampaio wrote: >> What would be the argument/switch to convert the option -u, from CURL command, to ns_http command? >> >> curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \ >> -H "Accept: application/json" \ >> -H "Accept-Language: en_US" \ >> -u "client_id:secret" \ >> -d "grant_type=client_credentials" > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Iuri S. <iu...@iu...> - 2019-11-16 19:04:04
|
Dear Gustaf, It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5> Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"] I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs. https://evex.co/paypal-checkout <https://evex.co/paypal-checkout> Notice: HTTP status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256} I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned. Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side. Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) Best wishes, I [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name. [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout ******* > On Nov 16, 2019, at 15:47, Iuri Sampaio <iu...@iu...> wrote: > > Dear Gustaf, > It did help me to remind and review my own code to assure that it was properly written. I grabbed the code from https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#5> > Plus, I switched to ns_base40encode. Before I was using Openacs [base64::encode “${client}:${secret}"] > I've used the very first, basic and simple example (i.e. http queue and http wait), and still, I get the same logs. > https://evex.co/paypal-checkout <https://evex.co/paypal-checkout> > > > Notice: HTTP > status 0 time 0:215139 headers d5 body {} https {sslversion TLSv1.2 cipher AES256-SHA256} > > > Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > > > I’m able to change credentials whenever I want to get 400 error to return. That means the credentials passed in the header were properly assigned. > Even though I agree I need to talk to the guys on PayPal, in case I missed any parameter to allow connectivity on their side. > > > Best wishes, > I > [16/Nov/2019:15:36:11][450.7f7a87fff700][-conn:evex:124:46257-] Warning: /paypal-checkout has no doc(title) set, fallback to instance_name. > [16/Nov/2019:15:36:23][450.7f7a87fff700][-conn:evex:124:46259-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > > > > > [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>) > [16/Nov/2019:15:46:05][450.7f7a87fff700][-conn:evex:124:46273-] Notice: RETURN URL /paypal-checkout ******* > > > > >> On Nov 16, 2019, at 08:58, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>> wrote: >> >> Dear Iuri, >> >> Let's start with a simple example: make a GET request to a service, which >> requires basic authentication >> % ns_http run https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/> >> status 401 time 0:513863 headers d11 body {<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >> "http://www.w3.org/TR/html4/loose.dtd" <http://www.w3.org/TR/html4/loose.dtd>> >> <html> >> <head> >> ... >> >> NaviServer returns (starting with 4.99.17) for "ns_http run" a Tcl dict with >> the relevant information. The request above returns the HTTP status >> code 401, which means "Unauthorized". >> >> Ok, now add some Authorization. As defined by RFC 7617, one has to add an >> Authorization request header field with user:id:password encoded in base64. >> % set h [ns_set create] >> % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]" >> % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/> >> status 200 time 0:485802 headers d8 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> >> <html> >> <head> >> ... >> >> Now we see the status code 200, which means that the Authentication was ok. >> If you still get a status code of 401, probably userid and/or password are not ok. >> >> Hope this helps. >> -gn >> >> On 15.11.19 16:21, Iuri Sampaio wrote: >>> What would be the argument/switch to convert the option -u, from CURL command, to ns_http command? >>> >>> curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \ >>> -H "Accept: application/json" \ >>> -H "Accept-Language: en_US" \ >>> -u "client_id:secret" \ >>> -d "grant_type=client_credentials" >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... <mailto:nav...@li...> >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Gustaf N. <ne...@wu...> - 2019-11-16 11:58:33
|
Dear Iuri, Let's start with a simple example: make a GET request to a service, which requires basic authentication % ns_http run https://jigsaw.w3.org/HTTP/Basic/ status 401 time 0:513863 headers d11 body {<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> ... NaviServer returns (starting with 4.99.17) for "ns_http run" a Tcl dict with the relevant information. The request above returns the HTTP status code 401, which means "Unauthorized". Ok, now add some Authorization. As defined by RFC 7617, one has to add an Authorization request header field with user:id:password encoded in base64. % set h [ns_set create] % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]" % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ status 200 time 0:485802 headers d8 body {<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <html> <head> ... Now we see the status code 200, which means that the Authentication was ok. If you still get a status code of 401, probably userid and/or password are not ok. Hope this helps. -gn On 15.11.19 16:21, Iuri Sampaio wrote: > What would be the argument/switch to convert the option -u, from CURL > command, to ns_http command? > > |curl -v https://myhost.com/oauth2/token > <https://myhost.com/oauth2/token> \ -H "Accept: application/json" \ -H > "Accept-Language: en_US" \ -u "client_id:secret" \ -d > "grant_type=client_credentials"| |
|
From: Iuri S. <iu...@iu...> - 2019-11-15 18:09:12
|
The same request returns successfully in python, as in
conn = http.client.HTTPConnection("api,sandbox,paypal,com")
payload = "grant_type=client_credentials"
headers = {
'Content-Type': "application/x-www-form-urlencoded",
'Authorization': "Basic QVF5YS10UmFKUlIzTVVHQVY2MTg4OVl5eEc1MFdmUlhhZEtLYWZqU0hpRUZxT195WGRFNWR3T01BdC1NeklMeU54S2Y3XzNHM3JuYmx1aWE6RVBYQjUxREhLY3RqemtzUzJqUUhwbWVFckdRWnpwalRxZmZGZ3VhZlRUNm1lVFRmTF9VNG1MYVF4MDFFLVRXcEw0MmlHVkNxSkFIQmNSYkE=",
'User-Agent': "PostmanRuntime/7.15.0",
'Accept': "*/*",
'Cache-Control': "no-cache",
'Postman-Token': "1b42b98e-5c36-4d2b-958c-91463fef648c,269500a1-20d2-479f-90fb-fb2706a7475a",
'Host': "api.sandbox.paypal.com",
'accept-encoding': "gzip, deflate",
'content-length': "29",
'Connection': "keep-alive",
'cache-control': "no-cache"
}
conn.request("POST", "v1,oauth2,token", payload, headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8”))
The result is
{"scope":"https://uri.paypal.com/services/invoicing https://uri.paypal.com/services/disputes/read-buyer https://uri.paypal.com/services/payments/realtimepayment https://uri.paypal.com/services/disputes/update-seller https://uri.paypal.com/services/payments/payment/authcapture openid https://uri.paypal.com/services/disputes/read-seller https://uri.paypal.com/services/payments/refund https://api.paypal.com/v1/vault/credit-card https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.* https://uri.paypal.com/services/subscriptions https://uri.paypal.com/services/applications/webhooks","access_token":"A21Ajrtihjrujhirjhiojheioji5wt83qyt78y3785y7845FEWRGFERHGIEGEWGzpuO0xg_I75pmqFAoSIuArLnfQIoBPdJLdyKSgig","token_type":"Bearer","app_id":"APP-876543FSDFSFP519543T","expires_in":32400,"nonce":"2019-11-15T16:00:40ZlUhzF8DCS6fFc88NwHf-BjiJZv6_DdVG4J8MU5VaHC0"}
> On Nov 15, 2019, at 14:48, Iuri Sampaio <iu...@iu...> wrote:
>
> So far, I added the line
>
> ns_set update $requestHeaders "Authorization" "Basic $auth_base64"
>
> which is using
> set auth_base64 [base64::encode “********”]
>
> and the results are
>
> [15/Nov/2019:13:19:55][450.7f7a7d7fa700][task:tclhttp] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token <https://api.sandbox.paypal.com/v1/oauth2/token>)
> [15/Nov/2019:13:19:55][450.7f7a65ffb700][-conn:evex:88:31735-] Notice: status code 0
> [15/Nov/2019:13:19:55][450.7f7a65ffb700][-conn:evex:88:31735-] Notice: reply
> [
>
>
>> On Nov 15, 2019, at 12:21, Iuri Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote:
>>
>> What would be the argument/switch to convert the option -u, from CURL command, to ns_http command?
>>
>> curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \
>> -H "Accept: application/json" \
>> -H "Accept-Language: en_US" \
>> -u "client_id:secret" \
>> -d "grant_type=client_credentials"
>>
>>
>>
>> Reading ns_http documentation I was not able to figure that out.
>> https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#section3 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#section3>
>>
>>
>>
>> set url "https://myhost.com/v1/oauth2/token <https://myhost.com/v1/oauth2/token>"
>> set requestHeaders [ns_set create]
>> set replyHeaders [ns_set create]
>>
>> ns_set update $requestHeaders "Content-Type" "application/json"
>> ns_set update $requestHeaders "Accept" "application/json"
>> ns_set update $requestHeaders "Accept-Language" "en_US"
>>
>> set data "grant_type=client_credentials"
>>
>>
>> set result [ns_http queue -method POST \
>> -headers $requestHeaders \
>> -timeout 10.0 \
>> -body $data \
>> $url]
>> ns_http wait -result R -headers $replyHeaders -status S $result
>>
>>
>>
>>
>> Best wishes,
>> I
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li... <mailto:nav...@li...>
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Iuri S. <iu...@iu...> - 2019-11-15 18:07:56
|
So far, I added the line ns_set update $requestHeaders "Authorization" "Basic $auth_base64" which is using set auth_base64 [base64::encode “********”] and the results are [15/Nov/2019:13:19:55][450.7f7a7d7fa700][task:tclhttp] Notice: HttpTaskRecv: connection probably closed by server (url https://api.sandbox.paypal.com/v1/oauth2/token) [15/Nov/2019:13:19:55][450.7f7a65ffb700][-conn:evex:88:31735-] Notice: status code 0 [15/Nov/2019:13:19:55][450.7f7a65ffb700][-conn:evex:88:31735-] Notice: reply [ > On Nov 15, 2019, at 12:21, Iuri Sampaio <iu...@iu...> wrote: > > What would be the argument/switch to convert the option -u, from CURL command, to ns_http command? > > curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \ > -H "Accept: application/json" \ > -H "Accept-Language: en_US" \ > -u "client_id:secret" \ > -d "grant_type=client_credentials" > > > > Reading ns_http documentation I was not able to figure that out. > https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#section3 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#section3> > > > > set url "https://myhost.com/v1/oauth2/token <https://myhost.com/v1/oauth2/token>" > set requestHeaders [ns_set create] > set replyHeaders [ns_set create] > > ns_set update $requestHeaders "Content-Type" "application/json" > ns_set update $requestHeaders "Accept" "application/json" > ns_set update $requestHeaders "Accept-Language" "en_US" > > set data "grant_type=client_credentials" > > > set result [ns_http queue -method POST \ > -headers $requestHeaders \ > -timeout 10.0 \ > -body $data \ > $url] > ns_http wait -result R -headers $replyHeaders -status S $result > > > > > Best wishes, > I > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Iuri S. <iu...@iu...> - 2019-11-15 15:40:46
|
What would be the argument/switch to convert the option -u, from CURL command, to ns_http command? curl -v https://myhost.com/oauth2/token <https://myhost.com/oauth2/token> \ -H "Accept: application/json" \ -H "Accept-Language: en_US" \ -u "client_id:secret" \ -d "grant_type=client_credentials" Reading ns_http documentation I was not able to figure that out. https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#section3 <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html#section3> set url "https://myhost.com/v1/oauth2/token <https://myhost.com/v1/oauth2/token>" set requestHeaders [ns_set create] set replyHeaders [ns_set create] ns_set update $requestHeaders "Content-Type" "application/json" ns_set update $requestHeaders "Accept" "application/json" ns_set update $requestHeaders "Accept-Language" "en_US" set data "grant_type=client_credentials" set result [ns_http queue -method POST \ -headers $requestHeaders \ -timeout 10.0 \ -body $data \ $url] ns_http wait -result R -headers $replyHeaders -status S $result Best wishes, I |
|
From: Gustaf N. <ne...@wu...> - 2019-11-06 19:54:46
|
On 06.11.19 17:52, David Osborne wrote: > The RSS size of our nsd process is often ~2GB but does occasionally > stray as far as 4GB. the RSS chart looks quite ok in terms of growth. What you can see it that when using zippy malloc, the memory never shrinks. So, one i more likely running into memory problems, when the machine has limited resources. So, probably some weekly restarts might help as well to come back from 4GB to 2GB.... One thing, you have to watch out concerning memory size is to avoid reading files into Tcl_Objs (sooner or later, one encounters large file) or - even worse - appending to large strings. Tcl has a memory-doubling strategy (it over-allocates memory such it can do append operations quickly). So, when you add a single byte to a Tcl_Obj with e.g. 500MB, you might end up with 1GB memory allocation for a single Tcl_Obj. Using nsproxy: you might look at the "exec" definition of OpenACS. It redefines Tcl's "exec" via a proxy::exec using nsproxy [1]. > is the patch referred to online somewhere? look into [2]. all the best -g [1] https://github.com/openacs/openacs-core/blob/oacs-5-10/packages/acs-tcl/tcl/proxy-procs.tcl [2] https://github.com/gustafn/install-ns/blob/master/install-ns.sh#L501 |
|
From: David O. <da...@qc...> - 2019-11-06 17:22:43
|
Hi Gustaf, Thanks for the very detailed response! I had an inkling that nsproxy might be the answer - we'll look at making this change. The RSS size of our nsd process is often ~2GB but does occasionally stray as far as 4GB. (The small spike on the right of the attached graph is when this particular problem occurred). Looking at your graph I've very little doubt we'd see benefit from using TCMalloc. I found this comment from you about how to go about it... is the patch referred to online somewhere? https://sourceforge.net/p/naviserver/mailman/message/31805358/ [image: image.png] Thanks again Gustaf, Regards, David On Fri, 1 Nov 2019 at 20:46, Gustaf Neumann <ne...@wu...> wrote: > Dear David, > > Technically, every unix fork() creates a new process by duplicating the > calling process. > If the calling process is large this can lead to the problem you are > mentioning. > However, on Linux uses a copy-on-write. This means that while after the > fork, > both processes might show RSS of 4GB, but it does not mean that 8GB are > really > used. However, based on the overcommit_memory settings, it might be > the case that the oom killer kicks in. > > Concerning your configuration: Are you using nsproxy? This module was made > for addressing this issue (instead of forking on every Tcl "exec", the > command is > sent via pipe to a second process that executes it. This process has > typically > a much smaller memory footprint, so the problem does not become worse, > when nsd uses are huge memory footprint). > > Do you monitor the size of nsd over time? Is it normal that nsd has > with the given configuration 4GB RSS? There might be a problem with the > application code causing some memory growth. The chart below is > generated with munin and the munin-plugins-ns from > https://github.com/gustafn/munin-plugins-ns (some plugins are for OpenACS, > some are fine for every NaviServer installation). > > Do you you system-malloc? One can reduce the size of the memory > footprint significantly by using SYSTEM_MALLOC together with > TCMalloc (see e.g. > https://next-scripting.org/2.3.0/doc/misc/thread-mallocs). > The following chart show the effects on openacs.org, when i switched > to SYSTEM_MALLOC + TCMalloc around August (same code, some > number of requests, etc.) > > -g > > > [image: yearly graph] > > On 01.11.19 18:02, David Osborne wrote: > > Hi, > > I was wondering if anyone could point us in the right direction with an > intermittent problem we're seeing. Apologies for the wooly problem > description - we don't have a firm test case as of yet. > > These instances are running NaviServer/4.99.16d10 on Debian Jessie 8.10 > > The problem usually manifests itself as memory exhaustion on the server in > question where the system's OOM killer is invoked. > > What seems to be causing the memory exhaustion is a copy of the main nsd > process (sometimes several) which can use large amounts of memory. > > For example we captured a snapshot of this copy of the nsd daemon (also > using 4gb RSS) after it had been running for about 5 hours. > > [image: image.png] > > It appears as if there are 2 of main nsd daemons running. Usually only 1 > nsd daemon is running on this server. > > When this child was killed by the OOM killer, it was a Tcl exec of an > external command which was running within it - not a command that would > normally 5 hours to complete. > > child killed: kill signal > while executing > "exec $cmd << $input" > > In test, when running an exec from naviserver, I see the forked process > being created and initially named "nsd", then it takes on the name of the > underlying command. I'm not sure why this isn't happening in these cases. > > Any insights? > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Gustaf N. <ne...@wu...> - 2019-11-01 20:46:27
|
Dear David, Technically, every unix fork() creates a new process by duplicating the calling process. If the calling process is large this can lead to the problem you are mentioning. However, on Linux uses a copy-on-write. This means that while after the fork, both processes might show RSS of 4GB, but it does not mean that 8GB are really used. However, based on the overcommit_memory settings, it might be the case that the oom killer kicks in. Concerning your configuration: Are you using nsproxy? This module was made for addressing this issue (instead of forking on every Tcl "exec", the command is sent via pipe to a second process that executes it. This process has typically a much smaller memory footprint, so the problem does not become worse, when nsd uses are huge memory footprint). Do you monitor the size of nsd over time? Is it normal that nsd has with the given configuration 4GB RSS? There might be a problem with the application code causing some memory growth. The chart below is generated with munin and the munin-plugins-ns from https://github.com/gustafn/munin-plugins-ns (some plugins are for OpenACS, some are fine for every NaviServer installation). Do you you system-malloc? One can reduce the size of the memory footprint significantly by using SYSTEM_MALLOC together with TCMalloc (see e.g. https://next-scripting.org/2.3.0/doc/misc/thread-mallocs). The following chart show the effects on openacs.org, when i switched to SYSTEM_MALLOC + TCMalloc around August (same code, some number of requests, etc.) -g yearly graph On 01.11.19 18:02, David Osborne wrote: > Hi, > > I was wondering if anyone could point us in the right direction with > an intermittent problem we're seeing. Apologies for the wooly problem > description - we don't have a firm test case as of yet. > > These instances are running NaviServer/4.99.16d10 on Debian Jessie 8.10 > > The problem usually manifests itself as memory exhaustion on the > server in question where the system's OOM killer is invoked. > > What seems to be causing the memory exhaustion is a copy of the main > nsd process (sometimes several) which can use large amounts of memory. > > For example we captured a snapshot of this copy of the nsd daemon > (also using 4gb RSS) after it had been running for about 5 hours. > > image.png > > It appears as if there are 2 of main nsd daemons running. Usually only > 1 nsd daemon is running on this server. > > When this child was killed by the OOM killer, it was a Tcl exec of an > external command which was running within it - not a command that > would normally 5 hours to complete. > > child killed: kill signal > while executing > "exec $cmd << $input" > In test, when running an exec from naviserver, I see the forked > process being created and initially named "nsd", then it takes on the > name of the underlying command. I'm not sure why this isn't happening > in these cases. > > Any insights? |
|
From: David O. <da...@qc...> - 2019-11-01 17:33:58
|
Hi,
I was wondering if anyone could point us in the right direction with an
intermittent problem we're seeing. Apologies for the wooly problem
description - we don't have a firm test case as of yet.
These instances are running NaviServer/4.99.16d10 on Debian Jessie 8.10
The problem usually manifests itself as memory exhaustion on the server in
question where the system's OOM killer is invoked.
What seems to be causing the memory exhaustion is a copy of the main nsd
process (sometimes several) which can use large amounts of memory.
For example we captured a snapshot of this copy of the nsd daemon (also
using 4gb RSS) after it had been running for about 5 hours.
[image: image.png]
It appears as if there are 2 of main nsd daemons running. Usually only 1
nsd daemon is running on this server.
When this child was killed by the OOM killer, it was a Tcl exec of an
external command which was running within it - not a command that would
normally 5 hours to complete.
child killed: kill signal
while executing
"exec $cmd << $input"
In test, when running an exec from naviserver, I see the forked process
being created and initially named "nsd", then it takes on the name of the
underlying command. I'm not sure why this isn't happening in these cases.
Any insights?
--
*David *
|
|
From: Gustaf N. <ne...@wu...> - 2019-10-29 12:26:38
|
Dear Wolfgang, thanks for the report. i could reconstruct the issue (the only one?), which can happen when writerstreaming is turned on (default is off) in the config file. The issue is fixed by [1] I do not see an issue with the "ns_writer size". However, while at the issue, i added change [2] to support use of memory units instead of plain integers. for the size. One can use now e.g. ns_writer size nssock 150KB Do you see still some leak in your configuration with this changes (in other words: is for you the high "ns_writer size" necessary? all the best -g [1] https://bitbucket.org/naviserver/naviserver/commits/e5a66b0d9184e88d59d01f4d435827e73b470fe5 [2] https://bitbucket.org/naviserver/naviserver/commits/5176741d8d1e468de9e8830f2e5d8553eb9c0b9c On 28.10.19 09:17, Wolfgang Winkler wrote: > Dear Gustaf! > > Unfortunately I didn't see your answer below and found it a few days > ago at Sourceforge in the mailinglist history. > > I deactivated the nscgi module, which we only use for awstats output. > This did not change the behaviour. So I checked all calls to > Ns_GetTemp(void) and found a possible culprit in NsWriterQueue(...). > > I changed the following parameters: > > ns_writer streaming nssock false; # was true > ns_writer size nssock [expr 15*1024*1024]; # was 15000 > > The number of open files has been stable since. > > Yours, > > Wolfgang > > > -------------------- > > From: Gustaf Neumann <neumann@wu...> - 2019-07-22 12:35:27 > > Dear Wolfgang, > > we do not see any growth in this area, below are statistics > from two different sites. > > monthly graph > > > These files are from Ns_GetTemp() which maintains a pool of tmp files, > which are released via Ns_ReleaseTemp(). This pool is maintained like > this since many years. > > One of the consumers of Ns_GetTemp() is nscgi. Are you using this module > on the site experiences the growing number? > > -g > > > Am 22.07.19 um 10:22 schrieb Wolfgang Winkler: >> >> Dear all, >> >> out naviserver instance opens a lot of files. It used to be constant >> 200 open files, now the number ist constantly growing, from 110 after >> a server restart to > 1000. >> >> What we see with "lsof -n" are a lot of files in tmp, e.g. >> /tmp/nstmp.1563598239.865582 that obivously never get closed. >> >> We updated from 4.99.17 to 4.99.18 but the problem persists. >> >> Does anybody have an idea what could cause this behaviour? We checked >> all our changes to the system and could not find the cause. >> >> Regards, >> >> Wolfgang Winkler >> >> -- >> >> *Wolfgang Winkler* >> Geschäftsführung >> wol...@di... >> mobil +43.699.19971172 >> >> dc:*büro* >> digital concepts Novak Winkler OG >> Software & Design >> Landstraße 68, 5. Stock, 4020 Linz >> www.digital-concepts.com <http://www.digital-concepts.com> >> tel +43.732.997117.72 >> tel +43.699.1997117.2 >> >> Firmenbuchnummer: 192003h >> Firmenbuchgericht: Landesgericht Linz >> >> >> >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Wolfgang W. <wol...@di...> - 2019-10-28 08:44:13
|
Dear Gustaf! Unfortunately I didn't see your answer below and found it a few days ago at Sourceforge in the mailinglist history. I deactivated the nscgi module, which we only use for awstats output. This did not change the behaviour. So I checked all calls to Ns_GetTemp(void) and found a possible culprit in NsWriterQueue(...). I changed the following parameters: ns_writer streaming nssock false; # was true ns_writer size nssock [expr 15*1024*1024]; # was 15000 The number of open files has been stable since. Yours, Wolfgang -------------------- From: Gustaf Neumann <neumann@wu...> - 2019-07-22 12:35:27 Dear Wolfgang, we do not see any growth in this area, below are statistics from two different sites. monthly graph These files are from Ns_GetTemp() which maintains a pool of tmp files, which are released via Ns_ReleaseTemp(). This pool is maintained like this since many years. One of the consumers of Ns_GetTemp() is nscgi. Are you using this module on the site experiences the growing number? -g Am 22.07.19 um 10:22 schrieb Wolfgang Winkler: > > Dear all, > > out naviserver instance opens a lot of files. It used to be constant > 200 open files, now the number ist constantly growing, from 110 after > a server restart to > 1000. > > What we see with "lsof -n" are a lot of files in tmp, e.g. > /tmp/nstmp.1563598239.865582 that obivously never get closed. > > We updated from 4.99.17 to 4.99.18 but the problem persists. > > Does anybody have an idea what could cause this behaviour? We checked > all our changes to the system and could not find the cause. > > Regards, > > Wolfgang Winkler > > -- > > *Wolfgang Winkler* > Geschäftsführung > wol...@di... > mobil +43.699.19971172 > > dc:*büro* > digital concepts Novak Winkler OG > Software & Design > Landstraße 68, 5. Stock, 4020 Linz > www.digital-concepts.com <http://www.digital-concepts.com> > tel +43.732.997117.72 > tel +43.699.1997117.2 > > Firmenbuchnummer: 192003h > Firmenbuchgericht: Landesgericht Linz > > > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- *Wolfgang Winkler* Geschäftsführung wol...@di... mobil +43.699.19971172 dc:*büro* digital concepts Novak Winkler OG Software & Design Landstraße 68, 5. Stock, 4020 Linz www.digital-concepts.com <http://www.digital-concepts.com> tel +43.732.997117.72 tel +43.699.1997117.2 Firmenbuchnummer: 192003h Firmenbuchgericht: Landesgericht Linz |
|
From: THORPE M. <ta...@me...> - 2019-09-18 11:30:12
|
Gustaf,
Thank you for your help and for the background information.
Thorpe
> On Sep 18, 2019, at 1:43 AM, Gustaf Neumann <ne...@wu...> wrote:
>
> Dear Thorpe,
>
> There is a problem with the nsdbi* drivers when the cache used for prepared statements runs out. The driver deallocates in such situations a prepared statement before being able to add the new one. On a busy server, it might run in the same, when preparing the next SQL statement, and so on. In such situations, performance will drop drastically. The worst are SQL statements with filled-in constants (tcl-substituted values) or "IN" clauses.
> Try to avoid these.
>
> Some background: A few years ago, i generalized the OpenACS SQL interface to work either with the nsdbi* driver family or with the good old nsdb* family. On our busy OpenACS servers the dbi-driver was sooner or later dropping due to the mentioned reasons in such (re)allocation loops. Due to lack in resources on my side, i never tried to solve the problem in nsdbi* to avoid such problems. We switched on on all major installations back to nsdb*.
>
> Since the configured cache listed below is just 1MB (which is nothing on today's machines), i would recommend to increase it substantially (e.g. to 10MB), unless you have good reasons for not doing so. ... and replace ".. WHERE name = '$name' ... " by ".. WHERE name = :name ... " if not done already.
>
> -gn
>
> On 17.09.19 20:57, THORPE MAYES via naviserver-devel wrote:
>> Hi,
>>
>> This happened today:
>>
>> I was getting thousands of these lines in my server log:
>>
>> [17/Sep/2019:07:59:07][4924.7f82467f4700][-conn:mealdeliverysoftware:19:25314-] Notice: dbipg: prepare dbipg_6242353/0 cols 0: deallocate dbipg_6238059
>> [17/Sep/2019:07:59:07][4924.7f82467f4700][-conn:mealdeliverysoftware:19:25314-] Notice: dbipg: prepare dbipg_6242354/0 cols 0: deallocate dbipg_6238060
>> [17/Sep/2019:07:59:07][4924.7f82467f4700][-conn:mealdeliverysoftware:19:25314-] Notice: dbipg: prepare dbipg_6242355/0 cols 0: deallocate dbipg_6238061
>>
>> I restarted the server and the problem went away (maybe).
>>
>> My guess is that configuration is either wrong or not complete. Here is the section in my config file that deals with this:
>>
>> # database configuration
>> ns_section "ns/server/${servername}/module/xxxxx"
>> ns_param default true ;# This is the default pool for mds
>> ns_param handles 2 ;# Max open handles to db.
>> ns_param maxwait 10 ;# Seconds to wait if handle unavailable.
>> ns_param maxidle 0 ;# Handle closed after maxidle seconds if unused.
>> ns_param maxopen 0 ;# Handle closed after maxopen seconds, regardles of use.
>> ns_param maxqueries 0 ;# Handle closed after maxqueries sql queries.
>> ns_param checkinterval 600 ;# Check for idle handles every 10 minutes.
>>
>> ns_param maxhandles 0
>> ns_param timeout 10
>> ns_param maxrows 1000
>>
>> ns_param cachesize [expr 1024*1024]
>>
>> # The following parameters are configured at server-startup.
>> ns_param user “xxxxxx"
>> ns_param password xxxxxxx
>> ns_param database “xxxxxx"
>> ns_param datasource "user=‘xxxxx' password=‘xxxxx' dbname=‘xxxxxx’"
>>
>>
>> This is also in the config file for my legacy code:
>> # database pool configuration
>> ns_section "ns/db/pool/${default_pool}"
>> ns_param driver postgres
>> ns_param connections 40
>> ns_param datasource localhost:5432:${database_name}
>> ns_param user xxxxxx
>> ns_param password xxxxxx
>> ns_param verbose true
>> ns_param logsqlerrors true
>> ns_param extendedtableinfo true
>> ns_param maxidle 1000000000
>> ns_param maxopen 1000000000
>>
>>
>> # Database pools accessible by server
>> ns_section "ns/server/${servername}/db"
>> ns_param pools "*"
>> ns_param defaultpool "${default_pool}"
>>
>>
>>
>> I will appreciate any help/direction.
>>
>> Thank you,
>>
>> Thorpe
>>
>> Thorpe Mayes
>> 2313 Lockhill-Selma Road, Suite 164
>> San Antonio, Texas 78230-3007
>> Phone: (512) 394-8766
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
|
|
From: Gustaf N. <ne...@wu...> - 2019-09-18 06:43:44
|
Dear Thorpe,
There is a problem with the nsdbi* drivers when the cache used for
prepared statements runs out. The driver deallocates in such situations
a prepared statement before being able to add the new one. On a busy
server, it might run in the same, when preparing the next SQL statement,
and so on. In such situations, performance will drop drastically. The
worst are SQL statements with filled-in constants (tcl-substituted
values) or "IN" clauses.
Try to avoid these.
Some background: A few years ago, i generalized the OpenACS SQL
interface to work either with the nsdbi* driver family or with the good
old nsdb* family. On our busy OpenACS servers the dbi-driver was sooner
or later dropping due to the mentioned reasons in such (re)allocation
loops. Due to lack in resources on my side, i never tried to solve the
problem in nsdbi* to avoid such problems. We switched on on all major
installations back to nsdb*.
Since the configured cache listed below is just 1MB (which is nothing on
today's machines), i would recommend to increase it substantially (e.g.
to 10MB), unless you have good reasons for not doing so. ... and replace
".. WHERE name = '$name' ... " by ".. WHERE name = :name ... " if not
done already.
-gn
On 17.09.19 20:57, THORPE MAYES via naviserver-devel wrote:
> Hi,
>
> This happened today:
>
> I was getting thousands of these lines in my server log:
>
> [17/Sep/2019:07:59:07][4924.7f82467f4700][-conn:mealdeliverysoftware:19:25314-]
> Notice: dbipg: prepare dbipg_6242353/0 cols 0: deallocate dbipg_6238059
> [17/Sep/2019:07:59:07][4924.7f82467f4700][-conn:mealdeliverysoftware:19:25314-]
> Notice: dbipg: prepare dbipg_6242354/0 cols 0: deallocate dbipg_6238060
> [17/Sep/2019:07:59:07][4924.7f82467f4700][-conn:mealdeliverysoftware:19:25314-]
> Notice: dbipg: prepare dbipg_6242355/0 cols 0: deallocate dbipg_6238061
>
> I restarted the server and the problem went away (maybe).
>
> My guess is that configuration is either wrong or not complete. Here
> is the section in my config file that deals with this:
>
> # database configuration
> ns_section "ns/server/${servername}/module/xxxxx"
> ns_param default true ;# This is the default pool for mds
> ns_param handles 2 ;# Max open handles to db.
> ns_param maxwait 10 ;# Seconds to wait if handle
> unavailable.
> ns_param maxidle 0 ;# Handle closed after maxidle
> seconds if unused.
> ns_param maxopen 0 ;# Handle closed after maxopen
> seconds, regardles of use.
> ns_param maxqueries 0 ;# Handle closed after maxqueries
> sql queries.
> ns_param checkinterval 600 ;# Check for idle handles every 10
> minutes.
>
> ns_param maxhandles 0
> ns_param timeout 10
> ns_param maxrows 1000
>
> ns_param cachesize [expr1024*1024]
>
> # The following parameters are configured at server-startup.
> ns_param user “xxxxxx"
> ns_param password xxxxxxx
> ns_param database “xxxxxx"
> ns_param datasource "user=‘xxxxx' password=‘xxxxx' dbname=‘xxxxxx’"
>
>
> This is also in the config file for my legacy code:
> # database pool configuration
> ns_section "ns/db/pool/${default_pool}"
> ns_param driver postgres
> ns_param connections 40
> ns_param datasource localhost:5432:${database_name}
> ns_param user xxxxxx
> ns_param password xxxxxx
> ns_param verbose true
> ns_param logsqlerrors true
> ns_param extendedtableinfo true
> ns_param maxidle 1000000000
> ns_param maxopen 1000000000
>
>
> # Database pools accessible by server
> ns_section "ns/server/${servername}/db"
> ns_param pools "*"
> ns_param defaultpool "${default_pool}"
>
>
>
> I will appreciate any help/direction.
>
> Thank you,
>
> Thorpe
>
> Thorpe Mayes
> 2313 Lockhill-Selma Road, Suite 164
> San Antonio, Texas 78230-3007
> Phone: (512) 394-8766
|
14 messages has been excluded from this view by a project administrator.
