ejabberd分析(二) 用户注册


ejabberd中由ejabberd_c2s处理:

ejabberd_c2s模块启动后gen_fsm的状态位于wait_for_stream

客户端发送

服务器端wait_for_stream 函数中经过

发送如下的响应给客户端


 由于客户端在注册时并未通过鉴权,所以wait_for_stream 中经过如下路径

向客户端发送feature消息,并将当前状态设置为wait_for_feature_request

客户端发送给服务器端

服务器端函数wait_for_feature_request中经过如下路径,并将状态再次设置为wait_for_stream:


客户端发送给服务器端

服务器端wait_for_stream中仍然经由以下路径:

send_element函数发送如下消息给客户端,展示服务器端可提供的鉴权方法,并再次将状态设置为wait_for_feature_request

由于是注册过程,所以客户端并不会从中挑一种开始鉴权过程,而是发送如下的iq消息给服务器端。以下消息查询服务器端注册时所需要的参数


服务器端的wait_for_feature_request 函数中按照xmlns属性处理:

由于客户端发送的是iq消息,xmlns会匹配到最后一项。

在process_unauthenticated_stanza函数中:

调用含有名为c2s_unauathenticated_iq回调函数的模块来处理iq消息。

此回调函数在mod_register模块中定义:

其对应于mod_register模块中的unathenticated_iq_register方法
以上标蓝的部分即为具体的处理函数。process_iq 将iq按照type 分为两类来处理:

本次客户端发送的iq type 为get ,所以匹配到get

至于下面的判断我们目前可以直接无视,匹配到true就OK。

于是服务器端发送类似如下的响应给客户端:

注意,我们在函数process_unauthenticated_stanza处理完当前的iq后状态仍然设置为了wait_for_feature_request。

客户端按照服务器要求的参数发送注册信息给服务器:

由于我们的状态没变,消息同样也是iq消息,type=set 所以本次轮到了set的处理:

set 项是一个if 结构的语句:

UTag、PTag、RTag 分别对应于username,password,remove

正常的注册流程走

这里有一个比较关键的变量IsCaptchaEnabled 他是模块的配置参数之一,默认为false。

所以我们在调用try_register_or_set_password 时会匹配到如下代码:

_ when CaptchaSucceed ->

具体注册由try_register 函数完成。

经过ip验证后 调用ejabberd_auth:try_register(
                       User, Server, Password)

ejabberd_auth中遍历配置文件中的每个MOD,并调用try_register/3 方法。注意:这里配置文件中写的只是模块名称的一部分,完整的为:ejabberd_auth_XXXX

例如ejabberd.cfg 中配置为{auth_method, internal}.那么实际调用的为ejabberd_auth_internal:try_register/3

最终我们在try_register/3 中看到如下的代码:


这就是最终注册的代码了。








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