Hello,
First of all, thanks to anyone involved for the really good job done on
jabberd2.
I've been trying to add an Xmpp compatibility to some pre-existing
services : I already have an user-list, passwords, and a roster-like
buddy list. I choose to use MySql storage, for authreg and for sessions.
To ensure consistency, I'd like to prevent changes to auth data and
roster from any IM client. Users will use the old system to add or
remove contacts or change password, and the system will update the
authreg or roster-items table directly upon changes through SQL.
mod_authreg allows that : I disabled registration, without activating
password changes, and I use my out-of-band registration/password changes
(using <id> configuration attributes).
But I have not yet found any easy way to have a "read only" mod_roster.
- I've tried to revoke rights from the SM user on the table
roster-items. It seems to work server-side, but I think the server does
not report a failure to the client when modifying the roster, and it
seems some clients will update their local copy of the roster. Since
some clients will rely on this local list (it seem to be the case with
MirandaIM for example, even if it should not, according to
http://tools.ietf.org/html/rfc6121#section-2.2 ), this situation leads
to inconsistencies. It's not a major issue : if the clients start to
face problems, they can remove the account from their IM client, and
then re-add it. It should then fetch the correct roster form jabberd2
server.
So even if this solution is acceptable, it's not very clean. Also, I'm
not sure about the consequences on sm when having fine-grained database
rights.
At this time, I can see 2 other solutions, yet to try.
- creating my own module "mod_preventrosterchanges". This module would
only "handle" roster changes by dropping them, and pass everything else.
It would be added to the "in-session" chain, just before "mod roster".
- Adding new options "roster.disablesubscriptions" and
"roster.disablechanges", loaded from "sm.xml". For now, I think only
option in mod_roster is "roster.maxitems" (mod_roster.c : 839).
with "roster.disablesubscriptions" enabled, mod_roster would report an
error to the client when before calling _roster_in_sess_s10n, or in
_roster_pkt_user
and
with "roster.disablechanges" enabled, mod_roster would report an error
in case of Roster Set. (Inside _roster_in_sess. mod_roster.c : 557)
Such an error message seem to be described in
http://tools.ietf.org/html/rfc6121#section-2.3.3 with the
"<not-allowed/>" mark-up.
I guess those 2 solutions should behave nicely overall, and prevent the
clients form updating their local roster on a failed add/set/delete. The
only problem would be that clients will not get a Roster Push
(http://tools.ietf.org/html/rfc6121#section-2.1.6) when the roster is
updated using the previous system. This could probably be fixed with
another component sending Roster Push stanzas at sess_start when
updating roster from the existing database.
I'd be very grateful to hear any advice from people more aware of Xmpp
and jabberd2 constraints. Since I've been tinkering with jabberd2 for a
few days only, I'm probably overlooking other ingenious solutions. I'd
be glad to contribute to the project if alternate-solution #2 seems to
everyone a good thing to add.
Thanks to anyone who took the time needed to read my shameful
wall-of-text... And many thanks in advance for any answer/hint/advice...
--
Sylvain "Gugli" Guglielmi
