thanks for your reply

jasondwyer — Tue, 26 Jul 2011 01:20:58 +0000

thanks for your reply badlop!

yes, the openfire 'client control' plugin looked like it would do what we wanted.

( and of course once understanding the protocol we realised its not 100% perfect, but would provide enough insulation that would restrict all but the most determined )

its not a pressing issue at the moment, but we will probably need to have some controls in place to restrict client access at some point.

the way i'd prefer to go about it would be to somehow hook into a disco#info iq request from server to client to collect its capabilities pretty early in the stream, then to check the client 'name' in the response, closing down the stream if it doesnt have the right caps.

i took a look through the openfire plugin and that seemed to be the way it was being done there, and thought that was a reasonable approach.

we dont have any erlang experience in house at the moment, so i guess this might be our first foray !

thanks for the suggestions too, we'll have a go at your suggested patch too ( actually one of the ops guys here suggested perhaps modifying the login stanza with an additional element containing a token, but we'd rather keep our options open and not mandate non-xmpp compliant interactions )

cheers

jasondwyer wrote: all good so

mfoss — Sun, 24 Jul 2011 14:20:00 +0000

jasondwyer wrote:

all good so far, but our client is for public distribution and we would like to ensure that only our custom client is able to connect to the service.

has anyone come across a filter or other module which can detect ( through caps i presume ) the connecting client application, and disconnect if it doesnt match?

the openfire server has a plugin doing pretty much this,

Do you refer to this easy-to-bypass filter?
http://coccinella.im/bypassing-openfire-client-control

ejabberd doesn't have any filter like that. But I can think of two ideas:

1. Quick and dirty: configure ejabberd to listen in non-standard port, instead of 5222.

2. More complex and more dirty:
Apply this patch to ejabberd:

diff --git a/src/cyrsasl_digest.erl b/src/cyrsasl_digest.erl
index 40e7edf..9f4b226 100644
--- a/src/cyrsasl_digest.erl
+++ b/src/cyrsasl_digest.erl
@@ -158,10 +158,11 @@ parse4([], Key, Val, Ts) ->
 %% In that case, ejabberd only checks the service name, not the host.
 is_digesturi_valid(DigestURICase, JabberHost) ->
     DigestURI = stringprep:tolower(DigestURICase),
+    AccessCode = "dummy1dwyer2code3",
     case catch string:tokens(DigestURI, "/") of
-	["xmpp", Host] when Host == JabberHost ->
+	["xmpp"++AccessCode, Host] when Host == JabberHost ->
 	    true;
-	["xmpp", _Host, ServName] when ServName == JabberHost ->
+	["xmpp"++AccessCode, _Host, ServName] when ServName == JabberHost ->
 	    true;
 	_ ->
 	    false

Enable the options starttls_required and certfile in the ejabberd c2s listener.
And now the clients will need to use STARTTLS+SASL, and provide a non-standard response. In Tkabber's TclXMPP I had to add this change to login correctly:

diff --git a/xmpp/sasl.tcl b/xmpp/sasl.tcl
index 5ee6766..cf84c0d 100644
--- a/xmpp/sasl.tcl
+++ b/xmpp/sasl.tcl
@@ -204,7 +204,7 @@ proc ::xmpp::sasl::auth {xlib args} {                            
                 set callback TcllibCallbackComponent
             }
             set state(token) \                                                      
-                [SASL::new -service xmpp \
+                [SASL::new -service xmppdummy1dwyer2code3 \
                            -type client \
                            -server $state(-server) \
                            -callback [namespace code [list $callback $token]]]

ejabberd - Comments for "Restricting Client ( sort of user-agent filtering )"

thanks for your reply

jasondwyer wrote: all good so