1
0
mirror of https://github.com/aclindsa/ofxgo.git synced 2024-10-31 22:00:06 -04:00
Commit Graph

5 Commits

Author SHA1 Message Date
David Alpert
01b26887af GH-39 relax ofx response parsing to support TYPE1 responses
Section 4.2.2.2 Type 1 Protocol Overview in the
[Open Financial Exchange Specification 2.2, Nov 26, 2017](https://www.ofx.net/downloads/OFX%202.2.pdf)
states that:

    Type 1 applies only to the request part of a message; the server response is unaffected.

Thus it appears that we can safely parse SECURITY:TYPE1
using the same logic that we parse SECURITY:NONE

As I understand it, Security:TYPE1 indicates that the
financial institution uses SSL enryption to protect
customer credentials in transit.  This applies
explicitly to the incoming requests which may
contain authentication as part of the request
but does not appear to cause any material changes
to the response format.

As a result it appears that we can safely parse
SECURITY:TYPE1 responess in the same way that
we parse SECURITY:NONE responsese.
2021-03-12 10:46:24 -05:00
Aaron Ross
2b8a79e4b7 review changes 2021-01-04 07:24:40 -05:00
Aaron Ross
0d93a42626 support SGML OFX responses with no line breaks
Some financial institutions (*cough* Wells Fargo *cough*) export OFX files as a single line, which is technically valid according to the v1 spec. In order to parse them correctly, `readSGMLHeaders` now uses a regular expression that allows for all whitespace/line breaks to be optionally excluded.

A new sample response (wellsfargo.qfx) has been added to document this behaviour.
2021-01-04 07:24:40 -05:00
Martin Kobetic
0f6ceccd86 Work around missing blank line after last header
Detect when a newline doesn't follow the last header when parsing SGML and break out of the header-parsing loop early. Add an example .qfx file demonstrating the broken behavior we're working around and a test.
2019-01-04 11:18:55 -05:00
ff18c86aea Test parsing of some sample responses 2017-04-10 20:01:01 -04:00