Bartosz, you were working on it - please review the patch.

I Added support for getting status of offline users.

Is it this completed yet? Bartosz, please update the due date, we need to know its completion time.

I rewritten the plugin with annotation.

I also should mention we need a new mechansim for supporting last activity for "Server and Component Query" due to [[http://www.xmpp.org/extensions/xep-0012.html]]. because these packets don't delivered to our plugin.

Bartosz, please take a look at the last attached version, if we can use it in our project.

I revised the plugin for more advanced queries, and request this version to be included in tigase. in it's current state, it support requesting for getting last activity of a Jid and BareJID. I replaced "user not found" error message with forbidden to avoid attacker to find out what are registered users in the installation. I also added support for requesting a last Activity to a domain that it returns the up time of the system if the requested user is admin [forbidden otherwise]. I also added a buddy mode, that just friends of mine can access to my last activity and it prevents others from getting my last activity. this features works fine now just when I'm online, because when I want to get a user buddy list, I need a session of that user, and when I'm offline, I don't have any, so I think there should be a modification to the RosterAbstract class for supporting this[loading buddy list for a null session]. I also asked a question in forum about the how to recognize that this packet come from an admin user(checking packet permision for example) and waiting for answer to complete the remaining parts.

thanks for your attention

added

Hi,

After 5 month I had time to check the code for re-factoring and clean-up and resolve some null pointer exceptions and restrict last activity to BUDDY list in offline and online mode correctly. I request to merge this source code.

Hi,

Is there any hope for merging This Version?

Thank you, included.

Benham, do you have any information or tests which show performance impact of that plugin? I suspect that lots of queries for offline users might generate excessive DB traffic and slow the service down. Also, looking into the code, I am not sure if following use-case is correctly handled:

• A user from a federated server sends last activity requests to our service. Will, in such a case, a buddy list be checked on our own server to ensure the remote user has permission to check activity time of our user?

I run it on my active server currently with 100K users and 10K online users and I didn't see any bottleneck.

In Buddy restriction mode, I think there isn't any better way to handle this (except we use a cache for roster loading).

when a user from federated server sends last activity we didn't handle it correctly due to unknown roster. So I think in this case logical action is forwarding the packet to destination and restrict it with destination roster, but in this case if the destination user is offline, what can we do? (roster util needs session to load the user roster).

Behnam, thank you for details you provided, this is very helpful.

1. Do you have any information how frequently last-activity feature is used on your installations? I am asking because, even though 100k and 10k users is a significant number, the last-activity may not be called frequently, hence no performance impact. However, if we deploy this on a system where this feature is called very often things may look different. However, on the other hand, if the plugin does not do roster checks for offline users, than the impact should not be that significant.

2. Regarding the roster check for offline users when a request comes from federated server. I think you are doing the right thing here. Even though there are ways to check a roster for offline users, I think the performance impact would be unacceptable. However, current implementation handles requests form local users differently than requests from federated servers. It is more restrictive for local users and may allow to leak some information to users from federated servers. So my suggestion is to add a configuration option to disable last-activity checking for offline users when a call comes from a federated server. This way we can allow service maintainers to have more control over security.

1. Well in our system, when ever a user starts chatting with a person, it ask server last activity of that user. So I think it is a frequent request and I didn't see any bad impact about this.

2. It is a good idea to have this configuration. I'm at holiday right now, but I try to add this configuration parameter to control information leak in service. I think I should ignore packets from federated server in processNullSessionPacket.(I have no idea how to do it, , I appreciate if you give me a hint)

%bmalkow Can we close this issue? I'm not sure there's anything left needed here.