@coderoftime/fints 0.1.0 → 0.3.0

package/CHANGELOG.md

@@ -1,3 +1,519 @@
+## 0.3.0
+
+An app may notice these changes: arguments and options of another type than declared, such as a number as `bankCode`
+or a `state` that is no string, and a user ID or customer ID of more than 30 characters fail with a `TypeError` before
+the bank is contacted; the client reads its options once; `close` waits up to five seconds for the request on its way,
+so the call it ends fails with `FinTsStateError` where the answer comes in time; a TAN goes out as the user typed it;
+`console.log` shows the models of the package only by what identifies no person, account or TAN, and `toString` of
+`FinTsFeedback` and `BankMessage` leaves out the bank's texts; `feedback` and `source` of an error are getters; and more
+malformed bank data fail with `FinTsProtocolError`. Where these notes compare with the Dart package, they mean its
+source after its release 0.2.0, unless they name 0.2.0, which differs in more ways: it keeps no refused login in the
+saved state.
+
+### Breaking
+
+- `getTransactions` rejects a `format` other than `'auto'`, `'mt940'` and `'camt'` with a `TypeError`, before it waits
+  for other calls or contacts the bank: one such as `'CAMT'` asked for MT940, and `null` meant `'auto'`, as `undefined`
+  still does.
+- `getBalance` and `getTransactions` reject anything but an `Account`, such as one written to JSON and read back, with a
+  `TypeError` before they wait for other calls or contact the bank. They logged in, fetched the SEPA account list, and
+  then failed with an unrelated `TypeError`.
+- `selectTanMethod` rejects a TAN method or medium that is no string, and a missing method, with a `TypeError` before it
+  ends the dialog. A number as the method was saved and then dropped at the next login, which asked `tanMethodSelector`
+  instead; a medium of another type went out as its text or as a data element group, which the bank refused as a login;
+  and a state saved in between could not be restored.
+- `FinTs3Client` throws a `TypeError` for options of another type, before contacting the bank: a missing `tanCallback`
+  or one that is no function, another callback that is neither a function nor `undefined` or `null`, a `state` that is
+  neither a string nor `undefined` or `null`, such as the parsed JSON a store hands back, and a `transport` without the
+  functions `post` and `close`. A callback that was no function failed the call after its messages had gone out,
+  `tanCallback` at the first TAN challenge after the PIN-signed login; a `state` that was no string was ignored; and a
+  transport without `close` made `close` reject.
+- The client reads its options once, when it is built, as the Dart package does: assigning another `tanCallback`,
+  selector, `onBankMessage` or `onWarning` to the options object afterwards no longer changes what the client calls.
+- `Account`, `Amount` and `FinTsConfig` throw a `TypeError` ('Invalid argument (<name>): …', without the value) for an
+  argument of another type than declared, as the Dart package's types refuse it: such as a number as `bankCode`,
+  `accountNumber`, `iban`, `currency` or `customerId`, a missing `bankCode`, a string as `minorUnits`, `scale` or
+  `typeCode`, anything but an array of strings as `allowedTransactions`, anything but a boolean as `allowInsecureUrl`,
+  and anything but an `AccountDataStatus` as `dataStatus`. `Amount.parseDecimal` does for a `value` or `currency` that
+  is no string. Such an account passed the constructor, threw in `toString`, and failed `getBalance` and
+  `getTransactions` only after the login, or matched none of the bank's accounts, so that the query failed with
+  `FinTsUnsupportedError` or went out without the bank's IBAN and BIC. A `dataStatus` written to JSON and read back
+  failed with an unrelated `TypeError` ('object is not iterable'), and a string counted as an empty status. An amount
+  kept a number as its currency, and a string as `minorUnits` threw a `RangeError` that showed it as a valid value.
+- `FinTsConfig` throws a `TypeError` for a `userId` or `customerId` longer than 30 characters, the length FinTS 3.0
+  gives them (Formals, data type `id`). The bank refused such a login with a syntax error, which the client counted as
+  a refused login, so it sent the PIN no more.
+- A `FinTsConfig` is frozen once its constructor has checked it: assigning to a field throws a `TypeError` in
+  strict-mode code and does nothing otherwise, and a subclass cannot add fields.
+- As in the Dart package, `Mt940.parse` and `Mt940.parseTransactions` throw a `TypeError` for a `status` other than
+  `'booked'` and `'pending'`, `null` included, which meant `'booked'`, and for a `currency` that is no string;
+  `Camt.parse` and `Camt.parseTransactions` for a status other than these, `undefined` and `null`. Such a status became
+  the transactions' `status`, and such a currency that of their amounts. `SepaPurpose.parseParts` throws a `TypeError`
+  for a string, whose characters it took for parts, and for parts that are no strings.
+- camt documents are read as XML 1.0 has them, failing `getTransactions` with `FinTsProtocolError` and `Camt.parse` with
+  `FormatError` for a name that is no XML name, such as `<1x>`, an end tag with another namespace prefix than its start
+  tag, a second XML declaration or one inside or after the root element, a processing instruction without a target, and
+  an attribute stated twice.
+- camt: a `Dt` that holds a date and time is read like a `DtTm`. One whose time the client cannot read, such as
+  `2024-03-15T25:00:00` or `2024-03-15T10:00`, fails `getTransactions` with `FinTsProtocolError` and `Camt.parse` with
+  `FormatError` instead of counting on the date written. So do a UTC offset beyond ±14:00, such as `+15:00`, which XML
+  Schema does not allow and which the client used to read as an offset, and `24:00:00` with a fraction of a second other
+  than zero.
+- `BankInfo.maxMessageSize`, `minTimeout` and `maxTimeout` are `undefined` for a value above 9999, the four digits HIBPA
+  allows, as in the Dart package. The client then sends messages of any size and starts a new dialog after 5 idle
+  minutes. `TanChallenge.plainMessage` leaves a structured challenge of more than 65,536 characters as the bank sent it,
+  as the Dart package does.
+- `close` no longer aborts a request on its way at once: it waits up to five seconds for the answer and only then aborts
+  it, and the dialog ends then have five seconds once that request is over, so `close` may take about ten seconds where
+  the bank has stopped answering. Where the answer comes in time, the running call fails with `FinTsStateError` instead
+  of `FinTsTransportError`, also where that answer completes it, unless the answer brings an error of its own, such as a
+  rejected PIN, which it fails with instead; a request aborted after the five seconds still fails it with
+  `FinTsTransportError`. A call whose last answer arrives after `close`, within those five seconds, fails with
+  `FinTsStateError` instead of returning its result.
+- A TAN goes out as the user typed it, except for full-width characters, which count as their ASCII counterparts, and
+  the ideographic space U+3000, which counts as a blank, as in the Dart package. Unicode NFKC changed it before:
+  superscript, circled and mathematical digits counted as digits, and characters that ISO 8859-1 holds went out altered,
+  such as `²` as `2` or a no-break space inside the TAN as a space, which the bank counts as a failed attempt; `µ`, `½`
+  and the like failed with a `TypeError` as not sendable. Other characters outside ISO 8859-1, and digits other than 0
+  to 9 for a `numericTan` method, fail the call with a `TypeError` before it is sent.
+- `FinTsFeedback.toString` gives the code only, such as `FinTsFeedback(3072)`, and `BankMessage.toString` gives
+  `BankMessage(…)`, as `console.log` showed them already. So `String(f)`, template strings and loggers that call
+  `toString` no longer collect the bank's texts and parameters, which with return code 3072 hold the new login data, or
+  a message that may address the user by name. To show them to the user, use `code`, `text` and `parameters`, or
+  `subject` and `text`. The message of a `FinTsBankError` stays as it was, with the code, text and parameters of each
+  error, such as `9010: Konto gesperrt [DE89370400440532013000]`.
+- `FinTsBankError.feedback` and `FormatError.source` are getters instead of own properties of the error, so
+  `Object.keys`, object spread and `JSON.stringify` of the error leave them out.
+
+### Security
+
+- Plain JavaScript can no longer change a `FinTsConfig` once checked, which could send the PIN to an http URL, or login
+  data the constructor had not checked, to the bank.
+- `FinTsConfig` refuses an `allowInsecureUrl` that is no boolean, such as the string `'false'` read from an environment
+  variable, with a `TypeError`: it allowed plain http to a loopback host, where the PIN passes any proxy the runtime's
+  `fetch` takes from the environment.
+- `console.log` and `util.inspect` on Node.js, Deno and Bun show the objects of this package only by what identifies no
+  person, account or TAN. An `Account`, `Balance`, `Transaction`, `TanMethod` or `TanMedium` shows as its `toString`, a
+  `TanChallenge` by its method, kind and attempt, a `FinTsFeedback` by its code and a `TanAnswer` by its kind.
+  `AccountDataStatus`, `BankInfo`, `FinTsConfig`, `FlickerCode` and `TanImage` show codes, versions and sizes only, the
+  statements of `Mt940.parse` and `Camt.parse` the last digits of the account and the number of transactions, and a
+  `BankMessage` shows as `BankMessage(…)`. Until now they showed every field: the bank's texts, references and
+  parameters (with return code 3072 the new login data), TAN media names, the TAN, the challenge data and image, the
+  login name and product ID, and a statement's full account. An error shows its message and stack, and a
+  `FinTsTransportError` its `statusCode`; the message of a `FinTsBankError` holds the texts and parameters of its
+  errors, as before. `JSON.stringify` and the browser console still show every field.
+- Node.js's report of an uncaught error ignores what `console.log` shows of an object. It printed the whole `feedback`
+  of a `FinTsBankError`, including the texts, references and parameters of its successes and warnings and, with return
+  code 3072, the new login data, as well as the `source` of a `FormatError`. `JSON.stringify` of such an error, and
+  loggers that copy an error's fields, got them too. Both are getters now, so an uncaught `FinTsBankError` or
+  `FormatError` prints its message and stack only, as in the Dart package, and `JSON.stringify` leaves them out.
+- `TanMedium.toString` leaves out the medium's name, which the user may have chosen after themselves, such as
+  `Max’s iPhone`: it gives `TanMedium(M, active)`, or, for a card, the last digits of its number,
+  `TanMedium(…2014, active)`, as before for a card without a name.
+- A PIN that begins or ends with U+0085 (NEL) fails with a `TypeError` before it is sent, like one with other blanks at
+  either end. It went out with the byte 0x85, which the bank could count as a failed attempt.
+- New login data (3072) next to an error in the answer to the login's TAN or app approval, such as 9941 for a wrong TAN,
+  an aborted dialog (9800) or any other error but a rejected PIN, end the old ones as well, as in the Dart package: the
+  call fails with `FinTsLoginDataChangedError`, the client ends the dialog where the bank keeps it open, and no later
+  call logs in with the old data. Until now the call failed with `FinTsTanError`, `FinTsDialogAbortedError` or
+  `FinTsBankError`, and the next call logged in again with the old login data and the PIN, which the bank may count as a
+  failed attempt, and asked for another TAN.
+- A refused login, and the count of logins whose answer was lost, are restored from a saved state whose owner names the
+  server by something other than a string, such as a number or `null`, as in the Dart package; the rest of such a state
+  is dropped, as for another server. Until now the whole state was dropped, and the next call sent the PIN the bank had
+  refused.
+- A `state` that is no string, such as the parsed JSON a json column returns, fails the `FinTs3Client` constructor with
+  a `TypeError`: the client ignored it, and with it a refused login it held, and sent the PIN again.
+- A refused login stays refused where the `loginGuard` section of a saved state for the same user is damaged, such as a
+  return code without its code or `unreadLogins` that is no integer: the client restores a `FinTsLoginRefusedError`
+  without return codes and sends the PIN no more until `clearLoginRefusal`. Such damage dropped the refusal, and the
+  next call sent the refused PIN again. A state without the section, as fints-ts 0.1 and the Dart package 0.2.0 save
+  it, restores as before.
+- `HttpTransport` copies each part of an answer as it arrives, as the Dart package does. An answer within
+  `maxResponseBytes` that a server sent in one-byte parts took gigabytes of memory and could end a Node.js process with
+  an out-of-memory error, which the app cannot catch. A `fetch` that refills the part it handed out corrupted the
+  answer.
+- The documentation of `HttpTransport` and `allowInsecureUrl` warns that plain http to a local server goes wherever the
+  global `fetch` sends it, as https does. Whatever replaces `globalThis.fetch`, such as a test's stub, and on Node.js a
+  global dispatcher get every message with the PIN. A proxy that the runtime's `fetch` takes from the environment, as
+  Node.js does with `NODE_USE_ENV_PROXY=1`, and Deno and Bun do from `HTTP_PROXY`, sees the PIN unencrypted: exempt the
+  host with `NO_PROXY` or pass a `fetch` that connects directly. The Dart package connects to the loopback host
+  directly, also bypassing a client set with `runWithClient`.
+- The limits on bank data are those of the Dart package. The following fail the call with `FinTsProtocolError`, and
+  `Mt940.parse`, `Camt.parse` and `Amount.parseDecimal` with `FormatError`: an answer with more than 1,000,000 data
+  elements and segments in its plain or in its encrypted part, or with more than one encrypted part (HNVSD); XML nested
+  more than 100 levels deep, an empty element such as `<a/>` included, or with more than 500,000 nodes besides text or
+  one per 16 characters, whichever is more; an MT940 field of more than 65,536 characters; and an amount written with
+  more than 64 characters. The limits were 200,000 data elements per answer, the encrypted part included, and XML of 256
+  levels or 1,000,000 elements and attributes; fields and amounts had none. A hostile answer can now take up to about
+  210 MB of memory while it is read, instead of about 25 MB. The 128 MiB a query may hold count each data element its
+  pages keep as 512 bytes instead of 256, and no longer count the elements of the encrypted part's envelope, so a query
+  of many short elements stops after half as many. The 200,000 statements and transactions per query stay.
+- XML text or an attribute value of megabytes of `&`, or of unknown entities such as `&a;`, fails at its first bad
+  reference. The parser first found every reference, which took more than a second and about a gigabyte of memory for
+  12 MB, beyond the 210 MB the limits allow.
+- camt: remittance information (`Ustrd`) of more than 65,536 characters, as for an MT940 field, fails
+  `getTransactions` with `FinTsProtocolError` and `Camt.parse` with `FormatError`. Megabytes of SEPA keywords took
+  about 40 times their size in memory.
+- camt: blanks alone between elements, such as the line breaks of an indented document, are no longer kept as text,
+  which halves the memory such a document takes while it is read.
+- MT940: the counterparty's IBAN and BIC come from the subfields `?31` and `?30` only, where the bank states them. A
+  payer could write `IBAN+…` and `BIC+…` into the end-to-end reference, and these filled `counterpartyIban` and
+  `counterpartyBic` where the subfields stated none. Both values stay readable in `purposeCodes`.
+- In a browser, `HttpTransport` sends no cookies and no referrer with a message, and the browser's cache keeps no copy
+  of the exchange (`credentials: 'omit'`, `referrerPolicy: 'no-referrer'`, `cache: 'no-store'`). With the defaults,
+  cookies of the page and its URL as referrer went along to a server on the page's own origin.
+- The relay server of the README refuses a body without `Content-Length` or of more than 1 MiB before reading it:
+  update relays built from it. The documentation of `FinTsTransport.post` says that the client bounds neither the time
+  of the exchange nor the size of the answer, so a transport of the app's own has to, as `HttpTransport` does.
+
+### Fixed
+
+- `close` ends the dialog of a request it aborts after five seconds, unless that request opened the dialog, whose ID
+  only the answer tells: the end goes out after the abort, under the next message number, since the bank may have
+  received the aborted message. Until now the abort dropped the dialog without an end, and the bank kept it open until
+  its timeout. The answer to that end refuses the login only for a rejected PIN, as at any dialog end, not for an error
+  such as a message number the bank did not expect because the aborted message never reached it.
+- `close` gives the dialog ends five seconds once the request on its way, if any, is over: then the client stops
+  waiting for them, a transport that takes the abort, as `HttpTransport` does, stops them, and none goes out later. A
+  bank that has stopped answering held up `close` for the end of an open dialog until the transport's timeout, 90
+  seconds by default.
+- The answer to a request on its way when `close` is called counts as any other, as in the Dart package: the logger gets
+  it, and the saved state keeps the bank and user parameter data, the customer system ID, the TAN medium and the SEPA
+  account list it brings. `close` aborted it at once, so a client restored from the state repeated the anonymous dialog,
+  the synchronization, which has the bank register another customer system ID, the lookup of the TAN media or the SEPA
+  account list, and its next login reported user parameter data version 0. The dialog of that request is ended as well,
+  also where the request opened it, whose ID only the answer tells, and a login answered so no longer counts as one
+  whose answer was lost.
+- A dialog end that `close` keeps from going out, once the time after the request on its way is up, no longer reaches
+  the logger as an outgoing message, as in the Dart package: the logger showed a dialog end the bank never received.
+- A TAN medium name the app passes to `selectTanMethod`, also from the saved state, goes out without blanks at either
+  end (Formals B.4.1), and one of blanks only as no name, as in the Dart package: a bank that knows the medium without
+  them refused the login, and the state kept the refusal. `selectedTanMedium` and the state keep the name as the app
+  passed it. A name the bank issued still goes back as the bank sent it, blanks at either end included, and the medium
+  in use of a state saved by 0.2.0, which does not tell the two apart, as 0.2.0 sent it.
+- `selectTanMethod(method, null)` leaves the TAN medium to the next login, which looks the media up where the method
+  needs one, as without a medium and as in the Dart package. The login went out without a medium, which the bank
+  refused, and the client kept the refusal until `clearLoginRefusal`.
+- A `tanMethodSelector` or `tanMediumSelector` that returns `null` picks the first method or medium, as for `undefined`,
+  instead of failing the call with a `TypeError`; the selector types allow `null`.
+- `null` for `logger`, `onBankMessage`, `onWarning`, `tanMethodSelector`, `tanMediumSelector` or `state` means none, as
+  in the Dart package. `logger: null` failed every call that exchanged messages, and `close`, after their traffic;
+  `onBankMessage: null` and `onWarning: null` failed a call whose answer carried a bank message or a warning; and a
+  `null` selector failed the call after the PIN-signed synchronization or the lookup of the TAN media.
+- `null` counts as not given for the details of an `Account`, whose `toString` threw for an `accountNumber` of `null`,
+  for the `customerId` of `FinTsConfig`, which is then the user ID, where a `TypeError` without the package's message
+  was thrown, and for the `currency` of `Mt940.parse`, which gave amounts in the currency `null` instead of the
+  `FormatError` 'MT940 statement without currency', as in the Dart package.
+- Where the bank parameter data rule out a login, by the PIN's length or the message's size, the client fetches them
+  anew in an anonymous dialog, which carries no PIN, and tries the login once more, which goes out only if the new
+  limits allow it; where they rule it out as well, the call fails with the error that names the new limits, as in the
+  Dart package. Until now outdated parameter data, as saved ones may be, failed every call that logs in with a
+  `TypeError` (`FinTsProtocolError` for the size) until the app dropped `client.state`. It takes only the limits from
+  the anonymous answer, and only from parameter data of another version than those kept, the PIN's length only where
+  they state it. Those limits serve until the login brings the user's parameter data, which the login asks for by
+  reporting version 0, so the login the new limits judge may be up to two bytes shorter than the one the old ones
+  stopped. The anonymous parameter data never replace the user's. A bank that does not answer anonymously cannot refresh
+  them; the call then fails as before, without sending the PIN.
+- A SEPA account list saved empty, as fints-ts 0.1 and the Dart package 0.2.0 saved it, is ignored on restore, as the
+  Dart package does after 0.2.0, so the client asks the bank for it again. Until the bank changed its user parameter
+  data, such a state kept the client from asking: `getAccounts` returned the accounts without their BIC, and an account
+  the app built from its IBAN went out without one, which a bank may refuse, or failed with `FinTsUnsupportedError`
+  where the user parameter data name the account by its number only.
+- `TanChallenge.tanMediumName` is `undefined` for a challenge in the dialog that looks up the TAN media, or where the
+  bank echoes it, instead of the placeholder `noref`.
+- The client no longer keeps the result of its last call, such as the transactions, until its next call or `close`.
+- `console.log` and `util.inspect` show an `Amount` as its `toString`, such as `-123.45 EUR`, as the Dart package prints
+  it, instead of its fields `minorUnits`, `scale` and `currency`.
+- An answer that is no FinTS message at all, such as the web page of a proxy or a maintenance notice, fails with the
+  `FinTsProtocolError` 'Malformed bank data: Not a FinTS message: no message header' instead of 'Malformed bank data:
+  Segment without terminator'. A message that starts with its header and is cut short still reports what is wrong with
+  it.
+- `HttpTransport` refuses an answer whose `Content-Length` announces more than `maxResponseBytes` at once, without
+  reading it, with the same `FinTsTransportError` as for a body over the limit, as the Dart package does. A server that
+  announced more and then stalled held the call until the timeout, 90 seconds by default. One that sent the whole answer
+  had it read up to the limit before the refusal.
+- `getTransactions` reads statement data that a bank sends as text instead of binary data, as it did for booked camt
+  documents: booked and pending MT940 (HIKAZ) and the pending camt document (HICAZ) were dropped without an error. A
+  malformed or overlong binary length still fails the call with `FinTsProtocolError`.
+- `TransactionFormat` `auto` takes camt.052 where the bank offers it and MT940 cannot be requested for the account (the
+  bank offers no `HKKAZ` version the client implements, or PIN/TAN does not permit it), instead of failing with
+  `FinTsUnsupportedError`.
+- A FinTS 3.0 time `240000` is midnight of the next day. So `Balance.bookedAsOfTime`, `Balance.bookingTime` and
+  `TanChallenge.validUntil` are set for it instead of `undefined`, and the account extension of the user parameter data
+  is read with it instead of being dropped as malformed, BIC, balance and data status included. `bookedAsOf` and
+  `bookingDate` stay the stated day.
+- camt: a booking or value date given as `DtTm` without a `T` after the date, such as `2023-12-31`,
+  `2024-01-02 10:00:00` or `2024-01-02t10:00:00`, is the date written, as in the Dart package, instead of failing
+  `getTransactions` with `FinTsProtocolError`. Whatever follows the date is not read then. A `DtTm` or `Dt` with the
+  time `24:00:00` is midnight of the next day, as a FinTS 3.0 time `240000` is. A `Dt` with date and time counts on its
+  German day, as a `DtTm` does: `2024-03-15T23:30:00Z` is 16 March.
+- MT940 and camt: `SVWZ+` after `ABWA+` or `ABWE+`, the order some banks write them in, starts the remittance
+  information, which went into the ultimate debtor or creditor, leaving the whole text, keywords and all, as the
+  purpose. Any other keyword in that text still starts no value, and one that occurs twice still has none.
+- MT940: `getTransactions` joins pages with `@@` where none of them holds a line break. After a first page without `@@`,
+  such as `:20:X`, the `@@` of the other pages were read as text, and the query returned no transactions without an
+  error.
+- camt: a comment ends only after its `<!--`, so that `<!-->` starts one instead of closing at once, which turned the
+  comment into text; an attribute counts by its name, namespace prefix and all, so that `q:Ccy` is not the currency of
+  an amount; an element named with a leading colon, such as `<:Ntry>`, is not the unprefixed one.
+- The `EREF`, `MREF` and `CRED` of camt `purposeCodes` keep the place the remittance text gives them, before `SVWZ` as
+  banks write them, instead of following all other keywords. Their values still come from their elements only.
+- MT940: the booking date of an MT942 lies between its value date and the creation date `:13D:`, which the statement's
+  balances otherwise bound, instead of in the year closest to the value date: a booking `1230` with value date
+  2023-06-15 in an MT942 created on 2024-01-02 is dated 2023-12-30, not 2022-12-30.
+- MT940: a statement whose closing balance is dated before its opening balance, or whose creation date `:13D:` cannot be
+  read or is stated twice, is a `FormatError` (`FinTsProtocolError` in `getTransactions`) instead of being read.
+- MT940: a statement that balances is read also where a sum on the way lies beyond what an `Amount` holds (about 90
+  trillion at two decimal places, less with more decimals), as camt batch bookings are. It failed `getTransactions` with
+  `FinTsProtocolError` 'Malformed bank data: MT940 amounts too large to add up', and `Mt940.parse` with `FormatError`. A
+  statement that does not balance fails with 'MT940 transactions do not add up to the closing balance' however large its
+  amounts, as in the Dart package.
+- MT940: the subfield that ends a `:86:` field keeps the blanks at its end, as in the Dart package and before 0.2.0.
+  Where the bank writes it before subfields it continues, such as `?33Mustermann?32Max `, the purpose, the
+  counterparty's name and the SEPA keywords are joined with that blank (`Max Mustermann`, not `MaxMustermann`). Only the
+  statement end and line feeds are dropped from the end of a field.
+- camt: a batch booking whose details add up to it is split also where their sum on the way lies beyond what an `Amount`
+  holds (about 90 trillion at two decimal places), whatever the order of the details; such a batch stayed one booking.
+- U+0085 (NEL), the byte 0x85 in ISO 8859-1 text, counts as a blank wherever the client drops the blanks around a value,
+  as Unicode and the Dart package have it. That covers what it reads: MT940, SEPA purpose and camt values (a camt `Sts`
+  of `PDNG` followed by it reads as pending, not booked), the parameter data, such as the account owner, a segment's
+  type and numbers, amounts and challenge texts; and what it sends: segment values, the login details of `FinTsConfig`
+  and the TAN the user enters. The IBAN and BIC of an `Account`, which go without any blanks, drop it as well.
+- camt: U+0085 (NEL), the byte 0x85 in ISO 8859-1, counts as white space between the parts of a start or end tag and
+  between the nodes outside the root element, as other Unicode white space did and as in the Dart package. Such a
+  document failed `getTransactions` with `FinTsProtocolError` and `Camt.parse` with `FormatError`.
+- Bank text read as UTF-8 that starts with two byte order marks loses both, as in the Dart package; the second stayed as
+  U+FEFF in data element texts and the message log, and on an MT940 page after the first it failed `getTransactions`
+  with `FinTsProtocolError`.
+- The security control reference that ties the signature head (HNSHK) to the signature end (HNSHA) is drawn uniformly:
+  its first nine digits up to 794967295 came up a quarter more often than the rest.
+- A number in the parameter data beyond 9007199254740991 (2^53 - 1), which a JavaScript number holds only approximately,
+  counts as not stated, as a malformed one does. Such a version of the bank or user parameter data went back to the bank
+  as `100000000000000000000` or `1e+22` instead of `0`. A minimum PIN length of that size failed every login with a
+  `TypeError`. Polling parameters of that size let a decoupled TAN method poll every 60 seconds with no limit on the
+  number of requests other than the 10 minutes, instead of the defaults. An account type of that size made `category`
+  `'other'` instead of `'unknown'`.
+- A number in the parameter data written `-0`, such as a version or an account type, reads as 0, as in the Dart package,
+  not as JavaScript's negative zero, which `util.inspect` shows as `-0` and `Object.is` tells apart from 0.
+- An account in the user parameter data whose national account has the older layout without sub-account (number, country
+  and bank code, such as `1234567890:280:12345678`) keeps its country and bank code, as in the Dart package. It got the
+  sub-account `280`, the country code `12345678` and the configured bank code, so queries for it named an account the
+  bank does not know. Three elements whose last is a country code, such as `1234567890:01:280` or `987654321::040`,
+  still read as number, sub-account and country code: a country code has three digits, a German bank code eight.
+- `getAccounts` completes an account of the user parameter data with the IBAN and BIC of the SEPA account list also
+  where one of the two states no bank or country code, which matches any, as in `Account.matches` and the Dart package.
+  This happens with a saved state edited so, or where a code the bank sent was only a byte order mark. The list entry
+  came out as an account of its own, and an account the app built from its IBAN went out as that entry, without bank
+  code, permitted transactions and currency.
+- Up to three further pages of a query may ask for an approval, as its first page may: the client asks `tanCallback`, or
+  waits for the app approval, as for the first page. Until now only the first page could, and a bank that asked again
+  for a later page failed every such query with `FinTsProtocolError`, without asking the user. Where a fourth further
+  page of the same query asks for an approval, the call still fails with `FinTsProtocolError`, before the user is asked,
+  and the dialog ends. A query thus asks the user four times at most, and an approval the user cancels still fails the
+  call with `FinTsTanCancelledError` and loses the pages fetched so far. The Dart package 0.2.0 asks for every page, up
+  to 1000.
+- `close` no longer waits for a transport that ignores the abort: five seconds after `close`, the request on its way
+  fails with a `FinTsTransportError` whatever the transport, and the dialog ends then have five seconds of their own.
+  A custom transport that ignored the `AbortSignal` and had no timeout of its own held up the call, and with it
+  `close`, forever.
+- A network error whose cause has no message of its own, as Node.js reports a refused or failed connection to a host
+  with both IPv6 and IPv4 addresses, gives the reasons of the attempts or the error code, such as
+  `fetch failed: connect ECONNREFUSED ::1:3000; connect ECONNREFUSED 127.0.0.1:3000`, instead of just `fetch failed: `.
+- The bank's dialog abort message (Formals B.7.6) fails the call with a `FinTsBankError` that carries the bank's
+  return codes and text, and ends the dialog. The bank sends it unencrypted, with the dialog ID `unbekannt` and message
+  number 9999, where it cannot tell them, such as for a broken message header, an unknown bank code or a bank locked
+  for a release. Such an answer to any message but the first of a dialog failed with the `FinTsProtocolError` 'The
+  answer belongs to another message than the one sent', which lost the bank's text, and the client then sent a dialog
+  end to the dialog the bank had aborted.
+- Balance and transaction queries that name the account by its international account (`HKSAL` 7 and 8, `HKKAZ` 7,
+  `HKCAZ`) name an account with BIC by IBAN and BIC only, without account number, sub-account and bank code, where the
+  bank parameter data rule out the national account (`HISPAS` 'Nationale Kontoverbindung erlaubt' `N`). They no longer
+  send an IBAN without its BIC, which the specification rules out (Messages B.3.2): such an account goes out with its
+  account number, sub-account and bank code instead, where it has an account number. Until now these queries always
+  sent the national account, and an IBAN without BIC with an empty BIC.
+- The account extension of the user parameter data (BIC, data status and complete balance) is read where the bank
+  pads it with U+0085 (NEL) or U+00A0, as the client allows for the other fields. Such an extension was ignored, so the
+  client fetched the BIC with the SEPA account list and the balance with a balance query.
+- A synchronization with the one-step method that the bank answers with `9955` (one-step TAN method not allowed) and
+  `3920`, as PIN/TAN B.8.2 prescribes for a user bound to two-step methods, is repeated with a method the bank lists,
+  with or without `9800`. It refused the login for good and forgot the PIN.
+- A call whose TAN method prompt after a refused login ends with an error, such as `close` during
+  `tanMethodSelector`, fails with that error and leaves no refusal behind. The refusal, which named a TAN method the
+  user may not use and not the PIN, outlasted the call: the client forgot the PIN, saved the refusal in `client.state`,
+  and refused every login until `clearLoginRefusal`.
+- Plain JavaScript can no longer change `Transaction.purposeCodes` or `AccountDataStatus.inventory` through the map
+  inside them: `ImmutableMap` keeps its entries in an ECMAScript-private field.
+- A flicker code whose start code states a length of 0, or sets bit 6 of its length, is refused, as a data element of
+  such a length already was. `FlickerCode.parse` read an empty start code, which rendered as ASCII data of length 0,
+  and dropped bit 6.
+- A flicker code whose tenth control byte announces another one is refused. It was read as if the list had ended
+  there, and the rest of the code was read from the wrong position.
+- A blank in the data of a flicker code, such as `1,00 EUR`, stays part of the data. The client removed every white
+  space before reading the code, so such a code in HHD_UC was refused and the challenge had no `flickerCode`.
+- A challenge whose HHD_UC is neither a photoTAN image nor a flicker code takes the flicker code of its challenge text
+  (`CHLGUC`). `TanChallenge.flickerCode` was `undefined` then, although `plainMessage` left out the code.
+- Challenge text counts as a combined challenge only where it starts with `CHLGUC`, after blanks, and the four digits
+  after it state the length of the code. Elsewhere it is shown as the bank sent it: `plainMessage` dropped everything
+  up to a `CHLGTEXT` anywhere in the text, such as in a payment purpose the bank copied in, and a `CHLGUC` in the
+  middle of the text gave a flicker code.
+- `TanImage.tryParse` refuses a container that declares an image of 0 bytes. It gave an image whose `toDataUrl()` was
+  an empty `data:` URL.
+- MT940: the balance date `0` or `000000`, which the specification allows for the first statement of an account,
+  reads as no date (`openingDate` or `closingDate` `undefined`). It failed `getTransactions` with
+  `FinTsProtocolError` and `Mt940.parse` with `FormatError`.
+- MT940: the `:61:` customer reference `KREF+` reads as the `KREF+` value of `:86:`, as the specification has it,
+  instead of `'KREF+'` for every such transaction.
+- MT940: a bank code in `?30` next to an IBAN in `?31` is `counterpartyBankCode`, not `counterpartyBic`.
+- `Mt940.parse` reads text that starts with a byte order mark or blanks, as `fs.readFile(…, 'utf8')` returns it. It
+  dropped the first `:20:` and returned its statement without `reference`.
+- camt: a transaction whose remittance information is structured only (`Strd/CdtrRefInf/Ref`, such as an RF creditor
+  reference) takes that reference as its `purpose`, which was `undefined` or the `AddtlTxInf`.
+- The README example saves `client.state` after `close`, not before, also where `close` fails: the answers `close`
+  waits for may bring a PIN the bank rejects at the dialog end, which a client restored from a state saved before would
+  send again, as well as the parameter data and the customer system ID of a request on its way.
+- The README says what the type declarations need: the global `URL`, `AbortSignal` and `fetch` types, from the
+  TypeScript lib `DOM` or `@types/node`, instead of a TypeScript version.
+
+## 0.2.0
+
+### Breaking
+
+- Keep a `FinTs3Client` out of Vue's reactive state (`ref`, `reactive`, Pinia): its fields are ECMAScript private now,
+  which Vue's proxies cannot reach, so every call fails with a `TypeError`. Use a plain variable, a `shallowRef` or
+  `markRaw`.
+- `FinTsTransport.post` takes an `AbortSignal` as fourth argument, which the client aborts on `close`: pass it to
+  `fetch`. Code that calls `post` itself must pass one; `HttpTransport.post` takes it optionally.
+- A custom transport reports failures as `FinTsTransportError`, with `statusCode` for an HTTP error. The client turns
+  any other error, another `FinTsError` included, into a `FinTsTransportError` that keeps only its message and that of
+  its cause, and `FinTsTransportError` takes and carries no `cause` any more.
+- A refused login is a `FinTsLoginRefusedError`, which `FinTsPinError` and `FinTsLoginDataChangedError` now extend, also
+  where the bank ends the dialog in answer to the login (it was `FinTsDialogAbortedError`). The client sends the PIN no
+  more then: see Added for `loginRefusal` and `clearLoginRefusal`.
+- `FinTsTanSetupError` replaces `FinTsUnsupportedError` where the client has no TAN method or medium to log in with: let
+  the user choose a medium or another method (`selectTanMethod`) rather than hide the feature.
+- `FinTsError` takes the message only, as `Error` does, and `FinTsBankError` takes no `name`: a subclass declares
+  `override name = '…'`.
+- `FinTsConfig` throws a `TypeError` for what the bank would refuse: a URL with user name or password, a country code of
+  other than three digits (280 for Germany, not 276), a German bank code of other than eight, and login details outside
+  ISO 8859-1. It trims the login details and the product, and `config.url` is a new copy at each access.
+- `HttpTransport` throws a `TypeError` for a `timeoutMs` that is no positive number up to 2147483647, and for a
+  `maxResponseBytes` that is no positive number.
+- A TAN longer than `TanMethod.maxTanLength`, with anything but the digits 0 to 9 for a `numericTan` method, or with
+  characters outside ISO 8859-1 fails the call with a `TypeError` before it is sent. Full-width digits count as digits
+  (NFKC).
+- A TAN callback answer that is no `TanAnswer`, such as the `undefined` of a callback that returns nothing, fails the
+  call with a `TypeError`.
+- Bank data are read strictly, failing `getTransactions` with `FinTsProtocolError` and the parsers with `FormatError`:
+  an MT940 statement that does not balance, states a balance, its account or its number twice, or holds an unreadable
+  balance, and MT940 text without fields; in camt, an unreadable date, a `DtTm` without time, and a document without
+  statements.
+- A negative amount next to a credit/debit mark is malformed: in camt and HISAL it fails the call, and it voids the
+  account extension of the user parameter data; a camt debit of `-5.00` used to read as a credit.
+- `TanImage.tryParse` takes PNG, JPEG, GIF, WebP and BMP only, no SVG, and `TanImage.mimeType` is in lower case.
+  `FlickerCode.parse` rejects a code that would not render as the bank sent it, so `TanChallenge.flickerCode` is
+  `undefined` for it.
+- `Account` keeps IBAN and BIC without blanks and in capitals. `Account.allowedTransactions` counts segment IDs only,
+  such as `HKCAZ`, no versioned names such as `HKCAZ_1`.
+- `FinTsFeedback.parameters`, and with them the new login data of `FinTsLoginDataChangedError`, and
+  `TanChallenge.reference` are read one character per byte (ISO 8859-1), as the client sends them back.
+
+### Security
+
+- The client keeps the PIN in a private field, out of reach of `JSON.stringify` and Node.js's `util.inspect`, though not
+  of a debugger or the browser's DevTools: never log the client. It forgets the PIN once closed or refused.
+- A refused login is kept in `state`, as the bank's return codes, so that a client restored from it, also one for
+  another URL of the bank, does not send the PIN. Any error in the answer to a login refuses it, and so does a wrong PIN
+  reported later, at the dialog end included. Run the clients of one user one after another: the state saved last wins.
+- After two logins in a row whose answer was lost, timed out or could not be read, which the bank may have counted, the
+  client refuses the login itself, with a `FinTsLoginRefusedError` without return codes, also across restored clients.
+- A call sends at most three logins the bank refuses: another TAN method and a new customer system ID count once per
+  call each, and a refused one-step login is repeated with another method only where the bank names the method (9075, or
+  a 3920 next to no error but 9050 or 9800).
+- New login data (3072) fail the call as soon as an answer to the login brings them, before any approval and also next
+  to errors; `clearLoginRefusal` cannot lift them.
+- `close` stops a running call at its next message and aborts the request on its way; only the ends of its dialogs go
+  out after it.
+- Error messages keep the PIN and account data out: a transport's error passes on its message only, without `cause`;
+  `FormatError` and `FinTsProtocolError` leave out the data; a URL with credentials is rejected before `fetch` puts it
+  in an error.
+- Messages go to the bank's URL only: `HttpTransport` rejects the answer to a redirect its `fetch` followed or from
+  another URL, and the transport gets a copy of the checked URL for each message.
+- An answer must be one complete message, with the number and, once assigned, the dialog ID of the message sent: one cut
+  short, broken in its framing, joined to another or answering another message fails with `FinTsProtocolError`. The
+  first answer of a dialog cannot be matched, so a relay must never mix up answers.
+- Parameter data come only from the answers to a dialog's opening; the anonymous dialog's serve until the user's arrive,
+  and those of another user, of a rejected customer system ID (9391) or of a state from an earlier version or the Dart
+  package are fetched anew.
+- A balance (HISAL) and camt transactions (HICAZ) must be for the account asked for, or the call fails with
+  `FinTsProtocolError`. MT940 is not checked, since banks write the `:25:` line in many ways.
+- An account the app builds itself goes out as the bank knows it and is checked against the transactions the bank
+  permits for it; one the bank names nowhere fails with `FinTsUnsupportedError` where those lists are complete
+  (UPD-Verwendung 0).
+- Hostile answers no longer exhaust the memory or hold up the thread: past 200,000 data elements per answer, 128 MiB or
+  200,000 statements and transactions per query, or XML of 256 levels or a million elements and attributes, a call fails
+  with `FinTsProtocolError`, and `Mt940.parse` and `Camt.parse` with `FormatError`; reading takes linear time.
+- An MT940 statement must balance, and name its account and number once, so that a payer cannot add a transaction or an
+  account with a purpose line that starts like a field, such as `:61:` or `:25:`.
+- A SEPA keyword in the text the payer or payee writes (`SVWZ+`, `ABWA+`, `ABWE+`) is part of that text, and one that
+  occurs twice has no value: such text replaced the creditor ID, mandate reference or IBAN the bank stated.
+- The creditor ID of a camt transaction is the creditor's (`Cdtr`) only, and the `EREF`, `MREF` and `CRED` of
+  `purposeCodes` come from their elements only, never from the remittance text.
+- A flicker code that would not render as the bank sent it is refused rather than shown altered on the TAN generator,
+  and so is a data element length of 0 or above 63. A TAN image of type SVG, which may carry scripts, is refused.
+- The docs say to show challenge text as text, never as HTML (`innerHTML`, `v-html`): it is the bank's text, or a
+  relay's.
+- The README relay serves the signed-in sessions of the app only, limits their requests, forwards to the bank of the
+  session only, refuses redirects and passes the signal on: update relays built from it.
+
+### Fixed
+
+- The README relay reports the relay's HTTP status as `FinTsTransportError.statusCode`, and its server passes the bank's
+  on. Without it, a bank that fails on the anonymous announcement of strong authentication never delivered its parameter
+  data.
+- The README names the minimum Deno (2.1) and Bun (1.2.6): with older ones a call from inside a callback waits forever
+  instead of failing with `FinTsStateError`.
+- The docs say when a call logs in again, which may ask for another approval, that `getTanMethods` may log in, that
+  `FinTsUnsupportedError` may follow a login, and the client's own limits of an app approval: 60 status requests where
+  the bank states none, and 10 minutes.
+- The PIN's length limits apply to the login only: a synchronization whose first parameter data ruled out the PIN the
+  bank had accepted failed its own dialog end.
+- An answer to a TAN or an app approval that asks for an approval once more (0030, 3955) fails with `FinTsProtocolError`
+  instead of reading as done, and only the first page of a query may ask for an approval.
+- While the client polls for an app approval, new instructions of the bank replace the open prompt, whose
+  `TanChallenge.resolved` settles; a settled prompt is no longer kept until `close`.
+- `getTanMedia` asks the bank unless the same call has just looked the media up; the list of a lookup that found no
+  active medium is handed out by every call; a TAN method switched back to has its media looked up anew;
+  `clearLoginRefusal` forgets the TAN medium, which the bank may have refused.
+- `getTransactions` rejects a `from` or `to` that is no valid `Date` with a `TypeError`, before it waits for other
+  calls; an Invalid Date went out as `0NaNNaNNaN`.
+- Values the bank issued go back as it sent them: dialog ID, customer system ID, TAN order reference, position to
+  continue at and TAN medium name, such as one in UTF-8 that fits ISO 8859-1, which the bank did not know otherwise.
+- A SEPA account list the bank answers by ending the dialog counts as rejected, and an empty one is not saved, so that
+  neither costs every client another login.
+- `HttpTransport` calls its `fetch` as a plain function (a browser's native one failed with `Illegal invocation`),
+  checks the size of an answer without a stream body, and reads the body of node-fetch.
+- MT940: `@@` separates the lines wherever the first line holds it; each page is decoded on its own; a booking date lies
+  in the year that places it within its statement; only `?` separates the subfields of `:86:`.
+- camt: a batch booking is split only into details that add up to it, in its currency; details count in `NtryDtls` and
+  purpose lines in `RmtInf` only; a `DtTm` counts on its German day; purpose lines cut at 35 characters keep their
+  blanks; `&constructor;` is an unknown entity.
+- Models keep copies of the `Date`s they are given, so that changing one in place changes no other, nor what a later
+  `getAccounts`, `getBalance` or `getTanMedia` returns. A complete balance of the account extension states the
+  `productName`.
+- An account of the user parameter data whose national account leaves out the bank code keeps its country code.
+- `state` encodes the parameter data once, as the bank sent them, and bank text is decoded in bulk: both held up the
+  thread with large data.
+- `FinTs3Client` extends no internal class, so that its declarations name no internal types.
+
+### Added
+
+- `FinTsClient.loginRefusal`, the refused login that keeps the client from sending the PIN, and
+  `clearLoginRefusal(pin)`, which lifts it with a PIN the user has entered anew; `FinTsLoginRefusedError`.
+- `FinTsTanSetupError`, for a missing TAN method or medium.
+- `Camt.parse`, which gives each statement of a camt document as a `CamtStatement` with its account.
+- `close` aborts a request on its way, through the signal of `FinTsTransport.post`; `HttpTransport` stops it.
+
 ## 0.1.0
 
 First release: a TypeScript port of the FinTS 3.0 client of the Dart package `fints`.
@@ -7,5 +523,7 @@ First release: a TypeScript port of the FinTS 3.0 client of the Dart package `fi
   parameters; TAN method and medium selection, chipTAN flicker codes and photoTAN images.
 - Bank parameter data, customer system ID and the chosen TAN method in an exportable state string, in the layout of the
   Dart package.
-- A client never sends its PIN again once the bank has refused a login.
+- A client never sends its PIN again once the bank has refused a login, but where the bank names a reason the client
+  takes care of in the same call: another TAN method (3920, or 9075 after the one-step method) or a new customer system
+  ID (9391).
 - Runs wherever `fetch`, Web Crypto and `TextDecoder` are available; no runtime dependencies.