powered by Jive Software

Lack of IQInterceptor requires continued used of StanzaInterceptor

I see StanzaInterceptor is deprecated and marked for removal, and users pointed to PresenceInterceptor and MessageInterceptor instead. However I see no analogous IQInterceptor, so using the deprecated StanzaInterceptor remains the only way to achieve this. Is this a deliberate omission?

Yes, IQ requests are handled by the IQ handler, if you want to intercept the request, then you have to do it in the IQ handler (or wrap the existing one). The Smack debugger is still able to access all incoming our outgong data. Eventually, it depends on your use case what the best tool is.

IQhandlers are defined on a per QNAME basis, so StanzaInterceptor or SmackDebugger.onIncoming/OutgoingStreamElement allow me to control all traffic.

I’ve found the following comment in AbstractXmppConnection, do we plan to allow interception in this way in the future?:
// We do not (yet) support interceptors for IQ stanzas.

Maybe, it depends if I believe that it’s something we want in Smack. I did not come up with a sensible use case for IQ request interceptors. What’s your use case and which feature do you want from the interceptor?

My use case is capturing of all incoming / outgoing packets to allow redaction of private information before logging. This was previously done with StanzaInterceptor/Listener in Smack 3.x. The logic is dependant on the class in hand (Message, AuthMechanism etc) so I think what I want can be achieved with the SmackDebugger interface and incoming/outgoingStreamElements methods, in which case I agree, a specific IQInterceptor is not required.

Yes, that sounds like you want a Smack logger with the desired functionality and not a stanza interceptor. Redacting sensitive information from logged stanzas sounds like something that others could be interested too. Please feel encouraged to attempt to upstream your solution.

The redaction is specific the contents we are expecting to see and unlikely to be more generally useful unfortunately, but we want to be upstreaming as much as we can!

I figure it would be a redaction mechanism that takes a set to strings to redact. So the mechanism is generic but can be filled with specific strings. Then again, “redcation mechanism” can mean a lot of things. Looking forward to your contribution. :slight_smile:

Aha, our logic is more bespoke with regex’s for specific things we’re looking to redact, we haven’t made it generic at all.

We found a use case for IQInterceptor; we have extended Java.io.File and StreamInitiation.File to allow support for thumbnails. Currently we use a StanzaInterceptor to snoop outgoing IQ packets and set the file field on StreamInitiation to a thumbnailed file.

That sounds more like a use case for a “stanza sending” listener. Interceptors are able to modify the stanza, while your use case appears to just require read-only access to the stanza that is about to get send.

If we’re changing the file member on the outgoing StreamInitiation IQ stanza that needs to happen before we serialize it to XML, via an interceptor in our case at the moment, whilst stanza sending listeners are invoked on the stanza post serialization?