New EventListener to catch ''successful authentication'' events

Openfire Openfire Dev
1

Openfire currently offers three types of events:

GroupEvents (unrelated to this discussion)

SessionEvents:

  • A session was created.

  • A session was destroyed

  • An anonymous session was created.

  • An anonymous session was created.

UserEvents:

  • A user was created.

  • A user is being deleted.

  • A user’'s name, email, or an extended property was changed.

There’‘s a significant difference in the creation of a new session and a logon (which I define as a successful authentication attempt). I’'d like to be able to catch ‘‘authentication events’’ as well, as having a trigger that fires after a user successfully logged in can be useful.

I can see at least two possible solutions: We can create a new EventListener and -Dispatcher class that handles these events, or we can add methods to one of the existing structures.

The first option would create a new class that’'s a bit weird, because the ‘‘mirrored’’ functionality of authenticate/logon would be the essentially the same as ‘‘session destroyed’’. The second option would force all existing implementations of the interface to update, as the new interface-defined methods need to be implemented.

The first option, creating a new ‘‘AuthenticateEventListener’’, only introduces one slightly weird situation (in logoff/session-destroy situations where a class implements both the SessionEventListener and the new interface). I would prefer this over the other solution - several small interfaces as opposed to a few bigger ones should gives you more flexibility.

Opinions and/or suggestions anyone?

2

Hey Guus,

I updated the javadocs of SessionEventListener to better describe when the events are triggered. Those events are triggered when users authenticate or authenticated session are destroyed. The creation events are not triggered when an entity connects to the server (at that point the server cannot know if the user is going to authenticate as anonymous or not).

However, there is no event for “there is a new c2s connection” in Openfire. Do you think you will need such event?

Thanks,

– Gato

3

I’‘m sorry Gato, I didn’‘t see further than the end of my nose here. I dug a little deeper: it seems that the session-created event is thrown after authentication, but before resource binding has completed. As resource binding is/can be required by the server, I considered this part of the authentication process (that’‘s why I created the initial post). The event that is generated contains full JID information. It’'s weird that this is generated before resource binding is completed (this might even be a cause for problems similar to http://www.igniterealtime.org/forum/thread.jspa?threadID=25375).

This behavior is found in our regular client as well (This client is not using HTTP binding, as the client in which I initially found the problem in does). These are three consecutive stanzas received by the client:

<stream:features xmlns:stream="http://etherx.jabber.org/streams"><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"></bind><session xmlns="urn:ietf:params:xml:ns:xmpp-session"></session></stream:features>

Note the empty element in this first line. This is the server requiring the client to perform resource binding.

<iq xmlns="jabber:client" from="buzzaa.com" to="guus@buzzaa.com/Home" type="get" id="318-187"><query xmlns="jabber:iq:version"></query></iq>

This second line is sent by the server. It’'s triggered by the session-created event.

<iq xmlns="jabber:client" from="buzzaa.com" to="buzzaa.com/a6924d79" type="result" id="agsXMPP_320"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>guus@buzzaa.com/Home</jid></bind></iq>

Finally, the server reports that resource binding was successful.

In my opinion, it’'s not unreasonable for clients to wait for resource binding to finish before ending the ‘‘log-in’’ phase. Assuming that this is what you want to use the SessionEvents for (as I am doing), this causes potential problems.

We might be able to circumvent these kind of problems by creating additional events (separate events for session-creation, authenticating and successful resource binding, for example). That would give developers more flexibility.

What’'s your take on this?

4

I added a patch that adds a new event type to the SessionEventListener. The event is triggered in IQBindHandler, after binding has been finished successful. Existing SessionEventListener implementations got an empty method to reflect the change.

Edit: Hmm, the Gateway plugin class ‘BaseTransport’ should also have gotten the empty method. This wasn’t included in my diff somehow.
patch_resourcebind_event.txt (3769 Bytes)

5

JM-1221 =)