ejabberd分析(四) 用户登录


仍然看ejabberd_c2s 这个gen_fsm 模块。

上面客户端与服务器建立连接的初始几步直接略过。具体参见ejabberd分析(二),重点看下面的交互:

注:目前的状态为wait_for_feature_request

客户端发送如下的鉴权请求给服务器:

<auth mechanism="DIGEST-MD5" xmlns="urn:ietf:params:xml:ns:xmpp-sasl"></auth>

服务器端匹配到

同时获取客户端选择的加密方式(DIGEST-MD5)。匹配到以下路径:

以上代码会向客户端发送challenge并将状态设置为wait_for_sasl_response:

<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cmVhbG09Imtpbmdsb25nIixub25jZT0iQXZ4aFNmYXo3ZlpmMWpqdXh2Qmo4ZTF2SUZQRHNPWDdPUWVXVEFTdiIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==</challenge>

客户端收到后返回响应:

<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iMTU1NTUyMTU1NTQiLHJlYWxtPSJraW5nbG9uZyIsbm9uY2U9IkF2eGhTZmF6N2ZaZjFqanV4dkJqOGUxdklGUERzT1g3T1FlV1RBU3YiLG5jPTAwMDAwMDAxLGNub25jZT0icUlaU05ORjNGVmFRN0UzRklKUXI2UFpYaHZTa0hvOFkrZ2ZBVjJ0VCIsZGlnZXN0LXVyaT0ieG1wcC9raW5nbG9uZyIsbWF4YnVmPTY1NTM2LHJlc3BvbnNlPWYxNGM0NDc4NWYwMzNlMDZkNTE1Y2I3MjI4MzVlZmI2LHFvcD1hdXRoLGF1dGh6aWQ9IjE1NTU1MjE1NTU0Ig==</response>

xmpp的验证机制可参照网上的资料。

这里啰嗦两句:

前面的<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>就是在进行TLS握手。先通过TLS传输密钥给客户端,再使用此密钥按照SASL协议进行用户名、密码等验证。

服务器端在wait_for_sasl_response函数中验证通过后发送鉴权通过的消息给客户端,并将状态设置为wait_for_stream:

<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cnNwYXV0aD0wMjFkMjI4MTRmNjcwNDMxMTUxZDMwMTIwYzg3ODg0Ng==</success>

客户端继续发送如下消息给服务器,再次初始化一个流。

<stream:stream to="kinglong" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0">

此时服务器端的状态已经为验证通过,但客户端未绑定资源:

服务器发送bind给客户端,并将状态设置为wait_for_bind:

<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="kinglong" id="7acd9ea9" xml:lang="en" version="1.0"><stream:features><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>

客户端接收到后发送bind响应,绑定自己的资源:

<iq id="T2U7N-0" type="set"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><resource>Spark 2.6.3</resource></bind></iq>

服务器端在wait_for_bind 函数中进行资源冲突的检查,完成绑定后返回成功的消息,并将状态设置为wait_for_session,等待客户端建立session:

<iq type="result" id="T2U7N-0" to="kinglong/7acd9ea9"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>12345678910@kinglong/Spark 2.6.3</jid></bind></iq>

客户端发送session请求给服务器端:

<iq id="T2U7N-1" type="set"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq>

服务器端的wait_for_session函数中:

对消息进行判断,成功后然后返回result消息:

<iq type="result" id="T2U7N-1" to="15555215554@kinglong/Spark 2.6.3"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq>

接下来调用

来创建session,并将状态设置为session_established,并在session_established2中处理接下来的客户端消息。

原文地址:https://www.cnblogs.com/yjl49/p/2371957.html