Martin, Thanks. I integrated the 'make clean' and I can now run locally modified code.
It turns out I am getting a 400 on receive from: aqbanking-cli request --account=00075XXXXX --transactions --fromdate=20210120 --todate=20210208 Debug output: ... ===== Enter Password ===== Please enter the password for user XXXXXX Input: ****** 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 175: Saving OFX log to "/Users/bobwhite/aqbanking/logs/aqofx.log" ... Saving communication log to /Users/bobwhite/aqbanking/logs/aqofx.log 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 128: RBW _createConnection 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 136: RBW addr https://df3cx-services.1fsapi.com/casm/usaa/access.ofx 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 145: RBW HttpVMajor 0 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 147: RBW HttpVMinor 0 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 151: RBW userAgent InetClntApp/3.0 6:2021/02/11 21-39-57:aqbanking(3280):httpsession.c: 167: Extending TLS SyncIo 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 65: RBW Connect here (0) 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 75: RBW POST (0) 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 88: RBW Recv (400) 3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 99: here (400) 6:2021/02/11 21-39-57:aqbanking(3280):./provider_user.c: 252: Unlocking customer "4563" 8:2021/02/11 21-39-57:aqbanking(3280):provider.c: 82: Destroying AB_PROVIDER (aqofxconnect) accountInfoList { } #accountInfoList securityList { } #securityList messageList { } #messageList Not being familiar with the gwenhywfar lib I haven't been able to see the actual buffer with the content of the POST request. The curl version of the request specified in the aqbanking-cli request above is working. I am including the verbose curl output from the request in the hopes it might provide clues as to whether gwenhywfar supports the interaction it describes, like the switchover to HTTP/2. (In the aqbanking-cli request I also did get a prompt to accept the cert due to "Status : Certificate owner does not match hostname" so it makes me wonder if the subjectAltName is supported.) * Trying 45.60.151.211... * TCP_NODELAY set * Connected to df3cx-services.1fsapi.com (45.60.151.211) 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/pki/tls/certs/ca-bundle.crt CApath: none * 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, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=imperva.com * start date: Jan 20 17:31:41 2021 GMT * expire date: Jul 22 08:26:17 2021 GMT * subjectAltName: host "df3cx-services.1fsapi.com" matched cert's "*.1fsapi.com" * issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R3 DV TLS CA 2020 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x8c3bb0)
POST /casm/usaa/access.ofx HTTP/2 Host: df3cx-services.1fsapi.com User-Agent: InetClntApp/3.0 Accept: */* Content-Type: application/x-ofx Content-Length: 753
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)! * We are completely uploaded and fine < HTTP/2 200 HTTP/2 200 < date: Fri, 12 Feb 2021 02:51:19 GMT date: Fri, 12 Feb 2021 02:51:19 GMT < content-type: application/x-ofx content-type: application/x-ofx < content-length: 5097 content-length: 5097 < vary: Origin vary: Origin < vary: Access-Control-Request-Method vary: Access-Control-Request-Method < vary: Access-Control-Request-Headers vary: Access-Control-Request-Headers < x-content-type-options: nosniff x-content-type-options: nosniff < x-xss-protection: 1; mode=block x-xss-protection: 1; mode=block < cache-control: no-cache, no-store, max-age=0, must-revalidate cache-control: no-cache, no-store, max-age=0, must-revalidate < pragma: no-cache pragma: no-cache < expires: 0 expires: 0 < strict-transport-security: max-age=31536000 ; includeSubDomains strict-transport-security: max-age=31536000 ; includeSubDomains < x-frame-options: DENY x-frame-options: DENY < set-cookie: visid_incap_2454689=MRSRHr7fT6qOqlWtxfrzWSbtJWAAAAAAQUIPAAAAAADEpEAhLOG6NipBTNfV1vXY; expires=Fri, 11 Feb 2022 10:20:34 GMT; HttpOnly; path=/; Domain=.1fsapi.com; Secure; SameSite=None set-cookie: visid_incap_2454689=MRSRHr7fT6qOqlWtxfrzWSbtJWAAAAAAQUIPAAAAAADEpEAhLOG6NipBTNfV1vXY; expires=Fri, 11 Feb 2022 10:20:34 GMT; HttpOnly; path=/; Domain=.1fsapi.com; Secure; SameSite=None < set-cookie: nlbi_2454689=WCVvUDxEvHjvcWozhXBnAwAAAAAtgmMABh/EhEr6j5RNlnax; path=/; Domain=.1fsapi.com; Secure; SameSite=None set-cookie: nlbi_2454689=WCVvUDxEvHjvcWozhXBnAwAAAAAtgmMABh/EhEr6j5RNlnax; path=/; Domain=.1fsapi.com; Secure; SameSite=None < set-cookie: incap_ses_1211_2454689=/vjDaM/xdD+lq06tT1bOECbtJWAAAAAA1PSYV8vjV8nlh6yIjsayog==; path=/; Domain=.1fsapi.com; Secure; SameSite=None set-cookie: incap_ses_1211_2454689=/vjDaM/xdD+lq06tT1bOECbtJWAAAAAA1PSYV8vjV8nlh6yIjsayog==; path=/; Domain=.1fsapi.com; Secure; SameSite=None < x-cdn: Incapsula x-cdn: Incapsula < x-iinfo: 9-6486643-6486644 NNNN CT(8 4 0) RT(1613098275955 0) q(0 0 0 -1) r(29 29) U6 x-iinfo: 9-6486643-6486644 NNNN CT(8 4 0) RT(1613098275955 0) q(0 0 0 -1) r(29 29) U6 < OFXHEADER:100 DATA:OFXSGML VERSION:103 SECURITY:NONE ENCODING:USASCII CHARSET:1252 COMPRESSION:NONE OLDFILEUID:NONE NEWFILEUID:NONE <OFX><SIGNONMSGSRSV1><SONRS> ... I've got gwenhywfar and aqbanking build environments setup on an EC2 instance so as to avoid IP blocking issues mentioned previously by Scott McRae. I hope you can offer some assistance or recommendations for next steps. Regards, Bob On February 11, 2021 at 11:02 AM, Martin Preuss <mar...@aquamaniac.de> wrote: Am 11.02.21 um 01:48 schrieb Bob White: [...] I pulled the latest (on master) but didn't see any commits beyond the uuid fix. I made the following changes, ran 'make && make install', but don't see the NONE reflected in aqbanking-cli requests (they still have time-base NEWFILEUID): [...] Maybe it has to with a bug in the build system, I couldn't figure out why but sometimes you need to do a "make clean" before "make". Sometimes not all sub-libraries files are properly rebuilt... Regards Martin _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
