Am 14.02.21 um 22:12 schrieb Martin Preuss:
[...]
>> * The BankID and Bank Name were set to a string of 0s on the credit card
>> account. I didn't try connecting with the 0s but changed both as Bob White
>> has done.
> Maybe the OFX importer didn't catch those fields...
[...]
Okay, I've had
> On Feb 14, 2021, at 1:12 PM, Martin Preuss wrote:
>
> Am 14.02.21 um 05:04 schrieb John Ralls:
> [...]
>> USAA changed the account number on my credit card account, so I had to
>> retrieve my accounts again in the AQBanking Wizard. I encountered a few
>> problems with that process:
>> *
Am 14.02.21 um 05:04 schrieb John Ralls:
[...]
> USAA changed the account number on my credit card account, so I had to
> retrieve my accounts again in the AQBanking Wizard. I encountered a few
> problems with that process:
> * If the old account was present it wasn't overwritten: I had to
> On Feb 13, 2021, at 6:20 PM, John Ralls wrote:
>
>
>
>> On Feb 12, 2021, at 5:08 PM, Martin Preuss wrote:
>>
>> Hi,
>>
>> Am 13.02.21 um 00:07 schrieb John Ralls:
>> [...]
>>> The next GnuCash release is 6 weeks from Sunday. This has nothing to do
>>> with GnuCash code so that doesn't
> On Feb 12, 2021, at 5:08 PM, Martin Preuss wrote:
>
> Hi,
>
> Am 13.02.21 um 00:07 schrieb John Ralls:
> [...]
>> The next GnuCash release is 6 weeks from Sunday. This has nothing to do with
>> GnuCash code so that doesn't really matter except that it's the next regular
>> opportunity to
Thank you Martin!
-derek
Sent using my mobile device. Please excuse any typos.
On February 12, 2021 8:08:45 PM Martin Preuss wrote:
Hi,
Am 13.02.21 um 00:07 schrieb John Ralls:
[...]
The next GnuCash release is 6 weeks from Sunday. This has nothing to do
with GnuCash code so that doesn't
Hi,
Am 13.02.21 um 00:07 schrieb John Ralls:
[...]
> The next GnuCash release is 6 weeks from Sunday. This has nothing to do with
> GnuCash code so that doesn't really matter except that it's the next regular
> opportunity to update the bundled AQBanking for flatpak, macOS, and Microsoft
>
Bob,
The next GnuCash release is 6 weeks from Sunday. This has nothing to do with
GnuCash code so that doesn't really matter except that it's the next regular
opportunity to update the bundled AQBanking for flatpak, macOS, and Microsoft
Windows. Once Martin releases a new AQBanking version
Martin,
Thanks! Being able to see the header cleared things right up--there was a spurious
"%0A" hanging off the end of the my 'serverAddr' in the user settings file, how
it got there I do not know.
As it turns out, with a proper user config, the current master branches of
gwenhywfar and
Bob,
Am 12.02.21 um 04:40 schrieb Bob White:
[...]
> Not being familiar with the gwenhywfar lib I haven't been able to see the
> actual buffer with the content of the POST request.
[...]
You could increase the logelvel of libgwen to "debug", that should show the
header sent (among many, many
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=00075X --transactions --fromdate=20210120
--todate=20210208
Debug output:
...
= Enter Password =
Please enter
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):
Martin,
Bob,
Am 10.02.21 um 04:09 schrieb Bob White via gnucash-devel:
[...]
With further curl testing I have discovered that the NEWFILEUID apparently now
requires an actual UUID or the value NONE. You can see my working examples in
my previous post to the list.
[...]
Thanks, I changed it
Bob,
Am 10.02.21 um 04:09 schrieb Bob White via gnucash-devel:
[...]
> With further curl testing I have discovered that the NEWFILEUID apparently
> now requires an actual UUID or the value NONE. You can see my working
> examples in my previous post to the list.
[...]
Thanks, I changed it to
Martin,
With further curl testing I have discovered that the NEWFILEUID apparently now
requires an actual UUID or the value NONE. You can see my working examples in
my previous post to the list.
Any attempt to use time-based NEWFILEUID, e.g. 20210209212246.000, results in:
Error
I attempted to use AqBanking's TRNUID, and something on the far side
returned a Java.IO error instead of any useful info. Some experimentation
shows it must be a UUID.
I ran my experiments with APPVER of 2300 and this worked. The curl command
Scott provided works, I think the typo was in his
The encryption is all standard HTTPS (which is HTTP over TLS). It is
encrypted in both directions on the network. But if you are terminating the
TLS (a.k.a. SSL) connection, you get to see the unencrypted data from both
directions. This is what a man-in-the-middle does.
On Sun, Feb 7, 2021 at
I'm you want something a bit more automated, I came across mitm-proxy in
searches:
https://mitmproxy.org/
This should take care of generating certificates automatically and actually
do the forwarding, etc. You'll need to generate a CA cert for it and
install that in your trusted certificates.
>>* So I decided to give the devil his due and temporarily got a Quicken
*>>* subscription and setup an SSL man-in-the-middle.
*>Sure, you can have a man-in-the-middle setup, but if you don't have the
>keys that quicken and the bank use to communicate and communications are
>encoded, you can't get
Hi,
nicely done!!
Some notes reagarding AqBanking's OFX Direct Connect plugin:
Am 07.02.21 um 05:45 schrieb Scott McRae:
[...]
> Some things I've found through trial and error:
> - The OFX elements must be separated with "\r\n". This is dumb, but true.
> No spaces. No simple "\n". Exactly
I extracted the Client ID from the enroll URL. After entering USAA
credentials, the page is redirected to
https://www.usaa.com/inet/ent_oauth_consent/authorize?0_id=----;
. I used that client_id as my clientuid. I received unauthoried message
using the clientuid
Overall I can confirm that this approach works, I have gotten both
account lists and transactions. Two details on this:
" - TRNUID must be present, but an UUID will do." More specifically,
it seems it must be a UUID. Aqbanking/Gnucash create a date based ID,
and this fails (the far server
OK I get it, nothing on top of https.
Thanks for all this great info.
J.
On 2/7/2021 7:53 PM, Scott McRae wrote:
The encryption is all standard HTTPS (which is HTTP over TLS). It is
encrypted in both directions on the network. But if you are
terminating the TLS (a.k.a. SSL) connection, you
Oh cool!
Thanks for the pointer.
One more question: is the ofx data encrypted on the way back to your
side of things? It does not look like it is since you're able to
download your data once you know all the parameter of the "traditional"
ofx query, is that right?
J.
On 2/7/2021 7:28 PM,
Wow, that's really cool. I would love to replicate that to be able to
connect to my bank as I'm sure many would. I wonder if there would be a
way to make that a bit easier than completely manually.
At the moment, I have a python script that logs into my bank, make the
right clicks and downloads
On Sun, Feb 7, 2021 at 5:10 PM Jean L wrote:
> Sure, you can have a man-in-the-middle setup, but if you don't have the
> keys that quicken and the bank use to communicate and communications are
> encoded, you can't get any data from being in the middle, unless I'm
> missing something.
You
Great work Scott and others. I used the CLIENTID from the URL when
registering using the Authorization link (
https://df3cx-services.1fsapi.com/casm/usaa/enroll). It seems the account
Authorization is tied to this ClientID.
Cory
On Sun, Feb 7, 2021 at 4:13 AM Scott McRae wrote:
> I got this
As Scott mentioned in his mail:
So I decided to give the devil his due and temporarily got a Quicken
subscription and setup an SSL man-in-the-middle.
Sure, you can have a man-in-the-middle setup, but if you don't have the
keys that quicken and the bank use to communicate and communications are
On Sonntag, 7. Februar 2021 18:00:36 CET Jean L wrote:
> Wow! That's dedication!
> I have to admit, the same thing happened with my Credit Union (Patelco)
> and I didn't have the dedication to do what you did!
> Kudos to you. It's really maddening, like you say, that apparently the
> only
This is very good news indeed! I've been watching this mailing list for
awhile to see if anyone could crack the code. That being said, I'm
trying to get this information disbursed to the developers of the open
source software PocketSense. They basically created a Python script that
generates OFX
Wow! That's dedication!
I have to admit, the same thing happened with my Credit Union (Patelco)
and I didn't have the dedication to do what you did!
Kudos to you. It's really maddening, like you say, that apparently the
only clients that our banks think have the right to download their data
Am 29.01.21 um 05:23 schrieb John Ralls:
[...]
> I've been using QWIN 2300, header version 102 for some time with no problem
> until you mentioned it today. Changing to 103 and adding a Client UID one at
> a time didn't help.
[...]
AFAIK only versions of Quicken not older than 2 years are
Am 30.01.21 um 18:29 schrieb Bob White:
> I can confirm the redirect to USAA for creds is a one-time issue.
>
> You also need a CUSTOMUID. I haven’t deciphered if it is generated sever or
> client side.
>
> I am away from my Mac at the moment but can upload the OFX log when I get
> back to
I can confirm the redirect to USAA for creds is a one-time issue.
You also need a CUSTOMUID. I haven’t deciphered if it is generated sever or
client side.
I am away from my Mac at the moment but can upload the OFX log when I get back
to it. Is there someplace to upload to or would attachment
> On Jan 30, 2021, at 6:50 AM, Bob White wrote:
>
>>
>>>
>>> The Quicken web interface is I think different from OFX Direct Connect. If
>>> it's OFX Web Connect then it handles authentication differently and that's
>>> probably at least part of the problem.
>>>
>>> I found a quicken
Am 30.01.21 um 18:06 schrieb John Ralls:
>
>
>> On Jan 30, 2021, at 6:50 AM, Bob White wrote:
[...]
> "The credentials that Quicken prompts you for will vary based on your
> software version and the type of account you want to download. With the
> recommended Direct Connect method in Quicken
The Quicken web interface is I think different from OFX Direct Connect. If it's
OFX Web Connect then it handles authentication differently and that's probably
at least part of the problem.
I found a quicken community discussion that suggests that Quicken for Windows
used IE to connect, so
On Samstag, 30. Januar 2021 05:11:44 CET John Ralls wrote:
> > On Jan 29, 2021, at 4:11 PM, Bob White wrote:
> >
> > Thanks, John,
> >
> >>
> >> Not mentioned in your emails is the response from USAA: A webpage
> >> reporting a server error instead of the usual 50x HTTP response code.
> >
>
> On Jan 29, 2021, at 4:11 PM, Bob White wrote:
>
> Thanks, John,
>
>>
>> Not mentioned in your emails is the response from USAA: A webpage reporting
>> a server error instead of the usual 50x HTTP response code.
>
> I do see a 400 in the Online Banking Transaction Window when attempting
Thanks, John,
Not mentioned in your emails is the response from USAA: A webpage reporting a
server error instead of the usual 50x HTTP response code.
I do see a 400 in the Online Banking Transaction Window when attempting to
download transactions in GNC:
AqBanking v6.2.5.0stable
Sending
> On Jan 28, 2021, at 5:01 PM, Bob White via gnucash-devel
> wrote:
>
> Not sure if this is the proper channel, but USAA Federal Savings Bank has
> deprecated older QWIN OFX support.
>
> I have confirmed with the bank this occurred on 27 Jan 2021.
>
> Using a trial subscription for Quicken
41 matches
Mail list logo
