Bug 377368 - KMyMoney 4.8 failed to import discover card ofx
Summary: KMyMoney 4.8 failed to import discover card ofx
Status: RESOLVED INTENTIONAL
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.8.0
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-08 08:38 UTC by wuzhuoqing
Modified: 2017-08-08 19:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
attachment-27869-0.html (1.83 KB, text/html)
2017-08-08 01:06 UTC, george
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wuzhuoqing 2017-03-08 08:38:19 UTC
This is not a bug, due to discover site change we cannot import from discover card since late Feb.

According to http://www.ofxhome.com/ofxforum/viewtopic.php?id=47793, Discover now require http header to be in exact order, and it is unlikely for Discover to change that.

[code]
POST https://ofx.discovercard.com/ HTTP/1.1
Content-type: application/x-ofx
Host: ofx.discovercard.com
Content-Length: 498(or actual length)
Connection: Keep-Alive
[/code]

I checked https://github.com/KDE/kmymoney/blob/4.8/kmymoney/plugins/ofximport/ofxpartner.cpp but being unfamiliar to code case I don't know how should the code be changed to workaround the issue. Any suggestions?
Comment 1 Thomas Baumgart 2017-03-08 11:53:39 UTC
The actual request is created in "bool KOfxDirectConnectDlg::init()" which can be found in https://github.com/KDE/kmymoney/blob/4.8/kmymoney/plugins/ofximport/dialogs/kofxdirectconnectdlg.cpp . The problem is that the metadata handling is completely handled within KIO::TransferJob which we simply utilize. The metadata is transported using a QMap<QString key, QString value> container, so changing/controlling the order of the entries is not that easy.

It looks like the order of HTTP Headers doesn't matter for headers with different names. If there are multiple headers with the same name, however, the order is important. More details can be found in the respective RFC at http://tools.ietf.org/html/rfc2616#section-4.2. 

If the bank's server still requires a certain order it is simply not compliant with the RFC and thus broken (just like so many other bank systems).
Comment 2 wuzhuoqing 2017-03-08 22:17:54 UTC
Thanks. Indeed, seems there is no easy way to work around this unless change the kio http slave code https://cgit.kde.org/kio.git/tree/src/ioslaves/http/http.cpp

I think I will just live with it.
Comment 3 wuzhuoqing 2017-03-11 07:14:07 UTC
Ok, tried a few things and finally settled with one dirty workaround for myself. Basically changed the code to call a custom python 2 script (which use httplib to fine control the header order) to send the ofx request first, and if not succeeded (script return non 0 code) then fallback to original code path.

Obvious this is not good for PR. Just in case anyone is interested https://github.com/Zhuoqing/kmymoney_discover_workaround/commit/3f7acce5fcc51cea1e9bac11e3edae8a4d8231d9
Comment 4 george 2017-08-07 19:22:45 UTC
I too have this problem. 
The comments above seem to indicate that it is, in fact, a problem (even if it is not a bug as suggested above).

What does it take to get some action here?
Comment 5 Jack 2017-08-07 20:51:40 UTC
George - do you have a suggestion as to who needs to act?  The comments above indicate there is absolutely nothing within the KMyMoney code which can help.

Thomas - is there any point in trying to bring in the KIO developers, at least to ask if there is anything they can do?
Comment 6 george 2017-08-08 01:06:18 UTC
Created attachment 107135 [details]
attachment-27869-0.html

Looks like two choices to me:

1) Get the folks who's code your using to give you a fix, possibly an 
addition option to order the header, or

2) Grab/purloin/etc. said code, fix the issue and make that part of 
Kmymoney.

To me, the problem is the solution is dead in the water, and, for me, 
has caused me to stop using the card.
Comment 7 Thomas Baumgart 2017-08-08 06:24:35 UTC
George, you forgot

3) get the developers for the bank's backend system to read and understand the RFC and fix the problem (hey, after all they introduced it)

though your solution to 'stop using the card' on a wide scale may have some impact  (I have dreaming mode on while I write this) and would be my choice as well.

As to 1) why should there be an option to control the order if that is not required by the standard and 2) only if said bank pays me so that I can retire immediately and take care of KMyMoney fulltime.
Comment 8 george 2017-08-08 19:21:42 UTC
On 08/08/17 00:24, Thomas Baumgart wrote:
> George, you forgot
>
> 3) get the developers for the bank's backend system to read and understand the
> RFC and fix the problem (hey, after all they introduced it)
Yeah, well I long ago realized that my tail was NOT going to wag the 
dog. So the only chance at resolution was to grab the bull by the horn, 
so to speak.
>
> though your solution to 'stop using the card' on a wide scale may have some
> impact  (I have dreaming mode on while I write this) and would be my choice as
> well.
>
> As to 1) why should there be an option to control the order if that is not
> required by the standard and 2) only if said bank pays me so that I can retire
> immediately and take care of KMyMoney fulltime.
Sorry, Quicken already paid THEM.