Skip navigation
All Places > Ignite Realtime Blog > 2008 > February
2008

We are very pleased to announce that Openfire has breeched one million downloads (not including downloads not from our site)!

 

 

We couldn't have done it without you all, the Ignite Realtime community!  (well of course not, we needed -someone- to download it    )  It's always fun to watch a milestone come and go, and take a moment to reflect, so I thought I would take a little bit to talk about Openfire's history, and even a little about my own personal history with it.

 

When I first found what is now called Openfire, it was somewhere in early 2006.  At the time it was called Jive Messenger and I was the lead developer of PyAIMt and PyICQt and was told that my transports didn't work well with Jive Messenger.  It wasn't long before I 'fell in love with' Jive Messenger and around the middle of 2006, I began work on the IM Gateway plugin.

 

Not long after, I watched Jive Messenger turn into Wildfire, run into a naming conflict, and then turn into Openfire.  As it turned out, Openfire became probably the most appropriate name, as it better reflected the open nature of the product, and was really catchy!

 

So approximately two years after I first became aware of Openfire, we've hit one million downloads!  That's pretty impressive for a server product!  Over those two years we've witnessed so many milestones in the world of XMPP.  One might even call it a "boom time" for XMPP at this point.  So lets all have a drink to Openfire's one millionth download, and to XMPP everywhere!  And also, we at Jive will be having a virtual toast to the Ignite Realtime community, and thank you for all of your involvement!  Happy road to two million!

Daniel Henninger

Big Brother In 3.5.0

Posted by Daniel Henninger Champion Feb 27, 2008

In Openfire 3.5.0, we have added two new features to address security concerns!  One of these features is security auditing.  We've had packet auditing in Openfire for quite some time now, but that only addresses communication amongst users of your Openfire server.  What the security auditing functionality provides is logging of administrative activities performed via the Admin Console.  Any action you perform that changes the server's configuration, adds, removes, or edits users and groups, or any number of things, will be logged into the security auditor database.  On top of that, we've implemented this via provider functionality just like the user providers.  What this means is that if you have a custom place you'd like to be logging audit events, or perhaps wanted to write some sort of sms event triggering implementation, you can do that and plug it into the existing infrastructure.

 

Beyond the security auditing, we have implemented the ability to lock out (disable) accounts.  By default, you can lock out accounts for certain periods of time, use delayed starts, or lock them out until manually unlocked.  You will find the option to lock out a user while viewing their account in the admin console.  Just like with the security auditor, the implementation uses a provider, so that you can implement whatever source you might have for disabled accounts.

 

The APIs should be pretty flexible and enable developers to build whatever solutions they might need around these two concepts!  I will be posting some more details in the Openfire Dev forum in the near future to go over some of the details and other API improvements.  We hope that you will enjoy the new functionality when 3.5.0 is released!

The next major release of Openfire is going to be 3.5.0 and it will be released on March 6th. Daniel and I are very happy with this new release since it has lots of new features and improvements. Today I will explain how you can be connected but invisible to all or some users. This has been a very popular request in Openfire and in XMPP in general.

 

 

A few XMPP extensions were created for invisibility using different strategies (and may be goals). Some of them focused only in blocking your presence to other users while others were blocking incoming/outgoing presences, messages and IQ stanzas. But they have something in common that jeopardized their success. In a nutshell, they not only required server side changes but also client side changes thus making it hard for a user to find a server and a client that supports them.

 

As of Openfire 3.5.0 there is a very easy way to be invisible and at the same time be able to maintain a one-to-one chat, a group chat or appear visible to the users of your choice or gateways of your choice. The best part of it is that we are not relying on any XMPP extension but just using the XMPP RFC core.

 

Usually XMPP clients follow these steps while logging in:

  1. Connect to the XMPP server

  2. Secure the connection with TLS

  3. Authenticate with the server using SASL

  4. Send available presence to the server indicating that the client is now publicly available (e.g. <presence><priority>1</priority></presence>)

  5. Request their roster

 

The forth step is actually optional so if clients do not send an available presence then they will be connected to the server but will not appear available/online to other users. Unavailable users cannot get messages from other users unless they made available to them.

 

When the user decides to appear as online to someone in particular he can send an available presence to that user (e.g.

). Being available to a user means that the user will see you online and you can now chat with that user.

 

Users that are publicly unavailable can also join a room and have a groupchat. However, if the room is not anonymous (i.e. real JIDs are sent to room occupants) then the other users will know that you are connected and chatting. But probably you won't care about that unless you wanted to chat without anyone knowing that you are you.

 

Currently our Spark and Sparkweb clients are not able to join in invisible mode but implementing invisibility this way should be a lot less work for clients than implementing some XMPP extension.

Filter Blog

By date: By tag: