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: t...@net-bembel.de; kmymoney-devel@kde.org
From: wolfe...@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

        wolfe...@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@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel

      
      

    
    

  


_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel                            
          
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel

Reply via email to