Skip navigation
Up to Discussions in Openfire Dev
4576 Views 4 Replies Latest reply: Dec 22, 2007 7:09 AM by Daniel Henninger RSS
Guus der Kinderen KeyContributor
Guus der Kinderen
777 posts since
Sep 8, 2005
Currently Being Moderated

Apr 4, 2007 12:14 AM

New EventListener to catch ''successful authentication'' events.

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?

  • Gaston Dombiak Jiver
    Gaston Dombiak
    3,863 posts since
    Sep 26, 2001
    Currently Being Moderated
    Apr 6, 2007 12:45 PM (in response to Guus der Kinderen)
    Re: New EventListener to catch ''successful authentication'' events.

    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

    • Guus der Kinderen KeyContributor
      Guus der Kinderen
      777 posts since
      Sep 8, 2005
      Currently Being Moderated
      Apr 9, 2007 11:57 PM (in response to Gaston Dombiak)
      Re: New EventListener to catch ''successful authentication'' events.

      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?

More Like This

  • Retrieving data ...

Bookmarked By (0)