Protect-Debug-Info not masking the sensitive data

shadei...@gmail.com

unread,

Feb 25, 2022, 8:26:47 AM2/25/22

to jPOS Users

Good day,

Please, my txnmgr.xml has the lines below as the last participants called by Q2:

And from the logs, I can confirm that both participants are called:

prepare: o.j.t.Open:open-db PREPARED READONLY NO_JOIN
prepare: c.i.j.t.SwitchParticipant PREPARED READONLY NO_JOIN
selector: 'Financial'
prepare: c.i.j.t.MessageReadParticipant PREPARED
************************ (Other participants) PREPARED
prepare: c.i.j.t.AbortImplementationParticipant PREPARED
prepare: o.j.t.Close:close-db PREPARED READONLY
prepare: o.j.t.ProtectDebugInfo:protect-debug PREPARED READONLY
prepare: o.j.t.Debug:debug PREPARED READONLY
commit: c.i.j.t.MessageReadParticipant
commit: ************************ (Other participants)
commit: c.i.j.t.AbortImplementationParticipant
commit: o.j.t.Close:close-db
commit: o.j.t.ProtectDebugInfo:protect-debug
commit: o.j.t.Debug:debug

but when i look at my Q2 logs, whereas the fep details i want wiped off, are really wiped off, the Field 2 in the ISO Msg remains clear. Using ProtectedLogListener in my logger.xml

protects the expected field but then once transaction manager drops the details in context, I end up with clear text in those fields again.

Please, assist with what I need to do to resolve this issue. I really don't see what I'm missing here as I have looked at the Programmers guide repeatedly.

Regards,

Shade

murtuza chhil

unread,

Feb 27, 2022, 10:29:18 PM2/27/22

to jPOS Users

You can try a simple ISOUtil.protect(pan) and see its output and determine if it meets the length requirement.

You can refer to the code that implements the protect functionality here

https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/iso/ISOUtil.java#L903-L943

-chhil

shadei...@gmail.com

unread,

Feb 28, 2022, 6:37:32 AM2/28/22

to jPOS Users

Hello Chi,

Thanks for your response. I can validate that the ISOUtil.protect(pan) works for my card pan - 628051*********4832.

But I don't know why it doesn't work when i call the ProtectDebugInfo participant. Please, can you help with what I may be missing here?

Shade

Andrés Alcarraz

unread,

Feb 28, 2022, 11:00:29 AM2/28/22

to jpos-...@googlegroups.com

Hi Shadei,

You can add a ProtectDeugInfo participant in the transaction manager. You can see an example configuration in ProtectDebugInfo javadoc

ProtectedLogger just protects ISO messages that are in the root of the log event.

Hope this helps.

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/c490dbdf-8aa8-42c6-bbda-10a52027acben%40googlegroups.com.

--

________________________________________

Andres Alcarraz - Senior Developer | Transactility, Inc. | Lima, Perú | e: a...@transactility.com | sk: alcarraz1976

shadei...@gmail.com

unread,

Feb 28, 2022, 4:49:00 PM2/28/22

to jPOS Users

Hello Andres,

Thanks for your response. But I did add the ProtectDebugInfo to my transaction manager and I can confirm it's been called. From the Q logs, I noticed the fields I want wiped out are indeed wiped out, it seems to be only the ones to protect the ISOMsg that isn't doing that.

prepare: o.j.t.Open:open-db PREPARED READONLY NO_JOIN
prepare: c.i.j.t.SwitchParticipant PREPARED READONLY NO_JOIN
selector: 'Financial'
prepare: c.i.j.t.MessageReadParticipant PREPARED
************************ (Other participants) PREPARED
prepare: c.i.j.t.AbortImplementationParticipant PREPARED
prepare: o.j.t.Close:close-db PREPARED READONLY
prepare: o.j.t.ProtectDebugInfo:protect-debug PREPARED READONLY
prepare: o.j.t.Debug:debug PREPARED READONLY
commit: c.i.j.t.MessageReadParticipant
commit: ************************ (Other participants)
commit: c.i.j.t.AbortImplementationParticipant
commit: o.j.t.Close:close-db
commit: o.j.t.ProtectDebugInfo:protect-debug
commit: o.j.t.Debug:debug

I guess I will put the code in my application and put some debug statements, hopefully, that would tell me what is failing.

Thanks for your time.

Andrés Alcarraz

unread,

Feb 28, 2022, 4:50:36 PM2/28/22

to jpos-...@googlegroups.com

Can you share how you configured it?

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/da8e3e9d-c1d7-4e60-8b48-003fffbcf91an%40googlegroups.com.

murtuza chhil

unread,

Feb 28, 2022, 9:37:48 PM2/28/22

to jPOS Users

You need to configure

property name="protect-entry" value="REQUEST" ("REQUEST", "RESPONSE" or whatever is your name of the name value pair in the context where the value is an ISOMsg.)

The code reads the object from the context and determines the type of object goes through its fields and does what's required.

See the java doc here and the code following it to see how the participant gets the "protect-entry" values and

https://github.com/jpos/jPOS-EE/blob/master/modules/txn/src/main/java/org/jpos/transaction/ProtectDebugInfo.java#L39-L64

-chhil

shadei...@gmail.com

unread,

Mar 1, 2022, 12:05:29 AM3/1/22

to jPOS Users

Hello Chi,

Thanks for your response. I looked at the code and noticed that property name was missing in my txnmgr.xml file configuration for it. I will include that and try it out.

Another question though, in the code, I noticed it cloned the existing ISOMsg and stored it in context, won't that make it display the clear text again when it drops everything in context in the logs? Just wanted to be sure.

@Andres,

Thanks for your response. I will try this out and re-engage if I still have an issue.

Regards,

Shade

murtuza chhil

unread,

Mar 1, 2022, 9:38:49 PM3/1/22

to jPOS Users

Not sure I understand your query...

The existing object is cloned and the data manipulated on the clone and "replaces" the original in the context.

https://github.com/jpos/jPOS-EE/blob/master/modules/txn/src/main/java/org/jpos/transaction/ProtectDebugInfo.java#L98

This participant should be placed after you have sent the response and no longer need to use the actual unprotected ISOMsg.

See section 9.4 of the programmers guide that has diagrams.

Bear in mind that this participant protects on the commit and abort phases.

https://github.com/jpos/jPOS-EE/blob/master/modules/txn/src/main/java/org/jpos/transaction/ProtectDebugInfo.java#L81-L86

-chhil

shadei...@gmail.com

unread,

Mar 26, 2022, 9:58:49 PM3/26/22

to jPOS Users

Good day,

Just wanted to give a final feedback in case someone comes across this challenge.

I put in debug statements and found out that the REQUEST and RESPONSE messages were ending as null when the application gets to the Protect-Debug Info participant and tries to pick them from context. I used REQUEST, Constants.REQUEST and even used c.i.u.j REQUEST as my protect-entry values to get the request out of the context, but all ended up as null.

So, I decided to put the Protect-Debug-Info participant in each of my switchparticipant groups as the last participant called and it still ended up as null.

My final and working solution was then to create a class and call the relevant ISOUtil methods from it and then called the class from my final participants in the groups and this worked. Finally, the relevant fields I want masked are now masked and okay.

Thanks for the time responding to my questions. It was all appreciated.

Regards,

Shade

murtuza chhil

unread,

Mar 27, 2022, 1:38:28 AM3/27/22

to jPOS Users

In your first participant that creates the context you can set the context trace option to true. This will tell you the changes made by each participant to the context. You will be able to figure out where the variables become null and of course you need the protect debug before they turn null.