Patch Submission : Option to Register Plugins as Full Domains instead of Sub Domains

Please reference my earlier post for background titled :

Change Request : Option to Register Plugins as Full Domains instead of Sub Domains

Attached is a patch representing my submission to allow plugins to function as full domain handlers. Can you review for consideration of inclusion in the main product line? That way we wouldn’t have to maintain our own branch to support our plugin, especially considering that the changes required to support are very minor. I used a flag interface in order to avoid changing the plugin API so no existing plugins have to make any changes.

Thank you.

Message was edited by: Matt B I added the wrong patch file to the original post. It has been corrected here. Sorry for the mistake.

Hi Matt -

interesting idea … but I wonder if this is conforming to the XMPP specifications, particularly related to federated (S2S) message routing. Also, might this introduce a vulnerability for spoofing other domains? I am not opposed to the patch, but I would like a few others to comment/respond before we would merge this type of routing change into the core product.

If it passes muster after further community consideration, one additional request I would have is to put this capability behind a configuration property that would require an admin user to explicitly enable it for a particular installation (off by default). This would further protect against inadvertent (or ill-intentioned) plugins that intercept stanzas destined for other domains.

Anyone one else care to weigh in on this proposal?

I am not enough of an expert on the XMPP specifications to judge conformance which I would rank as very important so hopefully we can get an opinion. I am also aware that the routing logic and options are complex and numerous in Openfire generally and I have to honestly admit that I do not fully understand all of the subtle intricacies.

I think the off by default admin switch is an excellent idea which also eliminates a lot of the risk of unintended behavior to the user community at large, thus lowering the risk of inclusion. I believe this use case requirement is probably quite narrow which is why I hesitated so long in the first place to submit a patch request.

I think what we are looking for in very simple terms is a way to have a plugin fully intercept a full domain and handle it exclusively and this was the best I could come up with. Thanks for taking the time to consider.