[Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads)
Jack
ostroffjh at users.sourceforge.net
Thu Dec 10 19:33:01 UTC 2015
Jeff,
My first suggestion is that any patches for libOFX go to that mailing
list, although there is an overlap in the developers here and there, so
someone else might suggest how they would like to receive them.
Patches for KMM can be sent to this list, or I believe the developers
would prefer them posted on ReviewBoard (http://reviewboard.kde.org).
I assume your patches to KMM depend on those to libOFX, so the order of
inclusion would matter. My preference (although I am not a developer)
would be to separate the ofx patches for daylight savings, CLIENTUID,
and other, since they could be reviewed and applied independently.
Based on my reading, the client (KKM) is supposed to generate the
<CLIENTUID>, but as you imply, if another software has already
generated on, it is best to be able to use that, so you don't run out
of connections. It seems that the server uses this to limit the number
of clients (different computers and/or different software packages)
which can connect to one account. I don't think there is anything
special or magic about creating it - it really seems to be essentially
a random number that should be universally unique. There are several
libraries that can produce one, but I don't see any problem using the
one Quicken created or hashing other values to create one. I'm not
sure if it's best to have one per KMM instance, or per account, or
perhaps the first allowing to override per account if necessary.
I actually got a voice mail from somone at Chase today - his message
said he would be glad to assist me, but he will be out of the office
until 12/14. If he's already out of the office today - that's some
great support.
Thanks for the work on this.
Jack
On 2015.12.10 11:28, jeffjl.kde at outlook.com wrote:
> I have a fix for this that I've been using for my Chase bank accounts
> since shortly after they made their change (but I do not have a
> credit card account at Chase). It's a pretty simple change to libofx
> to support <CLIENTUID>, and I added an edit box on the "OFX Details"
> tab of the "Online Settings" tab of the "Edit Account" dialog so KMM
> could support it - I made a new account ".value()" for it. (Aqbanking
> also provides an edit box for this purpose.)
>
> The <CLIENTUID> itself is still a bit of a mystery to me. For my
> Chase accounts, I used the 32 character hex string that Quicken uses,
> so KMM and Quicken are using the same string. That seems to work. I
> think if you don't "know" what to use for <CLIENTUID>, you can just
> come up with a random string of up to 36 characters. But I'm not 100%
> sure whether the client (KMM) or the bank (Chase) comes up with the
> string. I thought about adding a button to KMM to generate a hash of
> the file name and account name, which is, I think, what Quicken does.
> But from what I've read, your bank / broker probably limits the
> number of different <CLIENTUID> you can have, so you don't want to be
> changing it a lot. Though I've read that people can call the bank and
> ask for more and / or reset the "counter", if you can manage to talk
> to the knowledgeable person at the bank.
>
> The Chase change came up while I was making a bunch of other changes
> to libofx to support options (puts & calls), cash balance in
> investment accounts, and investment positions (how many shares your
> broker thinks you have) (for which I made a new callback from
> libofx). So this simple fix is buried in a larger change. I'm fairly
> comfortable that those changes are working, but I'd still consider
> them a work-in-progress.
>
> Oh, and I changed the daylight saving flag in libofx. It stopped
> working when my area went off DST (my credit card statement stared
> looking like it was for the previous day). My change now makes it
> work while we are off DST, but it is untested for when we go back on
> DST. The change lets mktime() determine whether DST is in effect.
>
> I could post the whole libofx change if people are interested. Or I
> could work on splitting out just the <CLIENTUID> change. I don't
> think the larger change would break anything in KMM, but I haven't
> tested that either. And I have not worked on the "ofc" parser, I've
> only been changing the "ofx" parser, since that's the one I use and
> can test.
>
> To: thb at net-bembel.de; kmymoney-devel at kde.org
> From: wolfemi1 at gmail.com
> Date: Thu, 10 Dec 2015 08:43:26 -0600
> Subject: Re: [Kmymoney-devel] libOFX question (relates to recent OFX
> failures with Chase credit card downloads)
>
>
>
>
>
>
> I just saw a request for the OFX data
> that Chase sends; here is a copy of the response I got from
> Chase
> after trying (and failing) to download OFX data:
>
>
>
> response:
>
> OFXHEADER:100
>
> DATA:OFXSGML
>
> VERSION:102
>
> SECURITY:NONE
>
> ENCODING:USASCII
>
> CHARSET:1252
>
> COMPRESSION:NONE
>
> OLDFILEUID:NONE
>
> NEWFILEUID:20151210083844.000
>
>
>
>
> <OFX><SIGNONMSGSRSV1><SONRS><STATUS><CODE>15510<SEVERITY>ERROR<MESSAGE>Please
> verify your identity within the next 7 days. Using your desktop
> computer, go to your bankӳ website and visit the Secure Message
> Center for
> instructions.</STATUS><DTSERVER>20151210093848.702[-5:EST]<LANGUAGE>ENG<FI><ORG>B1<FID>10898</FI></SONRS></SIGNONMSGSRSV1><CREDITCARDMSGSRSV1><CCSTMTTRNRS><TRNUID>20151210083844.000<STATUS><CODE>15500<SEVERITY>ERROR</STATUS><CLTCOOKIE>1</CCSTMTTRNRS></CREDITCARDMSGSRSV1></OFX>
>
> Completed
>
>
>
> Grabbed from the 'ofxlog.txt' file.
>
>
>
> -Mike
>
>
>
>
>
> On 12/10/2015 8:20 AM, Michael Wolfe wrote:
>
>
>
>
> As a side note, I am also having this
> problem; I wasn't aware that there was something Chase was
> expecting KMyMoney to send back.
>
>
>
> If anyone needs testing for a fix with Chase Bank, I'm
> available
> to do so if there's a testing version available for Windows
> (or
> alternatively some handholding with a code patch so I can
> build
> it myself!).
>
>
>
> -Mike Wolfe
>
> wolfemi1 at gmail.com
>
>
>
> On 12/10/2015 4:53 AM, Thomas Baumgart wrote:
>
>
>
> Hi,
>
> On Wednesday 09 December 2015 19:38:08 Jack wrote:
>
>
>
> Some of you may have seen some other posts I've made about
> this, but I
> think I've tracked down the problem.
>
>
> Thanks for the information. That helped a lot to identify
> what's going on.
>
>
>
> Background: last month Chase credit cards made a "security
> enhancement"
> change that has made all OFX downloads since 11/17 fail. The error
> message says to got to the Chase secure message center for info on how
> to verify your identity, but no such message ever appears. The
> section
> at
> http://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect_in_GnuCash_2#Chase_
> .22username_or_password_are_incorrect.22 indicates the need for using
> a UID
> (user id) within the OFX request. It looks like they associate that
> user
> UID with the account, probably to limit access. However, the first
> time
> they see a UID on an OFX request, they should generate a PIN and send
> it to
> your account at their Secure Message Center. You then use that PIN on
> another page the message links to. I suppose since KMM isn't sending
> the
> UID, they don't generate that message.
>
> So - I don't see any place in KMM for a user UID. In fact, looking
> into the libOFX source, I see the UUID type defined, but no element
> defined as that type which looks like a user id. Can someone confirm
> this is correct, and if so, does this need to be brought up on the
> libOFX list before there is anything that KMM can do? (Other forum
> messages I've seen seem to indicate that aqbanking can handle this, so
> I'll see if I can get this set up, but I hate to spin my wheels if
> someone can provide a more definitive answer.
>
>
> I took a look into the OFX spec (version 2.1.1) and found
> chapter 2.5.1.1.1
> "Client Unique ID <CLIENTUID>". In short, this is a uid generated by
> the
> client (KMyMoney). Here's the paragraph of the spec (© 2006 Intuit
> Inc.,
> Microsoft Corp., CheckFree Corp. All rights reserved):
>
> ---8<---
> OFX servers can require OFX clients to include a client ID in each
> signon
> request. This client ID should be unique to the installation of the
> client
> software, but the method that the ID is generated is left up to the
> client.
> The server can specify that this field is required using the
> <CLIENTUIDREQ>
> tag in the applicable <SIGNONINFO> section of the profile. Servers
> should
> expect that users may connect via OFX from multiple locations and may
> need to
> associate more than one <CLIENTUID> value with their <USERID>.
> ---8<---
>
> Would be interesting, if you see the CLIENTUIDREQ in the SIGNONINFO
> message of
> the server. One can (at least could) enable logging for OFX traffic
> in some
> way. Don't know, if that is still available. Will have to check.
>
>
>
>
>
>
>
>
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney-devel
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney-devel
------quoted attachment------
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney-devel
>
More information about the KMyMoney-devel
mailing list