The class declaration should look like this (assuming you are implementing just the packet processor):

public class Message extends AnnotatedXMPPProcessor
   implements XMPPProcessorIfc

The first thing to create is the plugin ID. This is a unique string which you put in the configuration file to tell the server to load and use the plugin. In most cases you can use XMLNS if the plugin wants packets with elements with a very specific name space. Of course there is no guarantee there is no other packet for this specific XML element too. As we want to process all messages and don’t want to spend whole day on thinking about a cool ID, let’s say our ID is: message.

A plugin informs about it’s presence using a static ID field and @Id annotation placed on class:

@Id(ID)
public class Message extends AnnotatedXMPPProcessor
   implements XMPPProcessorIfc {
  protected static final String ID = "message";
}

As mentioned before, this plugin receives only this kind of packets for processing which it is interested in. In this example, the plugin is interested only in packets with <message/> elements and only if they are in the "jabber:client" namespace. To indicate all supported elements and namespaces we have to add 2 more annotations:

@Id(ID)
@Handles({
  @Handle(path={ "message" },xmlns="jabber:client")
})
public class Message extends AnnotatedXMPPProcessor
   implements XMPPProcessorIfc {
  private static final String ID = "message";
}

The class declaration should look like this (assuming you are implementing just the packet processor):

public class Message extends XMPPProcessor
   implements XMPPProcessorIfc

The first thing to create is the plugin ID like above.

A plugin informs about it’s ID using following code:

private static final String ID = "message";
public String id() { return ID; }

As mentioned before this plugin receives only this kind of packets for processing which it is interested in. In this example, the plugin is interested only in packets with <message/> elements and only if they are in "jabber:client" namespace. To indicate all supported elements and namespaces we have to add 2 more methods:

public String[] supElements() {
  return new String[] {"message"};
}

public String[] supNamespaces()	{
  return new String[] {"jabber:client"};
}

Now we have our plugin prepared for loading in Tigase. The next step is the actual packet processing method. For the complete code, please refer to the plugin in the Git. I will only comment here on elements which might be confusing or add a few more lines of code which might be helpful in your case.

@Override
public void process(Packet packet, XMPPResourceConnection session,
	NonAuthUserRepository repo, Queue<Packet> results, Map<String, Object> settings)
	throws XMPPException {

	// For performance reasons it is better to do the check
	// before calling logging method.
	if (log.isLoggable(Level.FINEST)) {
		log.log(Level.FINEST, "Processing packet: {0}", packet);
	}

	// You may want to skip processing completely if the user is offline.
	if (session == null) {
		return;
	}    // end of if (session == null)

	try {

		// Remember to cut the resource part off before comparing JIDs
		BareJID id = (packet.getStanzaTo() != null) ? packet.getStanzaTo().getBareJID() : null;

		// Checking if this is a packet TO the owner of the session
		if (session.isUserId(id)) {

			// Yes this is message to 'this' client
			Packet result = packet.copyElementOnly();

			// This is where and how we set the address of the component
			// which should receive the result packet for the final delivery
			// to the end-user. In most cases this is a c2s or Bosh component
			// which keep the user connection.
			result.setPacketTo(session.getConnectionId(packet.getStanzaTo()));

			// In most cases this might be skipped, however if there is a
			// problem during packet delivery an error might be sent back
			result.setPacketFrom(packet.getTo());

			// Don't forget to add the packet to the results queue or it
			// will be lost.
			results.offer(result);

			return;
		}    // end of else

		// Remember to cut the resource part off before comparing JIDs
		id = (packet.getStanzaFrom() != null) ? packet.getStanzaFrom().getBareJID() : null;

		// Checking if this is maybe packet FROM the client
		if (session.isUserId(id)) {

			// This is a packet FROM this client, the simplest action is
			// to forward it to its destination:
			// Simple clone the XML element and....
			// ... putting it to results queue is enough
			results.offer(packet.copyElementOnly());

			return;
		}

		// Can we really reach this place here?
		// Yes, some packets don't even have from or to address.
		// The best example is IQ packet which is usually a request to
		// the server for some data. Such packets may not have any addresses
		// And they usually require more complex processing
		// This is how you check whether this is a packet FROM the user
		// who is owner of the session:
		JID jid = packet.getFrom();

		// This test is in most cases equal to checking getElemFrom()
		if (session.getConnectionId().equals(jid)) {

			// Do some packet specific processing here, but we are dealing
			// with messages here which normally need just forwarding
			Element el_result = packet.getElement().clone();

			// If we are here it means FROM address was missing from the
			// packet, it is a place to set it here:
			el_result.setAttribute("from", session.getJID().toString());

			Packet result = Packet.packetInstance(el_result, session.getJID(),
				packet.getStanzaTo());

			// ... putting it to results queue is enough
			results.offer(result);
		}
	} catch (NotAuthorizedException e) {
		log.warning("NotAuthorizedException for packet: " + packet);
		results.offer(Authorization.NOT_AUTHORIZED.getResponseMessage(packet,
				"You must authorize session first.", true));
	}    // end of try-catch
}

In Tigase server plugins are pieces of code responsible for processing particular XMPP stanzas. A separate plugin might be responsible for processing messages, a different one for processing presences, a separate plugins responsible for iq roster, and a different one for iq version and so on.

A plugin provides information about what exact XML element(s) name(s) with xmlns it is interested in. So you can create a plugin which is interested in all packets containing caps child.

There might be no plugin for a particular stanza element, in this case the default action is used which is simple forwarding stanza to a destination address. There might be also more than one plugin for a specific XML element and then they all process the same stanza simultaneously in separate threads so there is no guarantee on the order in which the stanza is processed by a different plugins.

Each stanza goes through the Session Manager component which processes packets in a few steps. Have a look at the picture below:

The picture shows that each stanza is processed by the session manager in 4 steps:

An important thing to note is that we have two kinds or two places where packets may be blocked or filtered out. One place is before packet is processed by the plugin and another place is after processing where filtering is applied to all results generated by the processor plugins.

It is also important to note that session manager and processor plugins act as packet consumers. The packet is taken for processing and once processing is finished the packet is destroyed. Therefore to forward a packet to a destination one of the processor must create a copy of the packet, set all properties and attributes and return it as a processing result. Of course processor can generate any number of packets as a result. Result packets can be generated in any of above 4 steps of the processing. Have a look at the picture below:

If the packet P1 is sent from outside of the server, for example to a user on another server or to some component (MUC, PubSub, transport), then one of the processor must create a copy (P2) of the packet and set all attributes and destination addresses correctly. Packet P1 has been consumed by the session manager during processing and a new packet has been generated by one of the plugins.

The same of course happens on the way back from the component to the user:

The packet from the component is processed and one of the plugins must generate a copy of the packet to deliver it to the user. Of course packet forwarding is a default action which is applied when there is no plugin for the particular packet.

It is implemented this way because the input packet P1 can be processed by many plugins at the same time therefore the packet should be in fact immutable and must not change once it got to the session manager for processing.

The most obvious processing work flow is when a user sends request to the server and expects a response from the server:

This design has one surprising consequence though. If you look at the picture below showing communication between 2 users you can see that the packet is copied twice before it is delivered to a final destination:

The packet has to be processed twice by the session manager. The first time it is processed on behalf of the User A as an outgoing packet and the second time it is processed on behalf of the User B as an incoming packet.

This is to make sure the User A has permission to send a packet out and all processing is applied to the packet and also to make sure that User B has permission to receive the packet and all processing is applied. If, for example, the User B is offline there is an offline message processor which should send the packet to a database instead of User B.

SASL implementation in Tigase XMPP Server is compatible with Java API, the same exact interfaces are used.

The SASL implementation consists of following parts:

Properties list for SASL plugin (urn:ietf:params:xml:ns:xmpp-sasl' ()

'sess-man' () {
    'urn:ietf:params:xml:ns:xmpp-sasl' () {
        factory = 'com.example.OwnFactory'
    }
}

'sess-man' () {
    'urn:ietf:params:xml:ns:xmpp-sasl' () {
        callbackhandler = 'com.example.DefaultCallbackHandler'
    }
}

'sess-man' () {
    'urn:ietf:params:xml:ns:xmpp-sasl' () {
      'callbackhandler-OAUTH' = 'com.example.OAuthCallbackHandler'
      'callbackhandler-PLAIN' = 'com.example.PlainCallbackHandler'
    }
}

'sess-man' () {
    'urn:ietf:params:xml:ns:xmpp-sasl' () {
        'mechanism-selector' = 'com.example.OwnSelector'
    }
}

After the XMPP stream is opened by a client, the server checks which SASL mechanisms are available for the XMPP session. Depending on whether the stream is encrypted or not, depending on the domain, the server can present different available authentication mechanisms. MechanismSelector is responsible for choosing mechanisms. List of allowed mechanisms is stored in the XMPP session object.

When the client/user begins the authentication procedure it uses one particular mechanism. It must use one of the mechanisms provided by the server as available for this session. The server checks whether mechanisms used by the client is on the list of allowed mechanisms. It the check is successful, the server creates SaslServer class instance and proceeds with exchanging authentication information. Authentication data is different depending on the mechanism used.

When the SASL authentication is completed without any error, Tigase server should have authorized user name or authorized BareJID. In the first case, the server automatically builds user’s JID based on the domain used in the stream opening element in to attribute.

If, after a successful authentication, method call: getNegotiatedProperty("IS_ANONYMOUS") returns Boolean.TRUE then the user session is marked as anonymous. For valid and registered users this can be used for cases when we do not want to load any user data such as roster, vcard, privacy lists and so on. This is a performance and resource usage implication and can be useful for use cases such as support chat. The authorization is performed based on the client database but we do not need to load any XMPP specific data for the user’s session.

More details about implementation can be found in the custom mechanisms development section.