You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if we set an empty value to the field with the fixed and variable length prefix, there will be no error when we pack such a message. Receiving side will get malformed data and will try to parse it...
It looks like for empty values we skip the length check, but we should not:
this is not a simple fix, as this if/return was added to fix other issue: #149
Example of the error when field 48 - Acceptor name is empty and receiving party is trying to read LLL prefix (which was not put into the message as we skip adding prefix because of ^^) and reads the value of the next field (49, currency code) instead:
failed to unpack field 48 (Institution/Merchant Name): failed to decode length: data length: 840 is larger than maximum 25
The text was updated successfully, but these errors were encountered:
Right, The code is very dangerous code
main parser that included MTI(bitmap) don't run correctly
it seems that we should update composite field only for #149
I believe I added #149 as a band-aid fix to a problem we were having locally with parsing, but with the updatest to moov its no longer a problem, so i think mfdevelopers's PR to remove it is a decent enough solution
Currently, if we set an empty value to the field with the fixed and variable length prefix, there will be no error when we pack such a message. Receiving side will get malformed data and will try to parse it...
It looks like for empty values we skip the length check, but we should not:
https://github.com/moov-io/iso8583/blob/master/field/string.go#L67:
this is not a simple fix, as this
if/return
was added to fix other issue: #149Example of the error when field 48 - Acceptor name is empty and receiving party is trying to read LLL prefix (which was not put into the message as we skip adding prefix because of ^^) and reads the value of the next field (49, currency code) instead:
The text was updated successfully, but these errors were encountered: