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
Looks like the server is down. ns1.linas.org responds to pings, ns1.gnucash.org
and www.gnucash.org don't.
Regards,
John Ralls
> On Feb 7, 2021, at 7:49 AM, Frank H. Ellenberger
> wrote:
>
> Hi Linas,
>
> the webserver is unreachable. Forwarded is the first alarm, which I got.
>
> Regards
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
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
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
Hi Linas,
the webserver is unreachable. Forwarded is the first alarm, which I got.
Regards
Frank
Weitergeleitete Nachricht
Betreff: [Hosted Weblate] Neuer Alarm in GnuCash/Glossary
Datum: Sun, 07 Feb 2021 11:49:19 -
Von: nore...@weblate.org
An:
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
>>* 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
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
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
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.
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
Hi,
Am 08.02.21 um 00:22 schrieb Linas Vepstas:
> It should now be working.
confirmed!
> Stabbed in the back again, by some combination of kernel "consistent
> network interface names", udev persistent-network config files, and
> systemd, which magically decided to rename some my network
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
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,
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
It should now be working.
Stabbed in the back again, by some combination of kernel "consistent
network interface names", udev persistent-network config files, and
systemd, which magically decided to rename some my network interfaces in
yet another way, different than ever before.
Given that the
Lost electric power yesterday, for 6 hours. When it came back up, I forgot
to check everything. Apache is running, but somehow nothing is connecting.
So I guess networking is borken? Debugging now.
--linas
On Sun, Feb 7, 2021 at 10:57 AM John Ralls wrote:
> Looks like the server is down.
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 got this working in my software with some help for the info on this list.
Here is a write-up:
USAA's changes to their OFX interface
-
On 2020-01-26, USAA's previous OFX interface (
https://service2.usaa.com/ofx/OFXServlet) stopped working. It seems like
they
21 matches
Mail list logo
