PIN Block field 52 about iso-8583-socket-queue HOT 17 CLOSED

Hi Noe!

No, it both doesn't come with such a specific logic and doesn't care about the pin block as this data is very sensitive. It is being encrypted by the POS terminal then checked on the bank side.

from iso-8583-socket-queue.

Thanks for your feedback.

Warms regards

from iso-8583-socket-queue.

Hi Juks,
Get an little issue with value send in de52.
i use an external crypto libs to format the secure pinblock but value send in de52 through SQ to the host is not formal well.

kindly assist

from iso-8583-socket-queue.

This seems to be a display issue. What is field 52 format?

ll-bin-char should be displayed correct.

from iso-8583-socket-queue.

yes. Even i use ll-bin-char same issue

Thats what client send 👍

curl -H "Content-Type: application/json" -X POST -d '{ "0": "1100", "3":"000000", "7": "1027160933", "11": "618160", "12": "191027130600", "24": "100", "25": "000", "33": 101010, "52": "0912AC251359B8D7" }' http://localhost:2017

also i remark that in httpcleintserver you declare hexfield value

// Todo: proper initialization with no hardcode
var hexFields = [52,55];

kindly explain

from iso-8583-socket-queue.

There was another hardcode, fixed it (forgot to mention this issue):
b5741ec

from iso-8583-socket-queue.

Hi Igor,
Thank for your revert.
After merge still get same issue,
I definitly remove field52 from hexFields rray and the value sent well.

Therefor I get sam issue with field 55. Even i remove it fro hexFields array

from iso-8583-socket-queue.

Hi!
Could you please provide the entire case exaple, like curl command you are using or equivalent.

from iso-8583-socket-queue.

Hi,
Kindly see below

{"0": "0100","2": "6367111201570495","3": "000000","4": "000000000500","7": "1910131642","11": "123456","12": "191013164212","14": "2001",
"15": "191023","18": "7011","19": "562","21": "686", "22": "600030V05100","24": "100", "32": "950160","37": "123456789878","41": "00048048","42": "0400600048048 ","43": "SCALP","48": "P310041100P92003236P70045 940164 6860081002000 TEST 7011P6100210", "49": "952","53": "0099000000", "55":"9f2608571f1e10d4fa4aac9f2701809f100706010a03a4b8029f37045bb074729f3602000c950500800010009a031508189c01009f02060000000010005f2a02064382023c009f1a0206439f03060000000000009f3303e0f0c89f34034403029f3501229f1e0835313230323831358407a00000000310109f41030000565f340101","128": "00000000"
} http://localhost:2017

from iso-8583-socket-queue.

Thanks! But there is no field 52 here, or? What is your expectation?

from iso-8583-socket-queue.

For De52 after remove it from hexData array it's passed well.
But for de55 send like thath, my host get it wrong like :

from iso-8583-socket-queue.

Hi Igor
any update

from iso-8583-socket-queue.

Hi, i am really sorry for this inconvenience, but i don't have means for coding right now. Went for bicycle training.

What actually hexFields does it just treat given values as hex coded. So for example 20 will produce a 0x20 byte (space, code 32) and 2020 will be to spaces. If field is not listed in hexFields it will just pass as a string.

https://github.com/juks/SocketQueue/blob/dd83a83f2e998180dce0f5417fd4db95f3a5c11c/lib/socketServer/lib/clientHttpServer.js#L180

What you get on your host side does show an easy explination in a straight point of view: there should be no zeroes at any scenario. Could you please provide the whole message on the host side or what is being logged by SocketQueue before sending. There might be some other format expected rather than ll-bin-char that is: LLLLDATA, where LLLL is starting length counter (one byte for field length under 100, or two bytes for greater):

https://github.com/juks/SocketQueue/blob/dd83a83f2e998180dce0f5417fd4db95f3a5c11c/lib/iso8583/lib/packer/ll-bin-char.js#L27

The problem might be also related with the value length. You cat try tweaking field length to se if there will be any difference.

from iso-8583-socket-queue.

Hi, thank for your revert.
The format expected for my host is LLLVAR b..255

from iso-8583-socket-queue.

So, did you solve it?

from iso-8583-socket-queue.

Not yet.
Is it possible to add lll-bin-char packer?
Im trying tweaking field type and when i use LLLANS and remove it from hex array, the field 55 has been get on my host but the contain value is not correct., Host parse it as hex. Seems like some hardcode convert my string entry send by the http client.

from iso-8583-socket-queue.

Probably your host expects ascii encoded length. So it is lllans format. According to your example above, you send the field value in HEX mode so need to leave it at hefFields or send in ascii.

I suggest you engineer the problem by producing the message payload in place then sending it to the host to see what happens. Just like this: cat ./test_payload.txt - | nc host port. You can copy the current message from SocketQueue debug output (run with --dangerous), then edit it with hex editor to understand whats wrong. There is not much options: first understand the way length is expected, then the message body (ascii or hex).

from iso-8583-socket-queue.