宫论项目开发记录

2024年4月30日
1、xc_face_ok_hook钩子已通过xc_do_action挂载动作钩子，如果有其它业务需要对人脸识别结果进行回调动作，可以通过add_action来注册关联事件进行绑定，这样当人脸识别对比成功后，会在输出结果前将处理结果发送给对应函数，比如账户实名认证成功，其它业务需要触发回调通知，那么就可以使用add_action来创建一个函数来对接处理。注：动作钩子只负责回调，不负责结果返回。
2、人脸识别后续事件处理成功后，为了确保前端能够正确响应和处理业务逻辑（中转事件过多，导致业务无法解析）。xc_face_ok_hook钩子现在除了返回code和msg两个字段外，还会返回【type：人脸认证场景，比如账户实名（personal）、id：写入的主键ID、table_name：人脸识别的数据表名】需要特别注意的一点，这里表名和主键ID是xc_face。
3、前端新增钩子：xc_hooke_real_personal_ok，账户实名认证成功时候触发，具体为：人脸对比与用户输入的身份证信息结果一致。后端业务已完成封装处理，此时会通过xc_hook_face_result钩子触发code=0，如果携带的返回体type参数等于【personal】则此时会触发这个钩子，触发该钩子时会携带msg原始数据包过去。
4、当用户实名认证成功，前端页面会通过xc_hooke_real_personal_ok钩子依次执行以下动作。1、通过xc_msg触发提示【账户实名认证成功】。2、将user.is_login_real对象标记为true，告诉前端该账户已完成实名账户请求。3、锁定页面元素【page-content.xc_real_personal】将子类real_personal_btn的onclick点击事件移除、文本变更为账户实名认证成功、背景颜色调整为黑色。
5、人脸识别后台配置新增字段：xc_face_needPicture_local（人脸采集的图片存放路径），服务器本地目录:(绝对路径)。示例：示例:/www/wwwroot/www.acocoa.com/wp-content/xxx/<br>如果不想要外部访问这些图片，可以放到非网站目录。注：涉及到严重的隐私问题，目前暂不考虑同步到云端对象存储，仅限本地服务器存储。
6、后端新增文件下载钩子：xc_download_hook($url, $saveDir) 这个函数接受两个参数：文件的URL和保存文件的目录。如果目录不存在，函数会尝试创建它。如果目录创建失败，函数会返回错误信息。如果没有指定保存的文件名，函数会从下载文件的URL中提取。如果下载失败，函数也会返回错误信息
7、文件下载钩子优化，考虑到同名文件的存在。下载的文件如果沿用原有的文件名，会导致出现覆盖保存现象。因此文件会进行系统重命名。规则如下 1、通过pathinfo获取提取文件扩展名。2、通过time()添加时间戳和uniqid随机字符到文件名以避免冲突。3、最终的文件格式为1714451993_663076197b94f.jpg。jpg是原文件格式，通过url完成提取。这样的命名处理，可以避免同文件被覆盖的问题。
8、文件下载钩子现在返回标准的数组结构：code=0代表下载成功，url是本地文件路径。code=1代表下载保存失败，msg是失败的原因。文件下载一般有两个场景会发生错误。1、通过mkdir进行目录创建的时候，因为权限不足导致创建失败会返回错误。2、curl_exec请求失败时（文件不存在，拒绝响应）也会返回对应的错误码信息。
9、xc_face_result_hook如果请求云函数成功，会对返回结果进行核验。如果返回值包含【pictureUrl：用户人像采集的图片地址（有效期15分钟）】则检查后台是否启用图片采集，如果启用则通过xc_download_hook将其下载到本地，路径由后台设定。保存成功后，将会将本地路径存放并更新到数据表主键中。方便后续查询。
10、xc_face（人脸识别核验结果数据表）和xc_real_personal（账户实名认证记录数据表）的三个同名字段进行加密存储（name：真实姓名。code：身份证号码、img：人像采集的图片），加密方式xc_encrypt($data)。如果需要提取这三个字段需要通过xc_decrypt($data)对其进行解密处理。否则会显示乱码。这三个字段涉及到用户个人隐私，出于安全考虑在写入sql前需要进行加密处理。
11、为了方便溯源，如果实名认证出现问题相关问题，可以通过官方渠道查询调用详情。xc_face数据表会通过字段：remake来记录face凭证（certifyId）。账户实名认证表xc_real_personal会通过字段：token来记录该值。注：certifyId是服务商（阿里云：蚂蚁金服）返回的唯一凭证，可以通过该字段返回查询结果（有时效限制！）
12、修复并解决xc_real_personal账户实名认证记录表写入失败的问题，一共有四个问题造成。1、name和code两个字段设置为varchar(16)和varchar(32)。但是加密后的字符大于这个数值造成sql执行异常。目前已全部变更为256。2、在执行sql写入前，没有在xc_face_ok_hook钩子中引入wpdb全局对象，造成sql无法顺利执行。3、return返回前端数据时，返回的是空【result】数组，正确应该是face_ok数组对象。4、在构建sql语句时，data字段错误的将,写成; 造成执行出现故障。目前已一一修正。
13、WEUI顶部提示消息组件优化，top_msg函数现在新增第三个可选变量（time）默认值为显示3秒，如果需要延迟或减少展示时间，可以通过改变这个字段来控制（目前只支持整数传递）不过需要特别注意的一点，顶部弹窗会遮挡左上角返回按钮，目前也不支持点击自动关闭。在进行长时间内容展示时，需要注意用户体验！
14、账户个人实名认证流程基本完成封装，交互执行动作如下。1、用户填写身份姓名、身份证号码表单，勾选页面相关用户协议。2、点击页面底部按钮（下一步，人脸识别认证）前端会检测用户表单是否输入正确，是否勾选协议、是否已实名过。如果不符合要求则返回提示中断请求。3、将用户提交的身份证号码、身份证姓名、通过ajax提交到后端进行处理。4、后端收到用户提交请求，会调用钩子：xc_face_check_hook钩子（账户实名的type值：personal）来执行检测。5、人脸前的核验检测包括一下（1。通过xc_is_face_metainfo检测是否符合环境要求，主要是获取设备SDK参数，获取失败则拦截。2、检查用户是否绑定手机号，如果未绑定手机号不允许进行实名。3、检测本次身份主体是否有人认证过，有人认证是否超过后台限制。如果超过拒绝。4、通过xc_is_login_idcard查询用户是否已实名过，如果已实名过则拒绝二次实名。5、通过xc_is_security核验用户环境是否安全可靠，不安全则需要核验短信。6、通过xc_idcard_verification_hook核验身份证和姓名是否有效（是不是存在合真人），如果不存在返回错误。7、读取用户可用人脸核验额度，如果不存在或小于1则需要付费【这里涉及支付系统，后面才接入】。）符合以上条件，则说明当前用户具备的实名认证的基础条件。6、调用内部封装好的云函数（xc_dcloud_face，请求获取certifyId凭证），如果获取失败或异常则返回对应错误。7、成功取得certifyId凭证后，将会建立redis令牌缓存，以用户设备指纹做标识。存储（用户身份信息、certifyId值）等信息，作为前后端交互的同行灵。8、后端的核验请求完成封装，返回code=0，并且附带certifyId参数。9、前端收到certifyId 凭证后，会触发xc_hooke_face_sdk钩子事件。钩子内部会通过xc_isplus来检测用户环境是否支持plus，如果支持则会触发APP通讯请求（xc_hook_h5_evaljs）。10、xc_hook_h5_evaljs是网页与APP通讯的钩子，实名认证会传递两个参数（type：startFacialRecognitionVerify、certifyId：之前的凭证）。11、APP收到startFacialRecognitionVer请求，则会检测certifyId值是否有效，如果有效则调用人脸识别SDK。12、用户成功调起实人认证界面，便可以进行人脸识别（眨一眨眼睛、向左右砖头）进行身份对比。12、完成人脸比对操作后将会触发complete监听事件（携带初步比对结果）账户实名认证会在原有基础上写入两个字段（type：face_result、certifyId）然后执行that.app_h5请求。13、app_h5是新封装的通讯事件（APP发送消息给网页端），完成人脸比对后，会将结果发送到前端钩子xc_hook_app_evaljs。14、前端xc_hook_app_evaljs钩子收到：face_result（人脸验证结果）请求后，会将数据进行还原成数组对象，然后执行单独的事件（xc_hook_face_result：人脸识别处理结果）。15、xc_hook_face_result负责将结果发送到后端处理，在发送前依旧会检测用户环境是否处于APP。16、后端收到人脸比对结构将会转发到xc_face_result_hook钩子来处理。17、xc_face_result_hook会尝试读取之前预设的令牌redis缓存，如果读取失败则返回【处理失败：令牌无效或已过期】，如果读取成功，但是令牌比对不一致则返回【处理失败：certifyId对比异常!'】。18、完成令牌比对后。直接对传递的数据包进行效验，如果数据包errCode不等于0，则说明错误或异常，此时将直接返回数据包的错误结果集。19、如果数据包表明人脸核对完成，则说明本次核验有效，账单已生成。此时会读取用户自定义字段【face_number】，进行-1处理。20、数据包具有伪造特性，为了确保安全。此时会执行第二次云函数请求xc_dcloud_face（请求的标识为：getAuthResult）。21、xc_dcloud_face会返回标准的结构体，如果不等于0则直接返回对应的错误信息。如果等于0，说明用户核验有效。22、通过xc_redis_count进行计数操作，计数标识为：api:face，统计人脸接口的调用成功次数。23、检测远函数返回的数据包是否包含pictureUrl，如果包含则说明存在人像采集。此时会通过xc_download_hook方法进行下载到服务器，下载保存的路径后台定义。完成下载后，会对下载地址进行xc_encrypt加密。24、执行sql写入动作，将本次的人脸核验请求参数、以及结果等信息写入到xc_face数据表（姓名、身份证、图片）会加密。25、根据云函数返回的字段【authState】来执行不同的业务逻辑。等于FAIL代表对比失败。直接返回【刷脸失败：人证信息比对不一致】。等于SUCCESS代表成功，触发单独的钩子：xc_face_ok_hook。26、xc_face_ok_hook是人脸核对成功的回调钩子：该钩子会接受id变量。该变量为人脸识别表的主键ID。触发后会检测是否存在记录，不存咋则返回【刷脸成功：但是(xc_face)数据表写入失败<br>系统问题，请联系管理员处理！】。27、xc_face_ok_hook如果处理的是【personal：账户实名认证】，那么会将本次实名记录信息写入到xc_real_personal数据表（这个代表用户真正意义上完成的实名认证）。28、除了写入sql记录，还会通过update_user_meta标记用户自定义字段real_type，将其标记为1。29、xc_face_ok_hook钩子支持do_action动作回调，如果其它业务需要知晓用户人脸比对成功结果，可以通过注册函数来进行业务回调。30、完成上述操作后，代表账户的实名认证流程（后端业务）已完成处理。此时会返回【code、msg、type、id、table_name】字段到前端页面。31、前端接收到人脸比对成功结果，会对msg.type进行判断，如果是【personal：账户实名认证】，那么将会触发xc_hooke_real_personal_ok钩子。32、xc_hooke_real_personal_ok钩子是负责账户实名认证通过后页面回调动作的，该钩子会接收msg（后端数据包）变量。33、xc_hooke_real_personal_ok会将实名认证页面操控按钮【real_personal_btn】进行如下操作，将onclick事件移除，防止继续点击、将按钮文字变更为账户实名认证成功、将按钮背景颜色调整为浅黑色。同时将user.is_login_real标记为true，告诉前端当前用户已完成账户实名。34、至此：账户实名认证流程基本完成！！

2024年4月29日
1、xc_face_result_hook基础拦截效验已完成封装，触发人脸识别结果处理时，会依次执行进行以下动作。1、通过xc_is_fingerprint获取当前设备指纹，然后以此作为主键，查询face_token缓存令牌数据是否存在，如果获取失败则认定用户非法提交。2、检查传递的对象是否包含（$face['certifyId']）凭证，如果未包含则视为非法提交。3、检测传递的certifyId是否与缓存令牌的certifyId是否一致，如果不一致则视为非法提交（最核心的一个效验）。4、检测errCode状态码是否为0，如果为0则说明接口本身就返回错误。此时将会返回对应的错误提示。
2、完成基础拦截事件后，会创建real数组 里面包含两个字段【way：getAuthResult、certifyId：$face['certifyId']】然后通过xc_dcloud_face发起云端函数请求，请求face云函数返回本次的处理结果。注：real所提交的两个字段都是必须的，如果有缺失会在云函数发起前就会返回错误。注：人脸识别完成，只能通过云函数来获晓是否对比成功。
3、通过xc_dcloud_face进行人脸结果核验时，基本可以确定已完成扣费工作（本次用户人脸识别需要支付服务商接口对应费用），为了避免云函数接口返回异常，导致后续处理失败。会提前执行两个动作。1、通过delete_redis_meta删除通讯令牌，确保用户的下次请求能够顺利执行，也是确保令牌被重复调用。2、通过缓存读取操作用户user_id，然后获取其字段【face_number】，在其原有数字基础上进行-1处理。相当于操作用户的人脸识别流量包。注：因为人脸识别场景可能存在非登录场景，所以扣费的处理必须通过缓存对象来获取。
4、xc_face_result_hook方法现在能正确响应并处理【xc_dcloud_face】核验的最终数据，有2种数据包返回。1、接口抛出的错误为标准的uni错误对象，这类错误统一返回code：1，msg是返回体加错误码。示例（0000:Api调用失败【424】：该certifyId用户未完成认证或认证进行中）2、人脸核验成功，但是需要通过authState字段来获晓检测状态。
5、xc_dcloud_face请求方法优化处理，现在能准确处理【getAuthResult和getCertifyId】两个场景业务返回。如果是getCertifyId来源，并且返回的errCode等于0则会返回certifyId值。如果是getAuthResult来源，并且返回的errCode等于0，那么将返回以下字段【authState核验结果、pictureUrl：身份证图片、data：原始数据包】
6、后台新增宫论redis计数器：【计数器】API - 人脸识别调用接口（标识：api:face）。当用户通过xc_face_result_hook完成人脸核验后（只要接口请求成功，不论核验是否成功）都会通过xc_redis_count方法进行计数操作。可以通过get_redis_count($key)获取计数器统计详情，支持查询【总数、今日、昨日、本周、上周、本月、上月、今年、去年】多维度的计数器查询统计。注：这个计数器可以监听每日接口调用次数，
7、通过xc_dcloud_face进行getCertifyId结果核验时，如果用户人脸核验成功。将会对返回结构体进行单独封装。返回给后端的字段如下【code=0标记为成功、authState：核验结果（SUCCESS代表是本人、FAIL不是本人）、pictureUrl：对象存储临时图片地址（有效期15分钟）、data：原始返回数据包】
8、当人脸识别接口完成扣费操作后，无论用户是否核验比对成功 都会建立sql数据表记录。写入字段如下【user_id：提交用户，通过缓存字段获取、type：来源场景、ip：当前客户端IP信息、ua：当前客户端UA信息、fingerprint：设备UUID码、name：核对姓名、code：身份证号码、img：临时图片地址、data：接口返回的数组对象、getMetaInfo：用户设备信息、time：当前时间日期、status：固定值SUCCESS或FALE】
9、人脸识别采集数据，在提交数据库时会进行优化处理。1、nanme身份证姓名、code：身份证号码，会通过xc_encrypt()方法进行加密，隐私安全保护。提取和效验这个参数必须进行解密。2、data字段存储json数据，该数据来源为云函数原始包，通过json_encode进行json字符处理。3、写入数据库后，会读取insert_id（主键ID），方便后续业务跟进。
10、人脸识别接口成功产生账单费用后，会对操作源用户$redis_meta['user_id']进行如下操作。1、读取对方自定义字段：face_number，如果值-1后小于0，则直接删除对方该字段。否则在原有的用户字段基础上-1处理。之前是仅进行-1操作，如果出现纰漏会出现负数。同时用户发起人脸识别时，可用额度检测增加一个判断。如果字段为空不存在也会返回错误！
11、人脸核验返回结果后会对$dcloud_face['authState']字段进行对比处理，如果等于FAIL，则说明检测失败。此时会直接返回前端【code=1、msg=刷脸失败：人证信息比对不一致】，如果等于SUCCESS，则代表认证合一返回前端（code=0、msg=刷脸成功：数据对比成功!）。如果以上情况都未触发，则会返回系统异常，防止死亡圈圈出现。注：为了方便后续业务的对接，无论是FAIL还是SUCCESS，都会返回【id、table_name】数据表名、主键id。
12、后端新增钩子：xc_face_ok_hook，需要传递【id：人脸识别数据表的主键ID】当用户完成人脸识别，并且核验对比一致时会触发该表。相关的业务回调可以通过这个钩子来处理。因为人脸识别的场景非常多，比如（解除账户冻结、账户实名认证、账户注销申请、找回丢失账户）等，业务逻辑都封装在xc_face_result_hook钩子内部，会造成维护非常不方便。只要人脸成功，并且成功建表。则通过xc_face_ok_hook来做处理，该钩子不需要返回操作结果，只管执行逻辑。
13、考虑到业务回调问题，人脸识别结构如果请求来源是：personal。则会在xc_face_ok_hook钩子内部依次执行以下动作。1、通过xc_get_sql读取数据表【xc_face】对应主键记录，如果读取失败则返回【刷脸成功：但是(xc_face)数据表写入失败<br>系统问题，请联系管理员处理！】2、强制通过update_user_meta方法来更新用户字段real_type，将其标记为1，表明用户已完成账户认证。3、创建xc_real_personal数据表记录，将用户实名记录写入到该表。如果写入失败则返回【刷脸成功：但是(xc_real_personal)数据表写入失败<br>系统问题，请联系管理员处理！】。4、返回coe=0，msg=刷脸成功：账户实名认证成功。

2024年4月28日
1、宫论后台人脸识别配置页面新增switcher字段：xc_face_needPicture，是否采集用户照片（开启后，将会采集用户的人脸图片）。需要慎重考虑，非身份证图片。而是人脸识别过程中拍摄的图片。这个涉及到用户隐私问题。注：涉及到本地存储问题，人脸识别通过后需要通过接口将图片采集到本地（并对存储地址进行加密处理）。
2、xc_dcloud_face接口优化，现在在执行云函数请求前，会读取后台配置xc_face_needPicture，来进行$real['needPicture']变量赋值。通过三元运算来决定该值属性为true和false。同样的云函数脚本执行frvManager.getCertifyId请求时会核验param.real.needPicture参数，如果为true则标记为采集图片信息。
3、face云函数脚本现在强制要求提供【way】变量，固定值（1、getCertifyId：获取SKD所需要的certifyId。2、getAuthResult：获取认证结果）与之对应的云函数脚本现在也以支持frvManager.getAuthResult方法的处理，该方法需要传递两个变量值：way= getAuthResult、certifyId：实名认证唯一凭证。云函数脚本收到请求后，会先核验秘钥和请求头是否符合规范，符合规范的情况下解析获得传递对象，然后通过对象way来知晓请求是获取凭证还是查询结果。
4、app项目新增网页通讯事件（app_h5：通过APP像网页发送数据包），该方法一般作用于handleMessage监听行为中，当业务请求处理完毕后，APP需要将结果发送到前端（网页内部）进行处理时将通过这个事件来完成。需要传递data对象数组，注意禁止传递字符串，必须包含data.type(方便业务进行区分)。该方法会在内部获取webview对象，然后通过currentWebview.evalJS方法执行消息下发。（单向通讯，不存在结果返回）
5、APP端新增通讯hook钩子：xc_hook_app_evaljs(data)，data是一个数组对象，必定包含type（操作来源）。钩子内部将通过type来识别场景，然后执行对应的业务逻辑，业务所需要的变量参数通过data来提取。注：之前的旧版通讯办法H5_js继续保持不变，后续的通讯请求则必须通过新版方法来处理。
6、网页端继续新增通讯HOOK钩子：xc_hook_h5_evaljs(data)，data是一个数组对象，必定包含type（操作来源）。钩子内部将通过type来识别场景，然后执行对应的业务逻辑，业务所需要的变量参数通过data来提取。注：之前的旧版通讯办法xc_app_js继续保持不变，后续的通讯请求则必须通过新版方法来处理。注：xc_hook_h5_evaljs是网页和APP通讯、xc_hook_app_evaljs是APP与网页通讯。两者都不支持回调，属于单向通讯。
7、网页与APP端新增一个固定调试方法【type:test】，如果需要对接口请求做通讯测试，可以通过xc_hook_app_evaljs来发起，只需要对讲type标记为（test）即可。注：虽然是调试预留方法，但是同样可以通过data来传递其它参数。需要特别注意的是，新增通讯事件必须先通过test的验收，在来自定义type标识。
8、app.js已完成数据包的接收处理，当APP项目通过app_h5执行evalJS数据发送请求时，前端会通过window.xc_hook_app_evaljs方法来接收数据，在成功取得data对象信息后，会先通过JSON.stringify转为json格式，然后在利用$.parseJSON将其转为json对象，最后在将对象转发到xc_hook_app_evaljs钩子进行业务分发处理。
9、APP收到（startFacialRecognitionVerify）请求时，会先检测certifyId是否存在，如果不存在返回错误并阻止后续执行。如果存在则调起实人认证界面。并对后续的动作进行监听处理。目前已支持的监听有（success：实名认证扣费成功（不代表认证通过，只是人脸识别成功。系统完成扣费）、fail：操作失败时被调用，一般为用户主动退出，调用接口失败、账户欠费、无权使用。complete：无论操作成功还是失败，这个函数都会在操作完成后被调用。）
10、成功调用APP端人脸识别SDK后，如果存在返回结果，会通过complete事件监听来触发【that.app_h5】方法，将SDK返回的结果信息（e对象）通过currentWebview.evalJS方法发送到网页端。网页端经过数据解析在转发到xc_hook_app_evaljs通讯事件。最后的业务逻辑处理通过该钩子来完成。注：转发e对象前，会将e.type赋值为【face_result】
11、新增前端钩子：xc_hook_face_result（）负责处理APP端返回的人脸识别结果。该钩子需要传递face_result数组对象，里面包含SDK返回结果集。在执行前会通过xc_isplus来效验用户环境，如果不处于APP则直接拒绝用户的执行。钩子触发后，会调用xc_loading_show显示【处理中】，然后将face_result发送到后端效验。注：是否人人脸识别成功，必须通过后端来决定。
12、新增后端钩子：xc_face_result_hook，负责处理人脸识别SDK返回的结果。该钩子返回标注的数组结构，来核验并返回处理结果。code=0代表操作成功，一般表明用户本次人脸识别效验成功。code=1代表失败，msg是详细的错误信息。注：code=1的返回包括（缺少参数诺参数错误、账户欠费、服务商异常不可用、刷脸异常、网络中断、用户主动退出、当前客户端环境异常）等等。
13、修复app与网页通讯出现【Error: java.lang.IllegalArgumentException: field】错误的情况，通过evalJS发送数据前会先通过JSON.stringify将对象变成字符串，然后在使用encodeURIComponent进行URL编码处理。这样可以确保传递的对象信息不回因为特殊字符造成解析异常。同样的通过xc_hook_app_evaljs接受APP数据时，会先试用decodeURIComponent进行uRL还原，在通过JSON.parse转为对象。
14、人脸识别过程中，为确保前后端交互安全（验收参数不会被非法篡改伪造）。app在执行startFacialRecognitionVerify方法时。无论返回的状态码是什么，都会通过h5.certifyId来获取验证凭证。该凭证会通过app_h5->xc_hook_app_evaljs->xc_hook_face_result->一直传递到后端业务钩子（xc_face_result_hook）。钩子将以凭证作为查询标准 来核验用户的请求是否安全可靠！

2024年4月27日
1、人脸识别核验接口：xc_face_check_hook增加过滤和动作钩子，在业务请求执行前会通过xc_apply_filters方法挂载过滤动作，可以通过外部自定义方法来接管处理结构。在返回结果前会通过xc_do_action方法写入动作回调，如果第三方业务需要接管人脸识别效验结果，可以通过自定义动作函数来触发回调行为。
2、后端在处理人脸识别请求，最终的返回数据包结构体如下。1、code=0：返回状态标记为ok、成功。2、token：秘钥令牌参数，前后端交互唯一效验参数。3、ID：xc_face数据表的主键值。4、name：身份证姓名。5、code：身份证号码（18位）。6、type：人脸识别核验请求来源。
3、增加人脸指纹令牌缓存face_token:' . $token。该缓存的有效期通过后台xc_face_token_time配置决定，一般大于30分钟，。缓存采用数组结构 内部字段结构如下。【token、user_id、name、code、type、id、fingerprint】注：可以通过fingerprint来核验操作方是否与生成方是否一致。
4、xc_face_check_hook不在进行任何数据表创建和写入工作，也不进行过期回调操作（经过此次数据库对比，容易出现问题）。现在改为通过redis缓存键位来效验用户令牌是否已有记录。具体表现为 函数执行后会通过xc_is_fingerprint获取用户设备uuid。然后以此作为缓存键名存储到redis数据库。钩子在完成基础效验后，会通过指纹令牌来读取该缓存，如果读取到了则进行参数对比。
5、人脸识别核验接口处理redis缓存的流程如下。1、通过get_redis_meta读取当前设备(uuid)是否有缓存记录，如果不存在或者缓存中的字段【name、code、type】与当前提交请求参数不匹配，则创建写入新的缓存数据记录。2、如果匹配成功，则直接读取缓存数据赋值到update_redis变量。3、读取到redis缓存后会提取其中的token和meta两个参数，而不是主传动生成。4、有效期保护设计，读取到redis缓存后，会刷新原有的token令牌有效期。
6、完成人脸识别核验后，最后会返回三个字段到前端页面。1、（code：0（业务标记为处理成功））2、msg：消息提示（SDK数据包完成封装，进行下一步操作）3、real：一个对象数组。包含参数如下【name：人脸识别姓名、code：人脸识别身份证号码、type：人脸识别消息场景、meta：SDK调用效验需要的参数信息、token：前后端交互令牌】。
7、宫论云函数脚本优化：人脸识别云函数脚本现在已支持外部域名访问，访问路径为xxXXX/face。并且请求face人脸识别云函数时，需要请求者提供自定义headers头部参数，如果未携带的参数，或者携带的参数与后台不匹配，则直接返回错误【非法请求[-3]】。注：body也是强制要求携带，如未携带则返回【携带参数不完整[-2]】
8、新增宫论云函数请求函数：xc_dcloud_face 需要传递固定数组对象【$real】里面包含需要人脸识别的用户必须信息。该函数触发后会在内部封装headers头部信息（与云端函数脚本保持一致）并通过xc_get_option来获取推送秘钥。完成上述两个鉴权参数封装后，将通过xc_post发起【人脸识别】certifyId凭证兑换请求。函数返回标准的数组结构，请求异常、失败、参数错误等会返回code=1。
9、后台新增字段：xc_app_face_api_link（人脸识别云函数地址）。出于安全考虑通过xc_dcloud_face发起人脸识别云函数请求，其接口请求地址将动态读取后台配置的字段。如果云函数地址出现安全问题（被暴露、被攻击）的情况，可以通过更换地址的方式来规避上述问题。注：需要留意HTTPS证书是否过期,避免请求异常
10、xc_dcloud_face已完成业务封装，该方法现在能够通过云函数来获取【certifyId】人脸SDK凭证。该请求会产生四种返回状态，分别为：1、非法请求（未使用或使用错误的header头部、秘钥解析错误）直接返回对应拦截。2、存在error状态标识，请求接口返回错误。一般为（缺少参数、欠费、空间不存在、请求过期、服务冻结）等等。接口会如实返回错误提示。3、errCode==0、代表请求成功，此时会返回code=0、certifyId两个参数。4、其他错误统一返回云函数接口异常。注：第二种和第四种会返回data、如果有需要可以通过这个返回值来监听错误。
11、方便后期维护管理，当人脸识别云函数返回错误时，会通过xc_log_error_warn方法来写入日志，日志标识为：dcloud_face。日志格式为【[时间: Y-M-D] - [错误:详细返回状态码和信息（示例：55001 Api调用失败，实人认证服务商服务不可用，请联系DCloud处理）] - [用户:UID] 】。该日志不会触发报警，只会在发生错误时，将其记录到日志文件。
12、减少云函数的等待响应时间，同类型参数（姓名、身份证、场景）一致的情况，会触发缓存方案。避免重复执行xc_dcloud_face来获取certifyId凭证。具体流程为：执行xc_dcloud_face函数前，会已设备指纹作为查询条件来检测是否有同类缓存，如果存在并且三要素都一致的情况，则读取redis缓存来获取certifyId凭证，并且额外返回一个字段cache【true】。注：因为缓存因素存在，在完成实名认证后，必须删除对应缓存！
13、新增网页端与APP项目通讯钩子：xc_hook_app_request()，接收一个数组对象data，需要传递的参数都必须通过这个变量传递（严谨一点，data必须包含type）。该钩子触发后将会通过uni.postMessage方法将data数据转发到APP项目内部，涉及到原生底层SDK的调用（人脸识别、扫一扫、自定义插件）的处理，都将通过这个钩子来处理。注：非必要的业务逻辑，尽量通过PLUS来处理，减少与APP的单向通讯。如果当前环境不支持plus则会返回错误。
14、新增人脸识别请求钩子：xc_hooke_face_sdk，因为人脸识别场景比较多，故而单独封装一个钩子事件。后续如果需要集成一些验证参数，可以通过钩子做到全局统一处理。该钩子只需要传递一个参数：certifyId（调用SDK凭证）函数触发时，会通过xc_isplus效验环境是否处于APP，如果处于的话，则封装data数据包【type：startFacialRecognitionVerify】，然后通过xc_hook_app_request将请求传递给APP响应。

2024年4月26日
1、后端在处理用户实名认证请求时xc_hooke_real_personal，新增一个拦截机制：会通过xc_get_option获取后台每个主体认证上限次数，然后对用户提交的身份证进行xc_encrypt加密转换，然后通过xc_is_idcard_user进行查询，如果返回的结构是数组，则利用count方法进行数量统计，如果数量大于或等于后台限制 则返回【认证失败：身份主体最多认证 ' . $number . ' 个账户】 防止同一主体无限认证！
2、新增后端钩子：xc_face_check_hook() 需要传递real数组 固定三个字段【name：姓名、code：身份证号码、type：人脸核验场景】该钩子负责核验用户是否具备人脸识别的条件，如果符合则会创建一个token令牌，并生成后端sql数据表记录。该表返回标准的数组结构，code=0代表符合条件，并返回token参数。code=1代表不符合条件，msg是错误详情。注：人脸核验场景比较多，每个场景的处理可能各不相同，因此需要通过type来做业务来源识别。
3、人脸识别——账户实名认证新增固定两个参数：1、xc_real_personal_free_number：免费次数，账户前 X 次人脸识别免费，超过次数则需要收费。免费额度最好设置为1-3，如果始终不免费则设置为0。2、xc_real_personal_free_cost：使用费用，超过免费额度，每次人脸识别都需要支付费用。
4、xc_face_check_hook接口已接入【personal：个人账户实名】拦截处理，当$type = 'personal'会执行以下检测。1、通过xc_is_login检测用户是否已登录，如果未登录则需要登录操作。2、通过xc_is_idcard_user获取身份证号码是否超过主体认证上限，如果超过则返回错误。3、通过xc_is_login_phone检测用户是否已绑定手机号，未绑定返回错误。4、通过xc_is_login_idcard检测账户是否已实名，未实名返回对应错误。5、通过xc_is_security检测环境是否异常。6、通过xc_idcard_verification_hook核验身份证信息是否有效，无效则返回错误。注：xc_face_check_hook是根据场景来进行对应参数效验，每个场景的核验标准各不一样。
5、新增用户自定义字段：personal_free（账户实名认证，人脸识别免费次数）。如果后台开启了前X次用户免费使用人脸识别，则在发起人脸识别前，会对其字段参数进行效验处理，如果次数大于或等于免费额度，则不允许用户通过免费额度来完成参数效验。调用人脸识别成功，并扣费成功会对用户该字段进行计数+1操作。
6、新增用户自定义字段：face_number（人脸识别可用额度），人脸识别场景会效验这个参数。如果不存在或返回值为0，则说明用户不能免费调用人脸识别，需要支付订单来重置购买人脸识别额度。示例：用户申请personal（实名认证），会先检测用户的自定义字段：personal_free可用额度是否存在，如果存在则检测是否小于后台免费次数。如果不小于则进一步进行检测是否存在face_number可用额度，如果不存在则返回错误【需要进行订单支付】在发起人脸识别请求。
7、后台人脸识别配，新增字段：xc_face_free_number（人脸免费次数），每次调用人脸识别接口（成功）大概需要支付0.85元，可以设置前X次用户免费。此处额度共享所有人脸识别场景，但用户首次调用是【账户实名认证】。如果设置为0，则表名平台每次实名认证都需要付费使用。注：可以视情况来设置额度参数。
8、注册成功回调钩子xc_reg_ok_hook：追加新的业务逻辑，当用户完成注册后会通过xc_get_option来读取后台配置xc_face_free_number，如果返回的值不等于0，则说明平台开启了【人脸免费次数】此时会通过update_user_meta写入额度次数到用户自定义字段（face_number）
9、APP项目移除AP-FaceDetectModule的引入，APP初始化启动请求中所需要的face参数现在通过：uni.getFacialRecognitionMetaInfo()方法来获取。并且face参数现在会通过xc_app_onLaunch_hook启动钩子执行写入记录，允许后端接口通过查询用户UUID来获取【人脸识别：MetaInfo】参数。注：MetaInfo这个参数是APP调用人脸识别必须品。
10、新增is检测语法【xc_is_face_metainfo】，尝试获取人脸识别接口所需的meta参数。这个函数首先检查是否是APP客户端，如果不是，则返回错误信息。然后，尝试获取设备的UUID，如果获取失败，则返回错误信息。接着，根据UUID从Redis中获取设备的元数据，如果获取失败或者元数据中不包含人脸识别的参数，则返回错误信息。如果所有检查都通过，则返回成功的信息和人脸识别的参数。标准的数组结构返回【code=0代表成功、face=是需要的参数。code=1代表处理失败，msg=是失败的详细信息】
11、通过xc_face_check_hook发起人脸识别请求时，会在执行其它参数效验前先执行xc_is_face_metainfo函数，确保当前操作的客户端环境处于APP，并且支持人脸识别SDK的调用。如果环境不支持，或者未能通过UUID获取到face所需要的媒体信息。则返回对应的错误，并阻止后续验证。如果获取成功则将face信息赋值到$real['metainfo']，以便后续业务使用。
12、当后端处理完，人脸识别拦截检测后，会创建一个xc_face数据表记录，具体参数如下。1、user_id：当前请求用户、type：人脸识别场景、ip：客户端IP、ua：客户端设备信息、fingerprint：客户端指纹信息、name：加密后的姓名、code：加密后的字符串、token：前后端通讯令牌、getMetaInfo：设备信息参数。、time：申请的时间参数、status：wait等待处理状态。注：如果数据库写入失败则直接返回【认证失败：数据库写入失败】，阻止后续处理。
13、为了避免段时间重复请求造成多次建表，后台新增一个字段：xc_face_token_time（令牌有效期）。在执行数据库写入前，会进行数据表检查,如果存在相同记录（type：请求场景、user_id：请求用户、nanme：姓名、code：身份证、status=wait）时间小于令牌有效期的。则不进行xc_insert_sql数据写入创建。而是提取原有数据表记录返回对应结果，并通过xc_update_sql更新时间日期。
14、人脸识别核验钩子在返回code=0（SDK数据包完成封装）的前，会对xc_face数据表进行一个回调操作。将数据表中token令牌已过期的记录，状态标记为：expired。检查语法条件如下：【数据表中time时间字段距离当前时间超过xxx分钟（后台Token令牌有效期），并且status=wait的记录，将它们的状态码统一变更为：expired】。

2024年4月25日
1、xc_is_login_idcard(检查当前用户或指定用户是否完成实名认证)函数进行重构处理，旧方法是通过查询数据表【xc_real】来核验，新方法则是通过【xc_real_personal】数据表来核验。并且返回字段（身份证、姓名）会进行优化，会使用函数xc_decrypt($data)对其解密处理。防止直接返回加密后的字符串数据。
2、xc_decrypt方法进行优化处理，如果openssl_decrypt进行解密失败，则说明秘钥或字符串本身并未加密。此时并不会直接返回false。而是进一步检测 通过base64_encode来查询原字符串是否为有效的 Base64 编码。如果不是则直接直接返回原始输入字符串。如果是则返回转码后的base64字符串。经过上述的处理，兼容性会更好，可以确保解密正常字符串不会被转义。
3、人脸识别配置中心新增字段【xc_real_personal_limit】实名主体限制，一个身份证主体最多实名X个账户，已实名的不受影响。当用户进行实名认证（人脸识别前，会经过内置函数核验。如果身份证已实名账户大于或等于此处设置）则会拒绝用户实名请求，并返回具体错误。正常情况下身份证只能实名一个账户，但是后期可以根据实际情况做出相对应的调整。
4、xc_is_idcard_user方法进一步优化处理，idcard 要检查的身份证号码。在完成身份证正则效验后，会通过xc_encrypt进行加密处理。加密后的字符串才会执行数据表查询。并且xc_real_personal数据表字段进行优化处理，name和code 现在的字段类型变更为【varchar(256）】防止加密后字符过长，造成写入失败。
5、APP项目包更新：底层提示基座调整到4.0.8，依赖的SDK（微信、支付宝、Push、MAP、录音相册）等都已完成同步更新。增加全新的模块引入（FacialRecognitionverify实人认证），负责云函数的人脸识别SDK的请求以及业务处理。同时移除自定义本地插件【支付宝金融级实人认证SDK】，后续所有的实名认证请求都通过云函数来处理！
6、账户资料页面，账户是否实名效验不在通过xc_get_real方法来处理，而是改为 xc_is_login_idcard($user_id, 'name')方法获取。同时在输出用户实名信息时，会通过xc_maskStringInRange进行脱敏处理。比如：张**。菜单地址跳转为【[xc_link type=global]/real/personal.php】。
7、后台人脸识别配置页面新增字段xc_real_personal_desc（htmlmixed）。展示于个人实名认证界面【头部自定义区域】可以在这里填写一些认证流程和相关说明介绍，字段支持HTML和短代码。在输出时会通过do_shortcode函数进行短代码转义处理。
8、考虑到很多场景都需要设置输入表单，特定封装一个全局通用样式【xc_setting_update_input】，该样式目前已支持（code：验证码、phone：手机号、mail：邮箱、pass：密码）等几种常规类型输入框。后续相关同类型的input表单引入创建，都必须通过该样式来处理，以做到后期样式的统一性。。。
9、宫论用户协议新增【账户实名认证协议】协议唯一标识real，协议地址（未定义），该协议作用于【xc_real_personal】个人实名认证页面，当用户填写姓名+身份证号 提交实名认证时，需要勾选该协议才能进行下一步。注：该协议通过do_shortcode短代码生成，页面会调用xc_login_protocol_check后台配置来决定是否默认勾选。
10、xc_user_visits_hook用户来访事件，如果用户已登录状态则会通过xc_is_login_idcard函数来效验对方是否已经实名认证。如果已实名则将is_login_real标记为true，否则标记为false。前端页面可以直接通过user.is_login_real来获晓用户是否已进行实名，对于一些特定安全行为，可以强制要求对方进行实名在操作。注：隐私保护，这里不会返回身份信息，只会返回布尔值！
11、新增前端钩子：xc_hooke_real_personal，用户可以通过这个函数来发起个人实名认证（人脸识别）请求，该函数不需要传递参数变量，执行后将依次执行以下检测。1、通过xc.is_login效验用户是否已登录，如果为登录则调用xc_login函数。2、通过user.is_login_real来检测用户是否已完成过实名，如果已返回则提示【处理失败：账户已实名认证】。3、通过user.is_login_phone检测用户是否已绑定手机号，如果为绑定手机号则提示【处理失败：实名认证前请绑定手机号】。并且立即执行xc_hook_jump_page('phone')，将用户页面跳转到手机号绑定页。4、通过user.is_security检测用户环境是否安全可靠，如果不安全则提示【处理失败：环境监测不通过】。并且执行xc_hook_jump_page('security')方法，将用户页面跳转到环境效验页面。5、尝试获取用户页面元素.page-content.xc_real_personal，并通过let将其赋值到【content】变量。如果获取失败则返回【处理失败：非法移交请求】
12、用户在提交实名认证请求时，如果完成了前端拦截检测后，则会创建一个对象数组【real】 然后从页面表单中获取用户输入值并写入到real.name和real.code中。然后一次执行两个正则匹配来效验是否安全可靠。1、身份证规则（/(^\d{15}$)|(^\d{18}$)|(^\d{17}(\d|X|x)$)/）2、中文正则匹配（/^[\u4e00-\u9fa5]{1,8}$/）。如果身份证匹配失败则返回：输入错误：身份证号码核验失败、如果姓名匹配失败则返回：输入错误：姓名必须为中文。如果参数都有效通过检测，则创建ajajx请求。
13、后端收到用户个人实名认证请求，会依次执行以下安全检测。1、通过xc_is_login检测用户是否已登录，如果未登录则返回提示【认证失败：请登录后再操作】，附带jump跳转参数：login。2、通过xc_is_login_phone检测用户是否绑定手机号，如果用户未绑定手机号则提示【认证失败：请先绑定手机号】，附带jump跳转参数：phone。3、通过xc_is_login_idcard检测用户是否已完成实名认证，如果已完成认证则提示【认证失败：当前账户已完成实名】4、通过xc_is_security检测客户端环境是否安全，如果不安全则返回【认证失败：当前环境存在异常】，附带jump跳转参数：security。完成以上检查，说明当前用户的自身条件已具备个人认证的条件，此时将会调用（身份二要素核验函数）xc_idcard_verification_hook，对用户提交的身份证和姓名进行检测。检测是否有这个真人存在。
14、用户通过xc_hooke_real_personal事件提交实名认证请求时，会通过xc_is_protocol来检测页面是否有未勾选的协议，如果有则触发提示【请查阅并勾选页面相关协议】。同时该方法最终传递的real数组对象增一个字段type：固定值为personal。注：人脸识别接口需要固定传递三个字段（name：用户姓名、code：身份证号码、type：人脸识别请求来源）。

2024年4月24日
1、身份证信息等参数涉及到用户敏感隐私，出于安全考虑平台在采集此类数据时，如果需要提交到数据库应当会进行加密存储，避免平台出现安全风险，造成用户核心敏感数据出现泄漏曝光。目前定义为敏感信息的有【身份证、姓名、证件照的图片地址、证件其它参数（地址、户籍、有效期）】注：平台在做安全等保的时候，这些参数加密也是强制要求的。
2、宫论新增AES-256-CBC加密算法，对于敏感字段需要提交数据库都需要通过加密在进行存储。加密函数已完成封装【xc_encrypt($data)】$data 需要加密的数据，加密成功后返回Base64编码的加密数据。该函数采用openssl_encrypt方法进行AES加密。返回Base64编码字符，是因为加密后的数据可能包含一些不可打印的字符，直接输出可能会造成问题。加个转码过程可能可以避免问题的发生。
3、宫论新增AES-256-CBC解密算法，对给定的加密数据进行解密。封装的解密函数【xc_decrypt($data)】$data 需要解密的Base64编码的加密数据。解密函数执行流程：先通过base64_decode对字符串进行还原，然后通过openssl_decrypt来执行（aes-256-cbc）数据解密请求，最后返回解密后的原始数据信息。注：加密和解密函数，需要配合一起使用。
4、为了确保加密数据的一致性，宫论加密和解密函数引入【密钥（Key）和初始化向量（IV）】机制，在执行数据加密处理的过程，会创建一个秘钥（MD5哈希生成）和IV向量值（MD5哈希固定值仅截取前16个字符）。这两个值是固定，在解密过程同样需要用到，以确保【加密算法的一致性】。如果key和IV出现不一致，将会导致解密异常和失败。注：秘钥和IV值是直接写在函数内部，无论什么情况都不允许进行变动修改。擅自修改将会导致以前提交的加密字符（数据库端）无法解密。
5、宫论秘钥管理配置中心，新增两个字段。1、xc_apikey_idcard_SecretID：身份证接口SecretID。2、xc_apikey_idcard_Secretkey：身份证接口Secretkey。集成第三方接口来效验【身份证(二要素验证)】以便效验用户提交的姓名+身份证号码是否有效。注：接口采用腾讯云市场方案，单次效验成本大概是4分钱。在发起人脸识别SDK核验前，会先通过接口效验身份证是否有效，避免不必要的请求。
6、redis安全检测新增配置；（idcard_verification：身份证二要素核验）参数如下：拦截方式IP，考虑到人脸识别请求会出现找回密码、解除冻结等非登录场景。主锁时间：86400秒（1天）触发上限5 次（每天只能核验最多3次）。副锁限制60秒。注：用户提交身份证和姓名 准备进行人脸识别请求，会核验参数是否准确（是否有这个人）。这里进行拦截处理！
7、新增后端钩子：xc_idcard_verification_hook（身份证信息验证函数），该方法需要传递$name 用户姓名、$code 用户身份证号码。该方法返回标准的数据结构，code=0代表查询身份成功、code=1代表查询身份失败。msg是失败详情。该方法会请求腾讯云市场【身份二要素】接口，检测传递的身份证和姓名是否有效，通过公安部数据库返回查询结果。
8、身份证二要素核验接口接入拦截机制，以下情况会被拒绝，返回code状态码【1】。1、redis_security_check检测用户今日使用检测次数，如果超过后台限制【24小时最多使用5次，每次间隔60秒】2、curl请求发生异常，通常为接口返回异常，网络波动异常。此时会返回相关错误。3、如果接口返回的数据不存在code或者code不等于200，则视为请求异常。将直接同步返回message结果。
9、身份证信息验证函数增加变量检测，name变量：会通过正则表达式匹配全为中文的模式，如果不是中文或字数大于8，则返回错误提示。code变量：通过函数xc_idcard_regular检测，如果返回false则说明不是身份证号，则返回对应的错误提示。这两个基础检测可以避免接口调用，在发起API接口请求可以拦截非法字符请求。
10、后台新增宫论redis计数器：【计数器】API - 身份证二要素核验（标识：api:idcard_verification）。当用户通过xc_idcard_verification_hook完成身份核验后（只要接口请求成功，不论核验是否成功）都会通过xc_redis_count方法进行计数操作。可以通过get_redis_count($key)获取计数器统计详情，支持查询【总数、今日、昨日、本周、上周、本月、上月、今年、去年】多维度的计数器查询统计。注：这个计数器可以监听每日接口调用次数。
11、身份证二要素核验接口优化：现在接口数据返回细致化处理。API请求发送成功后，会响应处理的返回状态有五种。1、$data['code']不存在或者值不等于200，这种情况一般是参数效验问题，此时会通过$data['msg']来捕获原因，并进行结果返回。2、$data['data']['result']等于2，接口响应成功。但是匹配不成功，此时会返回【核验失败：身份证信息不匹配】。3、$data['data']['result']等于1，接口响应成功，并且匹配成功，此时会返回【身份证核验成功】，并且附带data，里面包含了用户户籍地址，性别、生日等参数。可以根据需要进行提取。4、$data['data']['result']等于3，接口响应成功，但是返回库无。这种情况一般是【户口迁出/现役军人/移民/身份证不存在】。5、其它错误，目前不可知。直接返回验失败：未知原因!
12、xc_idcard_verification_hook钩子以下场景会触发xc_log_error_warn日志写入。1、curl发送的请求出现异常（未响应、被拒绝、网络断开）的情况。2、接口返回$data['code']值不等于200，也不是【400：请求参数错误】。那么可能的原因是【账户欠费、系统错误、服务异常、核验中心异常】。写入日志格式，[错误时间 - '日期'] [返回状态 - '400、500、999'] [错误 - '返回的错误信息'] [操作用户 - 'UID'] ['姓名' - ' 号码']。写入日志文件标识：idcard_verification
13、新增redis方法【clear_redis_security_check()】$key 需要清理的key前缀，需要在后台配置redis安全拦截。该方法将会清理指定的Redis安全检查key，比如后台设置了【comment：评论间隔配置】10分钟最多发送5条，如果超过了则会拦截请求，等待缓存过期才可以继续评论。这个新增的方法就是主动清理缓存，不用等待过期就能继续评论。需要特别注意的是，这个咱不能主动清理指定用户（涉及到动态IP），只能当前用户客户端触发。
14、身份二要素核验方法（redis安全拦截）优化处理，初始进行超速检测机制保持不变，但是后续的请求出现这两个场景则会通过clear_redis_security_check方法进行清理次数限制、超速限制。1、curl_errno返回错误，一般发生于请求超时、异常、拒绝、网络波动。这类情况视为请求无效，会主动释放拦截限制。2、接口商返回异常，code不等于200的情况。大概率是参数错误、欠费异常、系统错误等情况。这种一般也不会产生扣费。以上两种情况，并非用户的问题，大概率是服务出现故障。此时不应该进行上锁占用用户的接口额度，因此加入清理机制来确保能释放锁。
。

2024年4月23日
1、修复邮箱解绑验证码发送后，无法通过xc_hook_binding_email执行验证码效验的问题。原因：创建解绑验证码的场景参数为【unbind_phome】正确应该为【unbind_email】，目前已修正。并且验证码接口已集成了解绑验证码的发送处理，邮件模版如下：尊敬的用户： 您正在请求解绑账户邮箱。您的验证码是：" . $code . " 请在邮箱解绑页面输入此验证码以继续操作。如果您并未请求解绑邮箱，请忽略此邮件。 此致 系统自动发送，请勿回复。
2、通过验证旧邮箱账户来更换新邮箱的业务逻辑已完成封装，整个操作流程与短信换绑邮箱账户基本保持一致，先进行邮箱验证码效验，通过后生成uniqid令牌 并进入绑定新邮箱页面。在完成新邮箱的效验后，将换绑请求【uniqid令牌+新邮箱账户+验证码】发送到后端处理，后端对参数请求逐一效验，确认安全有效的情况，执行换绑操作。
3、xc_rebind_email_hook在处理完成邮箱换绑请求后，会通过异步的方式来执行【xc_notify_hook】。这里有一个语法异常情况，无法通过同步的方法来处理结果。为了确保返回结果不造成前端页面交互失效，暂且将其通过异步方法来执行。【报错：Fatal error: Cannot declare class PHPMailer\PHPMailer\PHPMailer, because the name is already in use in】
4、邮箱绑定成功回调钩子：xc_hook_binding_email_ok重构处理，现在会根据type来变更页面page-content区域。具体为bind：锁定元素【page-content.setting_bind_email'】、rebind：锁定元素【.page-content.setting_unbind_email】。然后将页面表单按钮全部remove移除处理，然后插入【当前绑定邮箱账户XXXXXX】。
5、手机绑定成功回调钩子：xc_hook_binding_phone_ok重构处理，现在会根据type来变更页面page-content区域。具体为bind：锁定元素【page-content.setting_bind_phone'】、rebind：锁定元素【.page-content.setting_unbind_phone】。然后将页面表单按钮全部remove移除处理，并插入新表单提示【当前绑定邮箱账户XXXXXX】。
6、宫论【手机号绑定、解绑】和【邮箱账户绑定、解绑】业务已全部完成封装，用户可以通过资料页面进行相关操作。手机号和邮箱都支持两种换绑处理。1、绑定的手机号或邮箱可用 则直接使用验证码完成换绑操作。2、若关联的手机号或邮箱不可用，则可以通过辅助方式完成验证【换绑邮箱，通过绑定手机号完成验证、换绑手机号，通过绑定的邮箱完成验证】。注：邮箱和手机号是账户安全重要凭证，两者都具备重置账户、解除风控的权限
7、新增数据表：xc_face（每次人脸识别发起，都会写入记录）。该表字段结果为【user_id：操作用户、type：应用场景、ip：客户端IP、ua：客户端设备信息、fingerprint：指纹信息、getMetaInfo：sdk生成的设备信息字符串、name：身份证姓名、code：身份证号码、img：认证的图片信息、data：接口返回的完整数据、status：实名认证的状态、token：加密凭证，用于前后端核验身份。time：操作时间、remake：备注信息、pay：支付凭证，保留字段】
8、宫论APP项目集成云函数：uni-cloud-verify 实人认证。后续业务涉及到【实名认证，人脸核对】都将通过这个【face：云函数】来处理。注：云函数发起的人脸识是调用阿里云SDK，相比之前的集成方案并无差别。唯一的区别在于价格上，阿里云自行集成方案是1元1次，按量扣费。通过云函数集成的处理方案起步价为0.85元，价格优势明显。
9、新增后台配置文件【acocoa/configure/face.php】主要负责【账户实名认证+人脸识别核验】的参数配置，图标库：fa-drivers-license-o。旧版的实名认证接口和相关配置参数将会被摒弃，将通过云函数方案重新设计一套认证接口（请求和回调都采用钩子机制来执行、允许追加业务一键部署）。
10、人脸识别配置页新增三个开关字段1、【xc_real_personal：是否开启实名认证，关闭后用户将无法进行账户实名（不能通过APP端发起SDK请求）】2、【xc_real_enterprise：是否开启企业认证，关闭后用户将无法通过营业执照的方式进行企业认证】3、【xc_real_face：开启人脸识别，关闭后用户将无法进行人脸核验。（账户解冻/找回账户/重置安全）等场景不可通过人脸识别方式解锁。
11、新增数据表：xc_real_personal（账户实名认证记录表）该表包含字段如下【user_id：实名认证用户、getMetaInfo：设备信息参数、ip：客户端IP信息、ua：客户端UA信息、fingerprint：浏览器指纹记录、name：实名用户姓名、code：身份证号码、img：图片信息、data：完整的数据包信息、time：认证时间、token：前后端交互加密令牌、status：认证状态码】
12、新增页面【global/face/real_personal.php】页面唯一标识：xc_real_personal，该页面用于用户进行账户个人实名认证，如果已实名认证则会脱密显示用户实名身份信息。如果用户未登录则会通过xc_empty输出提示【请登录后再进行操作！】注：账户一旦实名认证，不允许用户进行更换操作，防止用户存在账户交易行为！
13、后台简码配置页面新增【real：实名认证页面】，该自定义页面指向【[xc_link type=global]/face/real_personal.php】，允许前端通过xc_hook_jump_page('real'）或xc_page_list('real') 方法来直接访问个人实名认证页面。注：自定义页面，现在已支持短代码。在初始化xc.page_list数组时，会通过do_shortcode对link部分进行解析。
14、xc_is_idcard_user方法重构：通过身份证查询是否存在实名记录时，不在通过xc_real数据表来索引，而是通过新表【xc_real_personal】来索引查询。同时该表建立（user_id、code）组合索引，提示查询性能。并且：ip、ua、fingerprint、name、code字段都采用varchar类型来存储，进一步提升查询性能。

2024年4月22日
1、新增前端回调动作钩子：xc_hook_binding_email_ok，当账户邮箱完成绑定或换绑成功后会触发，携带两个变量参数。type|rebind:换绑成功/bind:首次绑定、email：本次绑定的邮箱账户。这个钩子触发后，会执行以下页面交互动作。1、将is_login_email标记为true，告诉前端，当前用户已绑定邮箱账户。2、检测页面是否存在【xc_user_setting .email span.value】元素，存在则将其文本变更为新的邮箱账户。3、通用类名回调：email_ID，将其文本和placeholder属性变更为新邮箱。5、触发xc_msg 提示用户邮箱绑定成功。
2、邮箱账户绑定页面【setting_bind_email】会通过xc_is_login_phone来检测用户是否绑定手机、通过xc_is_login_email检测用户是否绑定邮箱、通过xc_is_login_idcard检测用户是否实名认证。如果用户已绑定邮箱，则会通过xc_maskStringInRange脱敏显示邮箱账户，并在下方显示换绑提示【您已经成功绑定了邮箱账户，如果有需要更换邮箱的需求，我们有一套安全的验证流程来保护您的账户安全。如果您的原邮箱仍然可以使用，我们会通过发送验证码的方式，让您获取解绑的邮件，之后，您就可以绑定新的邮箱了。如果您的邮箱无法使用，但您的账户已绑定了手机号，那么您也可以通过手机号来完成邮箱的解绑操作。在最复杂的情况下，比如您的邮箱和手机号都无法使用，但如果您的账户已经完成了实名认证，我们仍然有一个备选方案：使用人脸识别技术来完成解绑流程。】。默认情况下会输出（通过邮箱账户进行换绑）菜单、如果用户绑定了手机号码则还会显示菜单（通过手机短信进行换绑）。
3、资料设置新增页面：【global/setting/unbind_email.php】页面唯一标识setting_ubbind_email，该页面需要传递GET变量【unbind_type】固定值：email：通过原邮箱来验证安全，并执行邮箱换绑操作。phone：通过绑定手机号来验证操作是否安全，并执行邮箱换绑操作。注：邮箱换绑流程和手机换绑流程基本一致，只是传参和执行钩子有差异。还需要注意的一点，邮箱只能换绑，不能单纯解绑！
4、邮箱换绑页面现在支持xc_order_access访问拦截钩子，拦截标识【setting_ubbind_email】、附带参数【unbind_type】。一共有三种情况会拦截用户访问该页面。1、如果用户未登录情况，不允许访问换绑页面。2、如果unbind_type=phone，但是xc_is_login_phone显示用户未绑定手机号则阻止访问，并提示【账户未绑定手机号】。3、如果unbind_type=email，但是xc_is_login_email显示用户未绑定邮箱则阻止访问，并提示【账户未绑定邮箱账户】。
5、短信场景模版新增配置【unbind_email：邮箱解绑验证码】，当用户通过短信来换绑邮箱账户时触发。具体参数如下：短信ID（2134016）、每日发送次数(5)该短信每日最多接收X条，超过则当日不在发送、短信验证码有效期(300秒)超过时间自动失效、发送间隔时长（60秒）防止重复请求、用户绑定手机号（开启）、登录用户才可用（开启）。短信模版【您的验证码：{1}，这是您解绑账户邮箱的操作验证码，如果这不是您本人的操作，请忽略本短信！】
6、邮箱解绑验证码发送事件已完成封装，前端钩子：xc_hook_sms_code在执行【unbind_email：邮件解绑】场景验证码请求时会进行以下两点额外检测。1、如果页面元素【setting_ubbind_email】不存在则返回错误，避免用户非法提交。2、通过user.is_login_email检测用户是否绑定了邮箱账户，如果返回false，则直接提示【账户未绑定邮箱，无需进行解绑】。同样的后端钩子：xc_sms_code_hook会通过xc_is_login_email检测用户是否绑定邮箱，如果未绑定则返回错误。完成上述额外效验后，会通过短信接口下发解绑短信。
7、xc_binding_email_hook钩子已支持(cut)邮箱解绑请求，后端会依次执行以下动作。1、在基础拦截基础上，检测code、type参数是否传递，如果未传递则返回参数异常。2、通过xc_is_login_phone来获取用户绑定手机号，获取失败则返回错误。不管是通过邮箱还是手机号换绑，都强制要求用户绑定手机号。3、如果unbind_type=email，则phone变量通过xc_is_login_email来获取用户邮箱账户，如果不是则通过xc_is_login_phone来获取手机号。4、phone完成赋值操作后，会检查是否存在值。如果为空则直接返回【换绑失败：账户未绑定过手机号/邮箱】5、通过xc_sms_code_check_hook执行验证码效验处理，如果出现异常则直接返回对应错误。6、回调xc_verification_code数据表，将验证码标记为OK。
8、邮箱换绑采用和手机换绑一样的验证机制，当用户通过xc_binding_email_hook钩子成功效验【短信、邮件】验证码后会创建一个redis缓存：unbind_email:uniqid，该缓存是一个数组 里面包含以下字段。1、uniqid：秘钥令牌，通过系统函数生成。2、user_id：令牌生成的用户。time：创建令牌的日期。email：换绑的邮箱参数。有效期为600秒（10分钟），返回前端的数据会将uniqid令牌一并发送过去。后续进行新邮箱绑定操作时，需要通过这个令牌来确保操作安全可靠性。
9、换绑邮箱验证码效验成功，前端会通过回调钩子执行以下动作。1、通过xc_msg发送提示【效验成功，可以绑定新的邮箱账户】2、将当前页面标题变更为【绑定新邮箱】3、将xc_get_code_1移除，然后在原有基础上写入xc_get_code。4、通过fadeOut和fadeIn进行页面DOM动画，渐隐移除unbind_email_old，然后显示unbind_email_new。5、如果后端传递了uniqid（换绑令牌），则将其写入到自定义属性【uniqid】。
10、新增前端钩子：xc_hook_rebind_email 负责处理邮箱换绑请求，该钩子需要传递固定值type【sms:通过短信解绑/email:通过邮件解绑】。该钩子会初始化数组对象unbind，然后依次执行以下检测。1、通过xc.is_login检测用户是否处于登录状态，未登录则调用xc_login。2、检测元素【.page-content.setting_unbind_email】是否存在，不存在则提示【换绑错误：页面元素不存在】3、通过jquery选择器获取页面表单（邮箱地址、验证码）然后检测是否为空或是否为有效的邮箱，如果不正确返回对应错误。4、获取页面中的（换绑令牌：uniqid）获取失败则返回【换绑失败：解绑令牌不存在】5、将type、code、email、unbind_type、uniqid字段封装到unbind数组对象，然后执行ajax请求
11、后端邮箱换绑钩子xc_rebind_email_hook业务逻辑已完成封装，该钩子需要传递【rebind】数组。触发执行后会依次执行以下动作。1、检测rebind变量是否存在，如果不存在则直接返回【绑定失败：传递的参数异常】2、通过xc_is_login获取登录用户UID，如果用户未登录则返回【绑定失败：请登录后操作】3、检测rebind数组是否存在以下字段uniqid、email、code、如果有缺失则返回错误。4、创建redis缓存查询【unbind_email:' . $rebind['uniqid']】如果不存在缓存，则返回绑定失败：解绑令牌无效。5、通过xc_email_regular检测用户输出的邮箱账户是否有效，如果无效则提示【绑定失败：请输入正确的邮箱账户】6、使用xc_is_email_user检测邮箱账户是否绑定过账户，如果绑定则返回绑定失败：邮箱账户已绑定过账户。7、调用xc_sms_code_check_hook发起验证码检测，环境环境固定值为bind_email。如果效验失败则返回对应的错误。8、验证码效验成功将xc_verification_code数据表就能行回调处理。9、触发xc_binding_email_ok_hook回调动作，完成整个邮箱换绑请求。
12、修复一个表单异常BUG，具体表现为：当用户完成短信邮箱效验后会通过转场动画进入【换绑新邮箱、换绑新手机】的页面，用户点击获取验证码后，会进入有效的倒计时处理，但是倒计时结束后，验证码onclick事件会还原失败。造成该问题的原因是，上级转场页面没有移除DOM，导致页面同时存在多个验证码表单，回调恢复onclick事件是上一级有效。解决办法：xc_hook_email_code_ok、xc_hook_sms_code_ok两个钩子在处理倒计时，会通过last来锁定最后一个元素。倒计时只影响当前页面表单元素。
13、邮箱换绑操作成功后，后端动作：1、通过xc_notify_hook通知接口下发换绑消息【rebind_push】，type参数为邮件。2、触发回调动作：xc_binding_email_ok_hook，type参数为：rebind。在回调钩子中完成账户邮箱变更逻辑。前端动作：1、将user.is_login_email标记为true，标记用户已绑定邮箱账户。2、通过元素选择将当前页面的表单【onclick、text】元素进行修改或移除。3、将email_UID的文本、placeholder改为新邮箱地址。
14、邮件验证码场景模版新增配置：unbind_email，当用户需要换绑邮箱账户，可以通过验证旧邮箱进行换绑操作。该场景配置参数如下：每日最多接收5条，超过则当日不在发送。邮件验证码有效期300秒，超过时间自动失效。发送间隔60秒，不允许重复请求。邮件接收账户必须为账户绑定邮箱，如果未登录或未绑定邮箱则返回对应错误。

2024年4月21日
1、手机换绑页面【setting_ubbind_phone】新增一个自定义属性unbind_type 固定值「email：通过邮箱换绑、phone：通过手机号换绑」通过xc_hook_binding_phone钩子执行换绑验证时，会读取这个自定义属性 然后封装到binding.type 一并通过ajax发送到后端进行验证码效验处理。后端在执行验证码效验时，将通过这个变量决定phone这参数是读取用户邮箱还是手机号。
2、xc_hook_rebind_phone换绑请求，现在也能够正确识别和处理【邮箱换绑和短信换绑】两种场景。具体为：函数需要携带type变量，该变量固定为|sms:短信解绑/email:邮件解绑。并且函数内部会读取自定义属性unbind_type。这个属性固定值为email、phone。这两个参数都会封装到unbind数组，发送到后端处理。
3、xc_hook_binding_phone_ok钩子现在能够正确处理【邮件验证码换绑手机】的页面回调动作了，当成功换绑手机号后，用户所在页面会进行以下交互操作。1、锁定元素【phone_' + xc.user_id】，然后对这个元素进行文本和自定义属性placeholder调整，参数为换绑的新手机号。2、如果页面操作表单（换绑手机号）存在，那么将其onclick进行清空，防止用户二次点击。同时将按钮文本变更为【手机号换绑成功】。
4、宫论【手机号】首次绑定、短信换绑、邮件换绑三个场景的业务逻辑已完成封装，用户可以通过账户资料-我的手机号页面，进行相应的操作。手机号是一个账户的核心，涉及到账户（安全、通知）都会通过短信形式告知用户。正常情况下，用户注册账户都是必须强制绑定手机号，第三方登录需要完成绑定手机号才算完成注册流程。手机号换绑，目前途径有两种方法。1、手机号可用的状态，通过短信效验身份。2、手机号不可用状态，通过邮件效验身份。后续还会集成人脸识别处理方案。
5、新增资料设置页【/global/setting/email.php】页面唯一标识：setting_bind_email。用户可以通过这个页面对账户邮箱进行绑定或换绑操作请求，该页面具有唯一性。每个用户都只能访问自己的邮箱账户页，管理员也不能查看或修改用户的邮箱。邮箱账户在宫论账户体系中等于辅助手机号，如果账户手机号不可用，忘记密码。可以通过绑定邮箱进行重置或更换。
6、用户资料页【邮箱菜单】，如果已经绑定邮箱会通过xc_maskStringInRange脱密显示邮箱，如果未绑定则显示【点击绑定】。无论是否绑定 点击菜单都会跳转到【[xc_link type=global]/setting/email.php】页面。菜单添加唯一类名（email_Uid）当用户邮箱发生变动时，可以通过类名同时修改。进入邮箱绑定页 会提示简语【邮箱账户可以重置账户安全，强烈建议绑定】。
7、邮箱验证码场景新增配置【bind_email】用户首次绑定邮箱账户将通过该场景验证码来效验邮箱是否可用，具体参数如下：每日发送次数（5次）、邮件验证码有效期（300）秒，超过时间验证码自动失效。发送时间间隔（60秒），防止短时间内用户重复发送。用户绑定邮件账户(关闭)，首次绑定需要用户通过表单输入邮箱。登录用户才可用（启用）。
8、前端邮箱验证码发送请求钩子【xc_hook_email_code】已支持bind_email场景，当收到绑定邮箱请求会通过【.setting_bind_email .email #xc_bind_email】元素来获取输入表单邮箱账户，如果输入为空则返回错误【邮箱账户不得为空】，然后通过xc_is_email来检测邮箱账户是否有效，如果无效则返回【请输入有效的邮箱账户】。获取邮箱账户成功后，将触发ajax请求。
9、后端邮箱验证码发送钩子：xc_email_code_hook在处理绑定邮箱验证码，会额外追加拦截，通过xc_is_email_user检测邮箱是否已绑定其他账户，如果已被使用过则返回【邮件发送失败：邮箱已绑定其他账户】。邮箱绑定标题：（绑定账号邮箱请求）、正文内容：（尊敬的用户： 您正在绑定账户邮箱。您的验证码是：" . $code . " 请在邮箱绑定页面输入此验证码以继续操作。如果您并未请求绑定邮箱，请忽略此邮件。 此致 系统自动发送，请勿回复。） 注：绑定邮箱验证码，不会检测账户是否已绑定邮箱。是因为换绑场景也会用到这个短信场景，如果拦截。会导致换绑的场景无法执行，处理方案是。在执行绑定更新的时，进行安全效验！
10、xc_maskStringInRange脱密加星方法进行优化，在执行字符串脱敏处理前 会通过xc_is_admin_x方法来效验用户身份，如果对方属于前台管理员（包含超级管理员）那么将直接输出原字符 跳过脱密处理。注：管理能够看到用户完整【手机号、身份证、邮箱】等信息，方便联系或管理用户。
11、前端新增钩子xc_hook_binding_email:绑定或解绑邮箱账户，该方法需要传递固定变量【status| add:绑定/cut:解绑】该方法通用拦截事件为：1、通过xc.is_login检测用户是否登录，如果未登录则执行xc_login请求。2、status：add(绑定请求)检测页面是否包含元素（setting_bind_email）不包含则提示页面参数异常，通过user.is_login_email检测用户是否已绑定邮箱，已绑定则提示【账户已绑定邮箱账户】。3、从当前表单中获取email和code，并对其进行检查。如果不是有效邮箱或者为空则返回对应错误。完成上述基础检测后，发起ajax请求。
12、新增后端钩子：xc_binding_email_hook，负责账户邮箱解绑或绑定业务逻辑的处理。该钩子返回标准的数组结构：code=0代表操作成功、code=1代表处理失败（原因有多种、比如权限问题、参数问题、安全问题、效验错误），msg会给出错误说明。该钩子需要传递一个数组变量【binding】包含以下字段：code：验证码参数、email：处理的邮箱账户（换绑场景为空）、type：短信场景，负责区分来源。
13、邮箱绑定请求，后端业务处理流程如下。1、效验binding是否为数组，如果不是则返回错误【处理失败：传递的参数异常】2、通过xc_is_login获取当前登录用户，如果用户未登录则返【处理失败：请登录后操作】3、检测变量字段【code、email、type】是否有缺失，如果存在缺失返回【处理失败：传递的参数异常】4、通过xc_is_login_email检测用户是否绑定了邮箱，如果已绑定则会返回【绑定失败：账户已绑定过邮箱账户】5、通过xc_email_regular检测绑定的邮箱是否有效，如果无效则返回【绑定失败：请输入正确有效的邮箱账户】6、通过xc_is_email_user查询邮箱是否绑定过账户，若是绑定过则返回【绑定失败：该邮箱已绑定过账户】7、通过xc_sms_code_check_hook效验验证码是否可靠有效，如果无效返回对应的错误。8、如果验证码有效则回调xc_verification_code数据表记录。9、返回前端：邮件绑定成功。
14、新增回调动作钩子：xc_binding_email_ok_hook当邮件绑定/换绑成功后会触发。该钩子会携带数组变量binding，必定存在两个字段：type|rebind:换绑/bind:首次绑定、email：绑定的邮箱账户。该钩子会执行两个通用事件1、xc_logout_session_hook强制当前账户其他设备离线，换绑邮箱账户涉及到安全行为，需要用户重新登录。2、通过系统方法wp_update_user更新用户邮箱账户。

2024年4月20日
1、后端手机号换绑操作钩子：xc_rebind_phone_hook已完成封装，该钩子需要传递【rebind】数组，必定包含字段【type：固定值sms短信验证换绑、email邮件验证换绑。phone：换绑的新手机号、code：换绑的验证码参数、uniqid：解绑令牌，完成短信或邮件验证后生成。】该钩子返回标准的数组结构，code=0代表处理成功 code=1代表处理失败，msg是错误详情。
2、xc_rebind_phone_hook的拦截处理流程如下。1、检测rebind变量是否为数组，如果不是返回错误【绑定失败：传递的参数异常】。2、通过xc_is_login检测用户是否登录，如果未登录则返回错误【绑定失败：请登录后操作】。3、效验rebind是否存在uniqid、phone、code三个字段，如果有缺失则返回【绑定失败：核心参数缺失】。4、读取redis缓存【unbind_phone:uniqid】解绑令牌缓存，如果读取失败则返回【绑定失败：解绑令牌无效】。令牌有效期是10分钟。5、通过xc_phone_regular效验绑定的手机号是否是国内号码，如果不是则返回【绑定失败：请输入正确的手机号<br>注：目前仅支持国内手机号码段】。6、通过xc_is_phone_user检测手机号是否绑定过账户，如果绑定过则返回【绑定失败：该手机号已绑定过账户】。7、执行验证码效验xc_sms_code_check_hook，消息场景为（bind_phone）如果效验失败，则返回对应错误。8、回调xc_verification_code数据表，将短信验证码标记为0K。9、返回前端code=0、效验操作结束。
3、全局push通知管理新增配置【rebind_push：邮箱短信换绑提醒】，当用户成功换绑了邮箱或手机账户，会通过对应的钩子触发。提醒用户 账户已完成换绑。该通知类型为（账户安全类通知）同时开启【手机短信、公众号模版消息、APP通知、服务号消息、邮件】五种消息场景下发。短信限制每日3条、邮件和模版消息限制5条。
4、用户换绑成功短信模版ID：2133448。文本模版【 尊敬的用户，您的账户已成功进行了{A}操作，新关联的信息为：{B}。为了您的账户安全，请确认这是您本人的操作。】在这个模板中，{A}可以是“手机号换绑”或“邮箱换绑”，{B}则是换绑的手机号或邮箱账户。这样，当用户账户更换了手机号或邮箱时，就可以使用这个模板来短信提醒对方。
5、通过xc_rebind_phone_hook执行手机号换绑操作时，如果验证码效验通过后将会同时触发两个钩子：1、xc_notify_hook（换绑成功通知钩子：rebind_push）钩子的push_data数组会传递四个变量过去，分别为（ip、ua、fingerprint、type）其中type固定值为手机号。因为换绑通知可能是手机也可能是邮箱，需要传递变量进行识别。2、xc_binding_phone_ok_hook：绑定成功回调钩子，会传递【rebind】数组。负责后续的缓存更新，用户手机号更新动作。注：这两个钩子的执行优先级是通知第一、回调第二。并且通知采用同步执行，而非异步。这样就可以做到短信邮件下发的是旧手机号码，而非新绑定的。
6、统一消息发送接口xc_notify_hook，已完成对【rebind_push：账户换绑通知】的封装处理。固定标题title：【XX换绑提醒】、固定内容content：【当前账户xxx，已变更为：xxxxx】邮件模版【尊敬的用户，您的账户已成功进行了' . $push_data['type'] . '操作，新关联的信息为: ' . $push_data['value'] . '。为了您的账户安全，我们强烈建议您确认这是您本人的操作。如果这不是您本人的操作，那么您的账户可能已存在安全问题，请尽快与我们联系！谢谢，】。宫论服务号消息会额外显示【更换时间、操作设备】两个菜单。
7、通过短信sms完成账户手机号换绑操作后（后端返回code=0）会立即触发xc_hook_binding_phone_ok前端回调钩子，钩子现在接收两个变量【1、unbind：里面包含phone、code等参数属性。2、type：固定值为：rebind（换绑操作）、bind：首次绑定】。无论是首次绑定还是换绑操作，只要操作成功都会触发。不同的业务可以通过type来区别处理。
8、安全考虑，当账户完成手机号绑定（包括初次首次绑定、换绑手机）会通过xc_binding_phone_ok_hook钩子来执行【xc_logout_session_hook事件】强制其他设备离线。相当于绑定手机号成功后，除当前设备外 其他设备在线账户都会强制注销会话，需要对方重新登录。这是处于账户安全考虑，手机号是账户非常重要的一部分，当发生变更的时候，需要重新效验账户安全。注：xc_binding_phone_ok_hook钩子现在可以通过$binding['type']来效验来源，rebind:换绑成功/bind:首次绑定。
9、资料设置页面：用户手机号value菜单新增自定义类名：phone_用户UID。手机号绑定页面，用户手机号表单新增自定义类名：phone_用户UID。当完成手机号绑定或者换绑业务，会通过这个类名来进行手机号变动调整。调整范围包括【text、attr】两个属性。后续如果有展示用户手机号的地方，也都会插入这个类名。这样可以做到全局回调处理。
10、安全隐私考虑，用户的邮箱账户现在也是脱敏显示。涉及到邮箱账户输出的地方，都通过xc_mask_email方法来处理。该方法会将邮箱地址中的一部分字符替换为星号，以保护用户隐私。具体表现为：函数将保留邮箱地址的前四个字符和域名部分，而将@符号之前的其他字符替换为星号(*)。如果输入的不是有效的邮箱地址，函数将返回原始输入。示例：examp*****@test.com。
11、xc_maskStringInRange方法进行重构处理，start和end两个变量现在是可选参数。该函数现在能够自动识别【邮箱、手机号、身份证】三个中内容，如果是这三种内容则会采用内部方法进行脱敏处理。1、如果输入的字符串是有效的邮箱地址，会保留邮箱前四个字符和域名部分，其余替换为星号【输出: examp*****@test.com】2、如果输入的字符串符合手机号格式，会脱敏中间四位数字【输出：138****8000】3、如果输入的字符串符合身份证号格式，会脱敏除了最后四位之外的所有数字。【1234**********5678】。以后执行脱敏处理，以上三种类型不需要指定前后位置星号。
12、邮件验证码场景模版新增配置【邮件换绑手机号：unbind_phone】具体参数如下：每日发送次数（5次）、邮件验证码有效期（300秒）、发送间隔时长（60秒）、用户绑定邮件账户（开启）、登录用户才可用(开启)。当用户手机号不可用状态（停机、注销、丢失）等情况，允许用户通过邮件验证码来执行手机号更换的操作。注：因为邮箱具备重置密码、更换手机号的能力。所以邮箱的重要性和手机号保持一致，相当于辅助手机号，其邮箱的隐私保护、安全性需要和手机号对等设计。
13、xc_email_code_hook邮箱发送场景已集成【unbind_phone】验证码的处理，当用户在邮箱换绑手机页面尝试通过【邮箱换绑手机号】，会通过该函数下发一封邮件【标题：手机号换绑请求。邮件正文：（尊敬的用户： 您正在换绑账户手机号码。您的验证码是：" . $code . " 请在邮箱换绑手机页面输入此验证码以继续操作。如果您并未请求换绑手机号，请忽略此邮件。 此致 系统自动发送，请勿回复。）】
14、邮件验证码增加两个安全优化：1、通过邮箱验证码重置账户时，会通过xc_is_email_user效验邮箱绑定账户。如果绑定账户不存在或不等于前端用户参数则返回错误。拒绝重置请求，防止出现安全问题。2、通过邮箱验证码请求换绑手机号时，会通过xc_is_login_phone检测当前用户是否绑定了手机号，如果未绑定则返回【邮件发送失败：账户未绑定手机号】。

2024年4月19日
1、setting_bind_phone（手机号绑定页面），如果用户已绑定手机号将显示以下内容。【1、脱敏显示用户已绑定手机号（136****5953）隐私保护，不管什么情况 都不会完整显示手机号。】2、显示平台关于换绑手机号的方法【您已经成功绑定了手机号码，如果有需要更换号码的需求，我们有一套安全的验证流程来保护您的账户安全。如果您的原手机号仍然可以使用，我们会通过发送验证码的方式，让您获取解绑的短信，之后，您就可以绑定新的手机号了。如果您的手机号无法使用，但您的账户已绑定了邮箱，那么您也可以通过邮箱来完成手机号的解绑操作。在最复杂的情况下，比如您的手机号和邮箱都无法使用，但如果您的账户已经完成了实名认证，我们仍然有一个备选方案：使用人脸识别技术来完成解绑流程。】
2、绑定手机号页面，会通过xc_is_login_email来获取用户邮箱、xc_is_login_idcard获取用户实名信息。如果用户已绑定手机号 则会默认输出底部菜单【通过手机短信进行换绑】。如果用户绑定了邮箱则额外显示【通过邮箱账户换绑手机号】菜单。如果用户已进行了实名认证，则还会显示【使用人脸识别换绑手机号】菜单。
3、新增页面：setting_ubbind_phone（换绑手机号），该页面需要通过GET来传递unbind_type变量（固定值：phone，通过原来短信验证码来换绑手机号。email，通过邮箱账户来换绑手机号）。进入该页面后会通过xc_is_login来获取登录用户，如果未登录则直接返回错误。同样的如果传递的email，但是用户未绑定邮件一样会返回错误。注：用户可以通过这个页面来执行手机号换绑操作。（注:手机号只能换绑，不能进行解绑）
4、手机号换绑页面已集成【xc_order_access】访问拦截事件，检测标识：setting_ubbind_phone，检测变量：$unbind_type。以下三种情况的页面访问会被拦截并跳转到403错误页面。1、如果用户未登录，则禁止访问。2、unbind_type等于phone，但是用户未绑定手机号则拦截。3、unbind_type等于email，但是用户未绑定邮箱账户则拦截。
5、宫论短信场景新增配置【手机号解绑验证码：unbind_phone】，用户通过短信方式来换绑账户手机号时会触发这个场景。短信模版ID：（1646861）、短信模版文本：（您正在修改账户手机号码，验证码为：{1}，为保障帐户安全，请勿向任何人提供此验证码。）。每日发送次数：5次、短信码有效期：300秒，发送间隔限制：60秒。短息发送来源为用户绑定手机号（是）、登录用户才可用该消息场景（是）。
6、手机号换绑页面采用下一步操作方式，在执行换绑前需要先效验旧手机号（此处号码依旧脱敏显示），如果旧手机号短信验证成功 则会生成一个有效期为N分钟的秘钥。然后进入下一步，新号码的绑定业务逻辑处理。新号码效验的时候后端将检查秘钥是否安全可靠，如果可靠则允许对方进行换绑操作。为了防止页面冲突，新旧号码的验证表单分别命名为【ubbind_phone_old、ubbind_phone_new】。
7、unbind_phone账户换绑验证码发送业务逻辑已完成封装，前端通过xc_hook_sms_code发送验证码前，会检查用户是否处于换绑页面（元素：setting_ubbind_phone），如果不处于则返回错误。后端在收到换绑请求验证码后，会效验账户是否已绑定手机号，如果未绑定则返回对应错误。以上两个前后端拦截属于短信场景追加，通用拦截规则依旧保持不变。
8、后端钩子：xc_binding_phone_hook 已完成换绑手机号的业务封装。用户通过前端业务提交换绑请求，钩子会依次执行以下动作处理。1、检测用户是否处于登录状态（换绑必须为本人，且处于登录状态才能完成）。如果未登录则提示【处理失败：请登录后操作】。2、检测传递的数组是否以下字段【code：验证码、type：短信场景】，如果不存在则提示【换绑失败：传递的参数异常】。3、通过xc_is_login_phone来获取当前用户手机号，如果获取失败则提示【换绑失败：账户未绑定过手机号】。4、通过xc_sms_code_check_hook进行验证码校队，如果不通过则返回对应错误，如果通过则回调xc_verification_code数据表记录。5、返回code=0，前端响应换绑验证码通过。
9、新增redis缓存【unbind_phone:令牌秘钥】，当用户通过效验了换绑验证码后 会通过uniqid函数来生成唯一秘钥（毫秒级），并将其封装成于token数组。token除了uniqid秘钥参数外，还包含（user_id：换绑用户、time：操作日期时间、phone：换绑的手机号信息）。数组会写入到redis缓存键位，有效期为600秒（10分钟）。返回前端的响应结构体也会同步返回（uniqid）字段。注：这个缓存是后端鉴权的关键步骤，在后续的新手机号效验过程中，会通过这个秘钥来判断用户是否有权限执行换绑操作。
10、前端新增钩子：xc_hook_ubbind_phone，处理换绑手机号请求。需要传递变量type（固定值为：email通过邮件验证码来完成换绑操作、sms通过短信验证码来完成换绑操作）后续还会接入real：通过实名认证方式来完成换绑操作。手机号换绑涉及账户安全处理，需要做很多安全拦截处理。因为支持的换绑方式有多个，为了业务的可靠性 前后端都需要封装一个钩子来处理换绑请求。
11、xc_hook_binding_phone在完成换绑短信验证码的效验后，会依次执行以下页面交互。1、通过removeClass将【xc_get_code_1】移除，并通过addClass将其改为【xc_get_code】2、使用fadeOut和fadeIn过长动画来处理（隐藏：unbind_phone_old旧手机号验证表单、显示：unbind_phone_new新绑定手机号表单）。3、如果后端的数据返回存在字段uniqid，则在setting_ubbind_phone元素后面追加自定义属性（uniqid）。4、页面提示【效验成功，可以绑定新手机号】。
12、手机号换绑页面现在采用动态标题，如果unbind_type=phone则默认显示：手机换绑验证码、如果是email则默认显示：邮箱换绑验证。当用户完成了旧手机或邮箱的验证码效验后，则标题会通过jquery来做动态调整，比如短信效验成功后，页面会通过xc_hook_binding_phone事件调整为【换绑新手机】。邮箱的动态标题后续也是一样的调整。注：为了避免页面冲突，动态调整标题时会通过：last来选择最后一个符合元素。
13、换绑新手机的验证码与新绑定手机验证事件为同一个【都是通过：bind_phone】短信场景来处理。两者的后端处理逻辑保持一致，唯一的区别在于前端钩子：xc_hook_sms_code会进行元素判断，通过检测【setting_unbind_phone】来判断是新绑定还是换绑。如果是换绑则手机号通过setting_bind_phone .phone.bind .xc_phone_number表单获取，并且会尝试获取uniqid页面自定义属性，如果获取失败则直接返回【获取失败：换绑手机令牌不存在】。注：因为换绑手机的时候，账户必定绑定手机号。因此后端【bind_phone】短信效验场景移除了xc_is_login_phone的处理。获取绑定验证码不在验证是否已绑定手机号。不过首次绑定xc_binding_phone_hook的钩子逻辑，依旧会效验账户是否绑定手机号。防止出现重复绑定。
14、前端换绑手机号请求事件xc_hook_unbind_phone完成短信封装，当收到sms请求解绑后。会依次执行以下动作。1、通过xc.is_login检测用户是否处于登录状态，如果不处于则触发xc_login。2、检测页面元素setting_unbind_phone是否存在，如果不存在则提示【换绑错误：页面元素不存在】。3、获取页面的新手机号和验证码，如果获取失败或则为空则提示【验证码手机号不能为空】4、通过xc_is_phone效验用户的手机号是否为国内号码不是则提示【请输入正确的手机号<br>注：目前仅支持国内手机号码段】。5、获取页面元素是否存在解绑令牌uniqid，如果不存在则提示【换绑失败：解绑令牌不存在】。6、将上述参数封装到unbind数组对象，然后通过ajax发送到后端处理。

2024年4月18日
1、xc_update_password_hook账户密码重置钩子优化，在通过wp_set_password完成账户密码重置工作后，系统会强制所有设备离线。但是这个逻辑与设计逻辑不通，重置账户密码的设备应该保持在线才对。因此在完成重置钩子执行前，会通过xc_is_login获取当前UID，如果操作用户与当前用户是同一人，则立即通过wp_set_auth_cookie来恢复用户的登录状态。
2、短信场景模版新增配置【bind_phone】使用场景：手机号绑定验证码。模版ID（2130785），文本示例【您的验证码：{1}，这是您绑定手机号的操作验证码，如果这不是您本人的操作，请忽略本短信！】。每日发送次数6次、短信验证码有效期：300秒、发送间隔时长（60秒）。用户绑定手机号（关闭：首次绑定手机号，用户必定未绑定）。登录用户才可用（开启，仅限登录用户触发该短信场景。）
3、手机号绑定页面优化处理，页面标识变更为【setting_bind_phone】，该页面user_id通过【xc_is_login】来获取，为了确保安全可靠，用户只能访问自己的手机号绑定页面，管理员也不能修改或绑定用户号码。在绑定页面，用户的手机号获取方式不在通过get_user_meta来读取phone字段，而是通过xc_is_login_phone方法来赋值。规范化整个页面变量。
4、xc_sms_code_hook已支持（bind_phone：绑定手机号）验证码场景，当收到该类型的验证码请求后，函数会在原有拦截机制下 额外执行以下两个拦截检测。1、通过xc_is_login_phone检测当前用户是否已绑定手机号，如果已绑定则返回【短信发送失败：账户已绑定手机号】。2、通过xc_is_phone_user效验手机号是否已绑定其他账户，如果已绑定则提示【短信发送失败：手机号已绑定其他账户】。
5、新增前端钩子:xc_hook_binding_phone()，需要传递变量（status）固定值为（add：绑定手机号验证、cut：解绑手机号验证）。为了方便维护，绑定和解绑事件封装到一个钩子事件中处理，根据变量参数来执行不同的效验处理的。注：后端也是采用统一钩子来处理绑定和解绑请求，操作成功回调也是一样。
6、xc_hook_binding_phone已完成【status：add】绑定手机号的业务封装，当收到手机号绑定请求，会依次执行以下检测。1、检测页面是否存在元素【setting_bind_phone】，如果不存在则返回【页面参数异常】。2、通过user.is_phone检测用户是否绑定手机号，如果等于true则返回【账户已经绑定手机号】。3、通过find元素选择器获取页面中的手机号表单和验证码表单。4、通过xc_is_phone来验证用户输入手机号是否有效，如果无效则返回【请输入正确的手机号<br>注：目前仅支持国内手机号码段】。5、创建binding对象，将【status、code、phone】三个属性封装到其中。然后发起ajax请求，到后端处理业务。
7、新增后端钩子：xc_binding_phone_hook，需要传递binding【数组对象，包含绑定解绑手机号的各项参数，比如手机号、验证码、短信场景】该钩子全局拦截事件有：1、binding如果为空或者不等于数组则返回错误【处理失败：传递的参数异常】。2、通过xc_is_login获取登录用户，如果获取失败则返回【处理失败：请登录后操作!】会同步返回jump=login。该钩子返回标准的数组结构。code=1代表操作失败、msg是失败详情。code=代表操作成功（解绑或绑定成功）。
8、账户【解绑/绑定】手机号钩子已完成绑定手机号的业务封装，当收到status=ADD的请求 会依次执行以下效验。1、检测数组是否存在code、phone、type三个字段，如果不存在则返回【处理失败：传递的参数异常】。2、通过xc_is_login_phone检测当前用户是否绑定手机号，如果已绑定则返回【绑定失败：账户已绑定过手机号】。3、通过xc_phone_regular正则检测提交的验证手机号是否为国内手机号，如果不是则提示【绑定失败：请输入正确的手机号<br>注：目前仅支持国内手机号码段】。4、通过xc_is_phone_user检测手机号是否绑定过账户，如果绑定则提示【绑定失败：账户已绑定过手机号】。5、通过xc_sms_code_check_hook执行验证码是否有效，如果验证码效验失败则返回对应错误。6、验证码效验成功，则回调xc_verification_code数据表对应记录，将其状态标记为OK。7、通过update_user_meta更新用户的手机号，完成绑定流程。8、返回code=0msg=绑定手机号成功。
9、后端增加回调钩子：xc_binding_phone_ok_hook，当用户手机号解绑或绑定成功 会触发这个回调钩子，会传递【binding】数组变量，可以根据binding[status]来判断是解绑请求还是绑定请求。这个钩子可以做一些内部事件的处理，比如手机号缓存更新、push通知等。绑定手机号的update_user_meta动作也通过这个回调钩子来完成。
10、前端同样新增回调钩子：xc_hook_binding_phone_ok，当【解绑或绑定手机】后端响应操作成功后会直接触发这个钩子。同意会传递【binding】数组变量，可以根据binding[status]来判断是解绑请求还是绑定请求。注：当响应为（add）会执行以下动作。1、将user.is_phone标记为true，在不刷新的页面情况下，告知所有业务 当前用户已完成手机绑定。2、触发提示【手机号绑定成功】。3、回调上级页面菜单元素【.xc_user_setting .phone span.value】将文本变更为本次绑定的手机号。4、延迟1.5秒，发生后退行为。
11、为了方便后续业务的接管，当用户执行手机号解绑或绑定操作成功后会通过xc_do_action来挂载动作钩子，挂载位置函数（xc_binding_phone_ok_hook），这个属于预留回调钩子，如果有接口或业务需要触发绑定和解绑手机号的事件，可以通过对应的回调机制，来接入到这个函数。这样当触发xc_binding_phone_ok_hook钩子时，会将对应的变量参数同步过去并执行。
12、xc_sms_code_hook钩子优化，短信超速拦截处理顺序进行调整。现在是在基础拦截效验结束后才会执行超速检测，具体标识为：如果未登录、手机号错误、获取次数超过限制、特定场景拦截规则，都不会触发超速锁的触发，只有上述通用拦截规则完成效验后，准备执行xc_phone_push消息下发时才会触发上锁处理。并且xc_phone_push下发短信失败后会立即释放锁。经过这样的处理可以避免，手机号登错误的情况，也要等待XX秒才能重新获取。
13、xc_user_setting（用户资料）页面优化处理：进入后会赋值以下五个变量。1、admin：管理员身份效验，通过xc_is_admin函数来获取。2、user_id：当前访问用户，通过xc_is_login来获取。3、phone检测用户对象是否已绑定手机号，通过xc_is_login_phone来获取。4、email：检测用户对象是否已绑定邮箱，通过xc_is_login_email来获取。5、weixin：检测用户对象是否绑定微信登录，通过xc_is_login_weixin来获取。注：资料页面需要区分以下三个场景（1、用户访问自己的资料页面，用户查看别的用户资料页、管理员访问其他用户资料页）

2024年4月16日
1、push通知接口，已完成【lnsecure_login：账户异地登录报警】的通知处理。通用标题：（⚠️ 账户异地登录提醒）正文：（登录地点：' . $data['city'] . '，如不是本人登录行为，账户可能已出现安全问题。）。邮件正文：（尊敬的 您的账户疑似在以下地点异地登录： 登录地点：' . $data['city'] . ' 登录IP：' . $data['ip'] . ' 登录设备：' . xc_get_phone_brands($data['ua']) . '如果这不是您本人的操作，您的账户可能已出现安全问题。请您尽快修改重置密码，确保账户安全。）。默认LINK链接【home：首页】。异地登录提醒，五个消息场景都开启通知。
2、考虑到异地登录提醒、重置密码通知 都是异步执行，无法获得客户端信息（IP、UA、城市）。因此在执行xc_notify_hook推送前，会提前捕获客户端IP、UA、指纹等参数 然后封装到push_data变量中。在异地执行推送请求的时候，可以通过检测push_data这个数组，来获取对应参数。然后对其进行解析处理。注：push_data是固定存在数组的，变量参数不固定，但是IP、ua、fingerprint这三个必定会存在的。
3、xc_login_hook用户登录钩子新增白名单机制，当登录请求来源属于白名单类型则默认视为安全。在完成登录效验后会通过xc_update_security对设备指纹进行安全同步更新，目前以下三种方式登录是安全可靠的（1、短信验证码登录。2、APP一键登录（通过手机号鉴权操作）。3、APP端：微信登录请求）其它登录均视为不安全。
4、异地登录报警机制全部重构，现在支持用户手动开启和全局强制开启。通知下发通过PUSH异步请求来执行【lnsecure_login】，短信和邮件的发送频率限制也由通知场景来控制。因为全局支持开启，所以判定异地登录的方式做了优化。不在单纯通过指纹来效验是否安全可靠，而是结合白名单登录来做双重效验。减少非必要的通知。（注：白名单登录、指纹、城市。三重要素都匹配失败的情况下，才判断并且标记为异地。）
5、很多场景需要效验用户user_id是否存在对象，每次都通过get_userdata之类的方法来查询存在性能耗损。因此封装一个is语法来处理效验用户是否存在【xc_is_user】，该方法具有缓存特性，不会重复执行sql请求。具体执行流程如下。1、通过is_numeric检测传递的用户UID是否为数字，如果不是则直接返回false。2、创建redis缓存键：【is_user:' . $user_id】，然后读取它，如果存在缓存则说明用户存在，直接返回true。3、如果读取缓存失败，则通过wpdb的get_row来查询users数据表是否有对应用户，如果查询成功，则更新缓存（有效期30天），并返回true。如果查询失败则直接返回false。
6、找回账户页面，右上角新增一个客服图标（引导用户进入客服中心），用户如果对账户存在疑惑可以通过客服中心来寻得帮助。同时该页面底部的两个找回接口【通过人工申诉找回账户、通过人脸识别找回账户】绑定临时onclick提示【接口尚未开放，等待集成中】。注：申诉找回账户和人脸识别涉及的业务很深，目前没有精力去集成。暂且搁浅一边，后面在回过头来集成。
7、宫论账户找回功能暂且集成完毕，在登录页面，用户可以点击忘记账户（菜单），进入账户查页。通过输入（手机号、邮箱、身份证）来查找关联绑定账户。如果查找到对应账户，会进入账户找回页面，在找回页面会显示账户找回相关提示，并且展示用户相关信息（其中：身份证、手机号）会脱敏显示。如果绑定手机号、则可以点击手机号进行短信登录。如果绑定了邮箱，点击可以进入邮箱重置密码页面。如果上述两种方式都无法登录重置，那么将会根据账户资料情况显示【人工申诉、人脸识别】菜单，然后用户可以选择对应方式来找回或申诉关联账户。注：申诉和人脸后面才会集成，同时账户找回接口是具有安全拦截性质，短时间内只能使用X次，超过次数自动风控拦截。
8、页面密码输入表单，点击图标监听事件（显示密码和隐藏密码）优化处理，在触发click事件时 会检测是否存在上级监听（重复加载多个页面，产生多个表单监听）。如果存在则使用 .off('click') 来移除已经存在的点击事件监听器，然后再添加新的监听器。这可以确保每个元素上只有一个点击事件监听器，避免了重复触发的问题。
9、新增css通用类名：grey。页面背景色background默认是白色，如果需要浅灰色则加入这个类名，即可将色调变更为浅灰色，调整位置为【.page-content.grey】。账户资料设置-密码重置页进行重构处理，防止出现冲突和安全，管理员也无法修改别人的的密码。同时操作页面标识调整为【setting_update_password】
10、短信场景模版新增配置【账户密码重置验证码】，唯一标识：update_password。短信ID：1646866。短信模版文本（您的验证码为：{1}，您正在进行密码重置操作，如非本人操作，请忽略本短信！）。每日发送次数（6次）、短信验证码有效期：300秒、发送间隔时长：60秒、用户绑定手机号（强制开启，接收验证码的短信必须为用户绑定手机号）、登录用户才可用：（强制开启：必须登录用户才能发起该场景验证码请求）。
11、登录安全设置页：xc_login_security，新增一个头部提示，告知用户登录限制的失效机制。具体文字为：【你可以对账户进行一些登录限制，但是账户进行【密码重置或解除冻结】时，系统会重置并删除这些登录限制和地区锁定。这是为了确保你在执行这些操作后能够顺利地访问自己的账户，而不会受到之前设置的限制的影响。】
12、xc_hook_sms_code：短信验证码获取钩子已支持密码重置（update_password）验证码的处理逻辑，在提交验证码前会先验证用户是否已设置账户新密码，如果未设置则提示【获取验证码前，请先填写新密码】。如果已输入，则效验两次密码是否一致，如果不一致则提示【两次输入的密码不一致】。符合条件的情况下，则触发ajax请求，通过后端情趣发送验证码（后端会进行一系列的安全拦截检测），在符合条件的情况下才会执行短信发送请求。完成短信发送请求后，页面会通过xc_hook_sms_code_ok钩子执行参数回调，将获取验证码表单设置为倒计时，并在倒计时完成前移除点击事件。
13、短信重置密码事件已完成封装（xc_sms_update_password）当用户获取验证码后，可以通过右上角【修改】文字来触发该事件，发起密码重置请求。会依次执行以下动作。1、通过is_login来检测用户是否登录，如果未登录则触发【xc_login】登录事件。注：短信重置密码必须用户已登录的情况再操作。2、通过元素选择器setting_update_password，检查用户是否处于密码重置页，如果不处于则视为非法请求。如果处于则将页面元素存储于content，方便后续的操作。3、获取两个密码输入表框，如果未填写 或填写密码的不一致则触发提示。4、获取验证码，如果获取失败则提示错误。5、完成上述前端效验后，将所有的变量封装到update数组对象中，发起ajax请求到后端。
14、后端已完成【xc_sms_update_password】的事件处理，当收到短信密码重置请求时，后端会依次执行以下动作。1、通过xc_is_login获取当前用户UID，如果获取失败则返回【请先登录后再操作！】，并额外返回字段【jump=login】。2、检测update数组是否存在code、password字段，如果不存在正则返回【密码重置参数不完整】。3、通过xc_is_password对密码变量进行检测，如果不符合规范则返回错误。4、通过xc_is_login_phone获取用户手机号，如果获取失败，则返回错误。5、通过xc_sms_code_check_hook发起验证码效验，如果效验不通过则返回错误信息。6、如果验证码效验通过则触发钩子xc_update_password_hook（密码重置请求）。7、回调xc_verification_code验证码数据表，将验证码状态标记为OK。8、返回code=0，告知前端 密码重置工作已完成。9、前端页面，收到密码重置成功请求，触发提示【账户密码重置成功】。延迟1.5秒发生后退行为、将修改按钮的onclick事件移除，防止二次操作。

2024年4月15日
1、xc_push_app_hook、xc_email_push、xc_phone_push、xc_gzh_push四个接口都已支持异步处理方案，函数都已集成新变量【asyn：默认值false】 如果需要异步来处理消息下发，只需要将该变量标记为true即可。函数会自动通过xc_asyn_execution进行请求转发，确保业务能够在异步中完成完成处理。注：服务号不涉及外部接口处理，因此不需要执行异步来处理。
2、至此，宫论统一消息下发接口【xc_notify_hook】已完成封装处理，该接口将负责以下场景【账户安全、资金变动、淘货订单、拍卖订单、鉴定订单、寄售订单、系统通知、审核通知、社交互动】的消息都将通过新版方法来处理。新版接口支持五种消息下发，可以根据消息场景来决定开启或关闭指定通知渠道【短信、公众号、APP、服务号、邮件】。每种消息渠道的下发都有数据表记录关联，也可以通过总表来追踪消息的投递情况（失败或成功都有记录）。并且支持异步或同步执行，可以根据实际使用场景决定函数的执行方式。注：新版通知系统 非常强大，但是配置也非常繁琐 每种通知都需要花费很多心力去做参数适配。
3、服务号消息短代码【xc_shortcodes_service_card】优化：如果通知的link属性存在，但是获取的值等于home_url（当前网站域名）则会对其进行过滤处理，不显示【>查看详情<】底部菜单。避免用户点击触发菜单触发页面刷新动作。注：指定内页跳转不包含对首页跳转，如果传递的首页需要进行过滤处理。
4、websocket接口优化参数接收方式：现在能够同时处理HTTP POST 的两种数据【JSON 数据、表单数据】。首先会使用file_get_contents("php://input") 从 HTTP 请求的主体中获取原始数据。接下来使用 json_decode 函数将其转换为 PHP 数组。如果获取失败 则通过表单数据来获取对应的参数。该接口固定两个参数【client_id、message】如果获取失败，也会直接返回对应错误。注：接口优化是适配（xc_post请求）该请求目前默认仅支持json数据包，因此接受参数的方式要兼容处理，同样存在的问题，可能是有支付回调。
5、通过xc_service_push下发的服务号通知，现在能够正确响应触发【在线弹窗通知】啦。之前不触发主要是两个问题引发的 1、websocket接口因为xc_post函数重构 导致参数无法捕获。2、xc_wss_user下发的消息，因为头像昵称存在HTML，破坏了原有的json结构体，导致前端websocket.JS解析出现错误。第二个问题触发非常频繁，因此这里做规范化处理，变量都需要通过htmlspecialchars转义处理。
6、后端HOOK宫论统一封装脚本（新增函数代码【文档+注释】更新）：1、保存用户备注信息：xc_save_user_remark_hook($save)。2、用户APP启动钩子，当APP启动时触发。xc_app_onLaunch_hook($data)。3、xc_user_visits_hook($visits)用户来访【首页访问】钩子，主要负责浏览器指纹事件，每次刷新页面都会触发。4、xc_sms_code_hook($type, $phone = '')处理短信验证请求，用户短信验证码发送必须通过这个钩子来执行。5、xc_sms_code_check_hook($type, $phone, $code) 检查短信/邮件验证码的有效性，与获取短信验证码结合使用。6、用户统一注册钩子：xc_reg_hook($reg)，所有的注册请求，都必须要通过这个钩子来处理。7、用户注册成功钩子：xc_reg_ok_hook($type, $user_id)注册成功后，会自动回调这个钩子，负责字段更新，通知等。8、忘记账户-查找账户钩子：xc_find_account_hook($username)，允许通过手机号/邮箱/身份证来查找关联绑定用户。9、处理邮件验证码请求：xc_email_code_hook($type, $email = '')，用户邮箱验证码发送必须通过这个钩子来执行。10、重置账户密码（不进行安全效验）：xc_update_password_hook($user_id, $password = '')，账户密码修改或重置钩子。11、统一消息发送接口（系统通知）xc_notify_hook($user_id, $type, $data = '', $asyn = false)，宫论核心接口-push消息的通知下发处理。
7、 前端HOOK宫论脚本（新增函数代码【文档+注释】更新）：1、保存用户备注钩子函数：xc_hook_save_user_remark(author_id)，通过该方法修改指定用户备注信息。2、用户备注修改成功回调钩子：xc_hook_save_user_remark_ok(save, id)，备注修改成功了，页面交互回调操作。3、自定义WeUI通知：xc_hook_weui_notification(),这个弹窗适用于系统通知，比如权限状态、发货信息等等。4、APP初始化动作已经完成回调钩子：xc_hook_app_plus()，此事件触发时，PLUS已完成装填。APP可以执行一些列交互动作。5、用户首页来访指纹动作事件：xc_hook_user_visits()，用户重新加载首页后才会触发，负责指纹处理。非常重要。6、微信绑定/解绑处理钩子：xc_hook_login_weixin(status)，微信账户绑定解绑事件只能通过这个钩子来触发并执行。7、微信解绑操作成功回调钩子：xc_hook_login_weixin_ok(status)。8、手机短信验证码获取钩子：xc_hook_sms_code(type, phone = '')，短信验证码获取必须通过这个钩子来触发。9、手机短信验证码发送成功后的处理函数：xc_hook_sms_code_ok(type, phone, msg)，短信发送成功后，通过这个函数完成页面交互。10、邮件短信码验证处理函数：xc_hook_email_code(type, email = '')邮箱验证码必须通过这个钩子来触发。11、邮件发送成功时的页面回调钩子：xc_hook_email_code_ok(type, email, msg)。12、根据提供的key跳转到相应页面。xc_hook_jump_page(key, title = '', time = 1)，内页跳转关键方法。后台配置简码。13、用户注册请求钩子函数：xc_hook_reg(type)，所有的注册请求都通过这个钩子来发起。14、登录成功回调钩子函数：xc_login_ok_hook(msg)，用户登录成功会触发该钩子，主要负责页面刷新。
8、后端is判断函数库（新增检测方法【文档+注释】更新）：1、检测用户是否绑定了微信账户，xc_is_login_weixin($user_id = '')。2、检测用户是否绑定了手机号码，xc_is_login_phone($user_id = '')。3、检测用户是否绑定邮箱账户：xc_is_login_email($user_id = '')。4、检测用户是否已关注公众号：xc_is_login_gzh($user_id = '')。5、检测用户是否有APP推送标识【CID】：xc_is_login_app_push($user_id = '')。6、检测用户是否已进行实名认证：xc_is_login_idcard($user_id = '', $column = 'code')。7、检测用户环境是否安全：xc_is_security($fingerprint = '')。8、检测账户昵称是否可用：xc_is_nickname($nickname)。9、检查内容中是否包含敏感词：xc_is_sensitive_words($content)。10、检测账户密码是否符合要求：xc_is_password($password)。11、检测手机号是否绑定账户：xc_is_phone_user($phone)。12、检测手机号是否绑定账户：xc_is_phone_user($phone)。13、检测邮箱是否绑定过账户：xc_is_email_user($email)。14、检测身份证是否绑定过账户：xc_is_idcard_user($email)。15、检测字符串是否为手机号：xc_phone_regular($phone)。16、检测字符串是否为邮箱账户：xc_email_regular($email)。17、检测字符串是否为身份证号码：xc_idcard_regular($idcard)。18、PUSH场景检测是否允许发送APP站内信：xc_is_push_app($user_id, $type)。19、PUSH场景检测是否允许发送模版消息：xc_is_push_gzh($user_id, $type)。20、PUSH场景检测是否允许发送邮件消息：xc_is_push_email($user_id, $type)。21、PUSH场景检测是否允许发送手机短信：xc_is_push_sms($user_id, $type)。22、PUSH场景检测是否允许发送服务号消息：xc_is_push_service($user_id, $type)。23、检测标识(或UID)是否为宫论服务号：xc_is_public_account($key)。24、获取当前设备的浏览器指纹标识：xc_is_fingerprint()。
9、为了维护方便，宫论统一消息发送函数钩子（xc_notify_hook）【和五个消息场景下发的接口封装】都从HOOK迁移到【push.php】脚本库。后续的通知推送业务都通过push脚本来更新，注：涉及到异步脚本的执行，每次更新了push脚本的通知逻辑，都需要重启异步进程，否则通过异步下发的通知请求，将无法触发对应的事件。
10、当用户密码重置成功后，会立即触发【xc_update_password_hook】该钩子将会依次执行以下动作。1、通过get_user_by来检测重置密码的用户是否存在，如果不存在则中断执行。2、wp_set_password通过方法对账户密码进行重置操作。如果提供的密码不存在则通过uniqid生成。3、执行xc_logout_session_hook钩子动作，将用户其它设备全部清理下线（保护措施）。4、通过xc_notify_hook执行消息通知，告知对方账户密码已重置。(通知采用异步执行，避免阻塞当前请求)。
11、现在用户可以通过【忘记账户-找回账户-邮箱重置密码】来找回邮箱帮点个账户并重置自己的密码。整个执行流程如下。1、账户如果已绑定邮箱，可以通过邮箱查找到关联账户。2、找到关联账户，可以点击页面的【邮箱账户】进入邮箱重置密码页面。3、在邮箱重置密码页面，用户可以通过接收邮件验证码的方式，对账户密码进行重置操作。4、账户重置后，会通过【update_password】通知场景下发消息，并清退所有账户登录状态。
12、通过xc_update_password_hook钩子重置账户密码成功后，如果用户存在字段【login_security：登录配置（禁用账户密码登录）、login_address_security：登录地域城市限制】则会一并移除处理。避免用户通过邮件重置密码后，依旧因为城市限制、账户密码禁用 而造成无法登录的情况。
13、用户登录成功（xc_login_hook）、用户注册成功（xc_reg_ok_hook）、用户密码重置成功（xc_update_password_hook）三个场景都已通过xc_do_action挂载同名【动作钩子】，允许外部业务通过回调动作触发上述函数。示例：当用户登录成功，如果其它设备在线账户，提醒账户在XX设备在XX城市进行登录了。
14、全局push通知管理新增消息场景【lnsecure_login】，异地登录提醒。使用场景：当用户开启了异地登录提醒，xc_login_hook判断登录请求不安全，就会触发这个提醒。1、短信通知（开启状态）示例：（尊敬的用户：{1}，您的账号疑是异地登录，登录地点：{2}。如不是您本人操作，请立即修改密码。）每日限制三条。2、公众号模版消息（开启状态）模版采用：账户安全通知，每日限制5条。3、APP通知（开启状态）标题:（账户异地登录提醒）。4、邮件通知（开启状态）标题:[异地登录提醒]，每日限制5条。服务号消息（开启状态），服务号标识（security）。

2024年4月14日
1、服务号消息下发成功后，会通过xc_redis_count对其进行计数操作，计数标识为【service_push】注：可以通过get_redis_count($key)获取计数器统计详情，支持查询【总数、今日、昨日、本周、上周、本月、上月、今年、去年】多维度的计数器查询统计。注：这个计数器可以监听每日消息通知发送情况。
2、xc_notify_hook统一发送接口：新增三个内部固定变量【title：标题通用变量(APP-邮件-服务号-站内信)可通用。content：正文通用变量(APP-服务号-站内信)可通用。link：跳转链接变量（只要涉及到菜单点击事件都可用，比如APP通知、服务号菜单、站内信通知、公众号模版消息）】这三个变量在应用通知场景下发前就会封装，减少后续的处理。
3、服务号消息模版数组已完成封装，在下发通知前会在xc_notify_hook函数内部创建【service_template】数组，里面包含字段参数如下【order：通知编号（一般为订单号，可以为空）。title：站内信标题，可以继承函数通用变量。message：站内信通知正文/服务号消息预览。keyword1：服务号第一栏（示例：修改时间：2024年4月14日 19:20）keyword2:服务号第二栏（示例：请求来源：IP地址）。keyword3：服务号第三栏（操作设备：UA解析处理）】依次类推，服务号菜单一共有五个。包含头部和备注，服务号通知有七个区域备注。
4、减少封装处理逻辑，服务号的短代码生成不在通过外部生成而是通过xc_service_push内部直接处理。同时template数组变量新增两个字段【first：头部介绍、remark：底部备注】这两个变量是可选的，如果未提供则first读取（title）、remark读取（message）。可以根据情况决定是否提供。短代码生成的时候，会对所有变量施加（esc_attr）确保安全可用性。
5、统一消息发送接口-服务号业务的封装已完成，xc_notify_hook涉及到服务号通知的处理一律转发到【xc_notify_hook_service】方法处理，该方法会返回标准的【service】数组结构，可以直接将返回结果继承到$result['push']['service']。该方法需要主动传递三个变量。【1、$user_id:需要通知的用户账户ID、2、type：服务号通知场景标识（通过接口传递的变量赋值即可）。3、template：模版消息结构数组。【11个变量，比较复杂】，少部分可选填写，其中title可以通过后台配置来读取。
6、统一消息接口，服务号消息处理流程如下。1、分装service_template数组变量（完整的字段有11个），然后请求：xc_notify_hook_service接口进行处理。2、函数内会效验template数组是否为空，如果为空则直接返回错误【服务号消息发送失败：传递template空数组】。3、通过xc_is_push_service检测服务号通知场景是否开启，如果未开启或不具备消息下发能力 则提示对应错误。4、通过三元处理将title进行修改，然后请求xc_service_push进行服务号消息下发，执行结果直接返回到$result['push']['service']。
7、公众号模版消息发送接口函数【xc_gzh_push】现在采用try-catch语句来捕获可能出现的异常。如果在发送模板消息的过程中出现了异常，那么 catch 语句会捕获这个异常，并更新数据库状态为 'fail'，然后返回错误信息。注：返回结构体与之前保持一致，只是当请求出现异常，会通过catch来返回错误异常，避免接口方面的异常导致全局出错。
8、修复xc_service_push服务号消息执行失败的问题，一共有三个原因引发。依次为。1、template数组缺失(receive/user_id/source/type)四个变量，已在消息下发前对参数进行重新封装。2、xc_is_push_service读取服务号标识错误的问题，字段service_id写成service_key。3、执行sql写入时候type、content两个变量无法正确写入，执行次序问题。content在sql写入后才生成导致的。
9、后台宫论计数器【新增五个PUSH类型计数器】分别为（email_push：【计数器】PUSH - 邮件发送计数、gzh_push：【计数器】PUSH - 公众号模版消息计数、sms_push：【计数器】PUSH - 手机短信计数、app_push：【计数器】PUSH - APP通知计数、service_push：【计数器】PUSH - 服务号消息计数）。以上计数器现在会每日自动重置次数。
10、xc_notify_hook已完成封装，执行后将会同步执行五种消息下发。当所有的消息都下发后会返回一下结构数组【{ "push": { "sms": { "code": 0, "msg": "短信发送成功", "id": 560, "table_name": "wp_xc_sms_push" }, "email": { "code": 0, "id": 26, "table_name": "xc_email_push", "msg": "邮件发送成功" }, "gzh": { "user_id": "3", "code": 0, "msg": "模版消息发送成功", "id": 39, "table_name": "xc_gzh_push" }, "app": { "code": 1, "msg": "APP消息发送失败：用户未绑定APP推送码" }, "service": { "code": 0, "msg": "服务号消息发送成功", "id": 446, "table_name": "xc_service_msg" } }, "code": 0, "msg": "用户通知处理成功" }】对应消息是否发送（可能因为接口、拦截、用户设备不支持等原因失败）成功，可以通过push子数组code状态码来进行判断。
11、新增数据表xc_push（消息通知记录）通过xc_notify_hook下发的消息，无论是否执行成功，都会记录到这个数据表，方便后期接入消息队列。简单讲就是通知消息执行前便会对其进行sql写入，在执行成功或失败后会回调相应字段到该表。数据表字段结构如下【user_id：收信人、type：通知场景、data：消息数据、title：消息标题、消息正文：content、通知时间：time、push：通知状态、status：消息状态】。
12、xc_notify_hook在执行完成所有消息推送后，会通过xc_insert_sql创建推送记录。将本次通知任务记录到数据表，并且将推送场景结果记录下来。方便未来溯源查看。注：如果函数传递了data变量数组，会对其进行json_encode处理，然后写入到data字段。push推送结果页是一样的处理，会将结果转json在写入到字段【push】 在完成上述所有操作后，会额外返回两个字段【id：本次推送数据表记录、table_name：数据表名】
13、宫论统一消息接口已支持异步进程下发通知，xc_notify_hook新增第四个变量【asyn：默认为false】如果需要通过异步进程来执行通知，仅需要将该变量设置为true。如果采用异步执行，那么函数会通过xc_is_asyn来检测当前环境是否处于gateway-worker，如果不处于，并且asyn为TRUE，那么将则通过转发方式【xc_asyn_execution】来请求异步来执行本次通知下发。注：异步进程的特定是高效高速，不阻塞当前请求。缺点是无法获得通知结果，可以根据实际场景来选择处理方式。
14、 异步执行函数xc_asyn_execution，现在返回标准的数组结构。code=0代表请求已转发到异步进程，code=1代表处理失败或异常。msg是错误原因。目前有两种情况会触发code=1的报错。1、在发送异步进程前会通过xc_is_asyn检测当前环境是否处于异步，如果处于则返回错误【当前处于异步进程，不能转发处理!】避免出现套娃循环现象。2、通过function_exists检测到执行函数不存在，则返回【函数不存在，不能转发处理!】注：有两种场景，是不确定能否返回code的。A:当异步进程请求异常，防止请求被丢弃，此时会同步执行函数。此时的返回结果是不可控的。根据函数来决定返回值。B：xc_asyn_execution第三个变量设置为TRUE，需要等待响应返回函数的执行结果。此时返回的结果和A一样，是由函数本身决定值的。

2024年4月13日
1、封装服务号消息下发接口【xc_service_push】，宫论所有的服务号消息发送都必须通过这个接口来处理，该接口返回标准的数组结构。code=0代表服务号消息下发成功，code=1代表服务号消息下发失败。msg是失败详情。这个接口集拦截、消息下发、通知、站内信、数据入库处理逻辑为一体，涉及到服务号的消息（包含接口转发）业务封装，都通过这个方法来处理。
2、服务号消息推送接口，只接受一个数组变量【template】，该数组变量包含以下字段【user_id：服务号关联UID、receive：收信人uid、type：消息场景、message：消息简称（可以理解为站内信和服务号列表页的正文描述）、order：关联商品编号（可选）、link：菜单跳转地址，最好是短代码形式来处理。title：通知标题、content：正文部分、source：服务号标识】
3、服务号基础拦截事件封装完毕：当收到服务号消息请求时，会依次执行以下拦截。1、如果传递的template数组为空，则返回【消息发送失败：传递template模版空数组】。2、如果template存在，但是以下字段存在缺失（content、user_id、receive、source）则返回【消息发送失败：服务号模版参数不完整】。3、通过xc_is_public_account查找服务号配置，返回false。则返回【消息发送失败：未找到服务号(XXX)】。
4、考虑到后面将继承消息队列机制，如果出现并发请求可能导致重复执行。因此xc_service_push新增一个redis安全锁：限制5秒内，只能执行执行一次同类型推送，如果出现重复请求则返回【消息发送失败：服务号超速限制!】。锁名标识为（$template['receive']+$template['type']）即：收信人+收信标识。
5、服务号短代码结构已完成封装处理，标识码为：xc_service_card、自定义属性包含【type：服务号消息场景。link：点击菜单的跳转方式、first：头部区域描述介绍、keyword1:第一个菜单（示例 提现金额：xxxxx元）、keyword2:第二个菜单（同上），以此类推一共有五个菜单。remark：底部区域，备注说明等】
6、短代码规范化处理，在生成短代码的时候 如果变量属于动态参数。比如传递的变量是【商品名称、商品描述、用户昵称、留言评论】类型，必须通过esc_attr函数来处理这些变量，这样可以确保这些变量在被插入到短代码中时，不会破坏 HTML 的结构。注：如果动态参数存在'"引号字符或其他HTML字符，可能会对整个结构产生破坏，造成do_shortcode无法解析或解析出错的.
7、私信消息处理钩子xc_add_msg_hook优化：第五个变量【order】现在默认为空，可以选择性传递，如果未传递则会通过xc_order随机生成 不在强制要求提前输入。xc_wss_message消息通知，现在会过滤来源service类型。服务号消息不会通过xc_wss_message方法来下发聊天消息通知。避免重复触发相应通知。
8、xc_add_msg_hook现在返回标准的数组结构【code=0 代表私信聊天消息创建成功。code=1 代表聊天消息创建失败。msg=是失败原因】需要特别注意的地方是，本身消息发送钩子不做拦截处理，这里错误返回只有以下几种情况。1、传递的参数不完整，比如收信用户、发信用户不存在。2、发信人和收信人是同一个人。3、数据库尝试写入失败。
9、后端新增浏览器指纹处理逻辑：xc_is_fingerprint()。该方法会检测设备客户端是否是异步环境，是的话则返回false，然后检测是否存在指纹cookie，如果存在指纹记录则返回对应指纹记录。如果不存则直接返回false。注：这个不能传递用户user_id，安全考虑。只能获取当前设备的指纹信息。现在是通过cookie来处理，存在一定安全风险，后面会进行加密处理。【后端获取设备指纹，必须通过这个方式来处理】
10、以下场景或方法的指纹获取变更为【xc_is_fingerprint】。1、消息发布钩子【xc_add_msg_hook】。2、朋友圈发布钩子【xc_moments_publish_hook】3、工单返回fault钩子【xc_feedback_publish_hook】4、工单回复评论钩子【xc_feedback_reply_hook】5、xc_add_chat_hook：新版聊天消息处理钩子。6、更新或插入用户安全信息：【xc_update_security】7、系统风控检验：【xc_environment_verification】。8、高德IP地址解析接口【xc_ip_position】。9、封禁用户方法【xc_user_ban】。9、账户解封方法【xc_unban_user】10、API：注销审核检测请求。11、微信注册验证码获取。12、找回密码验证码获取。13、短信登录验证码。13、邮件验证码。14、重置密码验证码。15、支付密码验证码。16、解绑微信验证。17、支付密码重置。18、安全环境验证码。19、冻结账户验证码。20、解除账户冻结。21、一键登录接口请求。
11、xc_add_chat_hook在处理完成聊天消息数据库动作后，在执行PUSH消息（APP+站内信通知）前，会对消息来源进行过滤处理。如果消息类型为service（服务号）则不执行xc_add_chat_ok_hook回调事件。同时返回钩子额外返回一个字段【id】数据表的主键ID，如果后续业务需要对消息进行处理，可以通过这个字段来进行sql处理。
12、通过xc_service_push下发服务号消息，完成基础拦截检测后，会通过xc_add_chat_hook创建聊天消息记录（目前服务号接口暂集成到chat）。如果创建失败（返回code=1）则会直接返回对应错误。如果创建成功，则继续写入本次服务号消息到xc_service_msg数据表，同样的如果sql写入异常则会返回错误【服务号消息发送失败：数据库写入失败】。两个表都完成创建的情况下，将会通过xc_update_notice_list更新通知用户的服务号列表会话记录。
13、通过xc_update_notice_list成功创建服务号聊天记录后，会读取在线过滤配置名单【xc_public_account_Pop_close】 如果当前通知类型已开启在线通知，并且不是被屏蔽的类型。那么将会通过service_notification来下发一条服务号在线通知。注：服务号的头像昵称以及认证标识通过xc_get_avatar来读取缓存。
14、服务号消息接口xc_service_push已完成封装，在完成基础拦截检测后，会依次执行以下动作。1、通过xc_add_chat_hook创建聊天消息，如果创建失败返回错误。2、将服务号消息同步到数据表xc_service_msg，如果同步失败则返回错误。3、检测通知是否开启站内信，rig开启则通过xc_wss_user触发消息通知。4、返回四个标准字段。【code：msg：id：table_name】。

2024年4月11日
1、封装新IS方法xc_is_login_app_push($user_id = '')，检查用户是否有uniapp_cid推送码(APP推送标识)。 $user_id 用户ID（可选）如果未提供用户ID，则尝试获取当前登录用户的ID。然后读取用户自定义元字段【uniapp_cid】，读取成功则返回该推送标识。失败则返回false。注：uniapp_cid是设备推送标识，每次用户来访都会更新。可以通过这个标识像用户发送APP应用通知。不过需要特别注意的一点，uniapp_cid目前是不支持跨账户关联，如果设备登录过两个账户，则最新登录菜户才会拥有uniapp_cid，之前关联账户会被自动清理该字段。
2、xc_is_push_app方法进行以下优化。1、新增拦截 通过xc_is_login_app_push检测用户是否具有推送码，如果没有则返回错误【APP通知发送失败：用户未绑定推送标识】。2、如果允许发送APP通知，则在原有基础上再新增四个字段返回。【title：APP标题、content：APP正文内容、link：APP点击的跳转链接、cid：推送标识码】除了CID，其它字段可能为空，具体看后台配置是否有填写。在获取对应字段时，需要通过empty检测是否为空。
3、xc_push_app_hook迁移到push函数库，负责APP应用场景的push通知。函数原有的执行逻辑基本保持不变，只做了几个优化处理。1、uniapp_cid的获取方式通过xc_is_login_app_push来处理，旧方法读取元字段，不便维护。2、title标题和content内容会通过xc_content过滤处理，并且长度进行（标题：20、正文：50）截断。3、推送成功返回两个新字段：table_name（wp_xc_app_push数据表）、id（数据表记录）。注：新增两个字段是为了适配xc_notify_hook结构体。
4、统一消息发送接口，会初始化两个数组变量1、【gzh_template：公众号模版消息预设数组】包含六个变量（keyword1、keyword2、keyword3、keyword4、keyword5、link）负责模版消息自定义参数处理。2、【app_template：APP通知模版预设数组】包含三个变量（title：APP标题、content：APP正文、link：跳转链接）这些参数可以为空，如果为空则读取后台设定。如果后台页面没有则终止消息下发。
5、统一消息发送接口-APP通知业务的封装已完成，xc_notify_hook涉及到APP通知的处理一律转发到【xc_notify_hook_app】方法处理，该方法会返回标准的【app】数组结构，可以直接将返回结果继承到$result['push']['app']。该方法需要主动传递三个变量。【1、$user_id:需要通知的用户账户ID、2、type：APP通知场景标识（通过接口传递的变量赋值即可）。3、template：模版消息结构数组。只需要传递三个可选参数（APP标题、APP正文、APP跳转链接），如果为空则会尝试读取后台配置。
6、xc_notify_hook_app会执行三元运算来处理APP通知的所需的接口参数。1、link：跳转链接（优先读取传递配置$template['link']，如果为空不存在读取$push_app['link']）2、title：APP标题（优先读取传递配置$template['title']，如果为空不存在则读取$push_app['title']）。3、conten：APP正文部分（优先读取传递配置$template['content']，如果为空则读取$push_app['content']）。优先读取接口函数预设的变量，如果未设置才读取后台参数。涉及到动态参数变量（名字、订单状态、商品介绍）等必须通过函数来预设。
7、统一消息发送接口-APP消息业务的封装已完成，执行流程如下。1、通过xc_is_push_app来查询当前用户是否具备推送资格，如果不符合条件则直接返回错误。2、如果符合条件则进行三元运算来获取【标题、link、正文】三个参数。如果表或正文获取失败，则返回错误【APP消息发送失败：标题和正文参数为空】。3、尝试解析link是否存在，如果存在则将其封装成payload（APP透传数据，确保可以执行页面跳转监听）。如果不存在则将payload标记为null。4、通过xc_push_app_hook发起本次APP消息处理请求（注：禁用异步处理，采用同步处理）。5、将处理结果返回进行封装，确保结果可以被统一消息接口能够识别。
8、消息推送返回结构体统一规范化，如果执行错误或异常返回【code=1、msg=错误或失败详情】，如果执行消息发送成功返回【code=0、msg=xxxx消息发送成功、id：数据表记录主键、table_name：数据表名】涉及的消息钩子有【xc_push_app_hook：app消息下发、xc_email_push：邮件消息下发、xc_phone_push：手机短信消息下发、xc_gzh_push：公众号消息下发】。非必要的情况下，上述返回字段不能做修改，可以增但不能删。
9、统一消息发送接口，消息业务封装简化处理。不在业务内做二次结果判断。而是完整返回原有结构（消息下发的返回结构体已做到统一，不需要单独做适配处理，其返回的字段参数可以被notify_hook接口识别）。同时消息业务下发都固定传递三个变量。1、user_id：通知用户。2、type：消息场景。3、template：消息自定义数组（涉及到自定义的变量，都封装到这里面，不单独提供字段）比如短信就是sms_template、邮件就是email_template.这些消息自定义数组会在函数执行前进行初始化。
10、xc_notify_hook_email：统一消息发送接口-邮件业务 做出两个优化处理。1、移除content、attachment两个变量，改为通过template数组来处理返回结构。同时template数组新增字段title（允许在函数内自定义标题）。2、在发起邮件推送前，会通过三元运算来获取$template['title']是否存在，如果不存在则调用后台配置【push_email['title']】
11、在处理统一push发送请求时，内部的封装好的消息接口【xc_notify_hook_sms、xc_notify_hook_gzh、xc_notify_hook_email、xc_notify_hook_sms】会对第三个变量（template）进行empty检测，如果传递的是空数组则会统一返回code=0、msg=xxx消息发送失败：传递template空数组。注：template如果数组为空（没有设定任何字段的情况）视为主动弃用该场景。这个判断优先级最高，高于后台配置。如果后台启用了通知场景，但是函数没有定义变量，也视为放弃推送。
12、新增数据表【xc_service_push：服务号记录表】负责宫论服务号消息记录。该表字段结构如下【user_id：收信人。service:服务号标识、title：标题、conten：正文（短代码）、json：菜单结构、type：通知场景、time：发送时间、error：错误信息、chat：聊天消息编号、link：消息执行链接参数。status：处理状态】
13、服务号消息发送检测方法已完成封装：xc_is_push_service，需要传递【$user_id 用户ID、$type 推送类型，消息场景】会依次执行以下拦截检测。1、读取xc_push_config配置，检测通知场景【type】是否存在，如果不存在则返回【服务号通知发送失败：通知场景未配置】。2、检测当前通知场景是否已全局禁用，如果全局禁用则返回错误。3、检测service_open字段是否已启用，如果未启用则提示【服务号通知发送失败：通知场景禁用服务号】。4、检测service_key字段是否为空，如果为空则返回【服务号通知发送失败：服务号参数未配置】。5、通过xc_is_public_account方法来获取服务号配置，如果获取失败则提示【XX服务号不存在】。完成上述检测后，返回五个字段【code=0、msg=允许发送服务号消息、title后台预设的服务号标题、key：服务号标识、user_id：服务号绑定user_id】。

2024年4月10日
1、update_password账户密码修改通知，已开启邮件通知。下发的邮件模版如下【尊敬的XXX，您的账户密码已更新。如果这不是您本人的操作，您的账户可能已出现安全问题。如果您未进行此操作，请尽快联系我们以保护您的账户安全】。当用户的密码被修改后，将会通过xc_notify_hook下发邮件通知。
2、后台全局push通知管理（xc_push_config）公众号模版配置新增一个字段：gzh_link（模版跳转链接）用户点击公众号消息，将跳转到指定链接。支持短代码，会自动转义处理。如果为空则默认打开首页。注：之所以将模版链接设置到后台，是为了方便调整。后面如果涉及到小程序内页跳转，APP跳转。那么就可以直接通过后台进行适配处理。不过也存在一个弊端，后台设置的链接不能指定动态参数，指定跳转固定页。
3、xc_is_push_gzh函数已集成对gzh_link字段的处理，在完成基础拦截检测后 准备返回结果前。会效验$push['config']['gzh_link']是否存在，如果存在则通过do_shortcode进行短代码解析，并复制到$result['link']变量。如果不存在则直接输出【home_url：网站首页地址】到$result['link']。相关接口通过xc_is_push_gzh来获取推送权限的时候，可以直接获取link字段来处理模版链接。
4、xc_gzh_push变量优化：keyword0-keyword6都现在为可选状态，可以不指定参数。因为微信官方已经移除了first（头部信息）、remark（尾部备注）两个字段 并且对应菜单字数严格限制在20以内。旧版本的变量结构已经过时，但是考虑到旧版语法兼容问题，目前还不能对传递参数进行移除处理。只能在原有基础上进行适配处理，keyword参数从必须变成可选状态。
5、统一消息发送接口-公众号业务的封装已完成，xc_notify_hook涉及到公众号通知的处理一律转发到【xc_notify_hook_gzh】方法处理，该方法会返回标准的【gzh】数组结构，可以直接将返回结果继承到$result['push']['gzh']。该方法需要主动传递三个变量。【1、$user_id:需要通知的用户账户ID、2、type：公众号通知场景标识（通过接口传递的变量赋值即可）。3、template：模版消息结构数组。只需要传递菜单参数即可（模版ID、链接）可以通过后台配置来读取。菜单参数固定为五个【$template['keyword1']-$template['keyword5']】有几个就写几个，没有的保持为空即可。需要特别注意：菜单字符不要超过20字符。
6、xc_notify_hook_gzh处理流程如下：1、通过xc_is_push_gzh方法来查询用户是否被允许发送公众号通知（主要检查是否开启公众号通知、用户是否绑定关联公众号）。如果当前场景不支持发送，则将['gzh']['code']=1、['gzh']['msg']=不支持原因。如果支持的话，则通过xc_gzh_push执行公众号通知发送请求，模版ID和用户openid通过xc_is_push_gzh方法获取。如果发送成功则返回【code、msg、id、table_name】四个变量，并赋值到$result['gzh']。如果发送失败则只返回【code=1、msg=错误原因】
7、全局push通知管理：【update_password】开启公众号模版消息配置，模版类型选择：账户安全提醒、模版编号：（mLmc_07E56AG6FON_bYV0RCs7-Sgb9CNPF55t_Dvg8Q）、模版跳转链接：为空，默认为首页地址。每日限制（5次，同类型通知，每日最多触发五次）。1、一级菜单（用户账户：xxxxx - 密码修改成功）2、二级菜单（操作时间：如果这不是本人操作，账户可能已出现安全问题。）该模版只有两菜单，3-5忽略默认保持为空
8、xc_notify_hook_gzh第三个变量【template】优化，现在该数组支持link字段设置（模版跳转link：默认为空）。如果未传递则读取后台应用场景（['gzh_link']）配置。如果后台也未配置则视为默认点击跳转首页，复杂的场景，比如订单页、聊天页，活动页等需要动态参数的可以在函数内部进行提前处理。优先级（$template['link']>['gzh_link']>默认首页）。
9、xc_notify_hook宫论通知统一接口目前已集成【xc_notify_hook_sms：短信业务封装、xc_notify_hook_email：邮件业务的封装、xc_notify_hook_gzh：模板消息业务的封装】只需要传递几个动态固定变量，即可完成对应消息的下发。无论是否发送成功，都可以通过$result['push']来捕获处理结果。比如邮件发送状态$result['push']['email']。可以通过子数组的code=状态码来业务的执行状态，1：代表执行失败 msg是失败详情。如果执行成功则返回固定四个变量【code、msg、id、table_name】。注：目前尚未集成app+服务号的通知处理，后面业务扩展到再进行对接。
10、xc_notify_hook有四个变量值，其中【user_id、type】是必须的。$user_id:是需要通知的用户，如果用户不存在会直接返回错误，阻止后续通知。$type：通知场景，决定本次push消息下发方式。【data、asyn】可选变量。$data默认为空，如果通知场景需要订单参数，可以通过这个数组传递，减少对sql的请求。$asyn默认为false，是否采用异步执行。这个是保留字段，需要评估业务是否支持异步执行。注：需要考虑（异步环境的兼容问题，钩子内部的方法都必须支持异步处理才不会出错）。
11、修复公众号模版消息无法通过xc_notify_hook接口下发的问题，一共有两处错误导致的异常。1、xc_is_push_gzh返回的模版ID为空，参数没有正确引用导致的。这也是导致发送异常的主因。2、xc_gzh_push在效验【模版ID和openid】参数是否存在时，错误的将msg写入到code里面。这导致返回的code不是等于1，造成后续的判断出错。
12、xc_gzh_push接口新增一个拦截，当通过xc_post发送模版消息下发请求后，如果返回值【res或$res['errcode']】不存在，则视为接口异常，此时会返回code=1、msg=模版消息发送失败：接口返回异常。并对公众号数据表进行回调操作，将其状态标记为fail、将错误标记为：公众号接口返回异常，没有捕获到【errcode】。这样的处理，可以避免接口出现返回异常。
13、经过慎重考虑，宫论全局push通知配置【APP和服务号】做分离处理，APP不在负责服务号消息（含站内信）的通知处理。同时APP配置新增两个可选字段：1、app_content：APP正文内容，【可选】如果通知函数没有自定义正文，则调用此处的内容描述。涉及到动态参数，只能通过通知函数来自定义。动态参数指的是【订单号、用户名、商品信息】。2、app_link：APP点击链接，【可选】如果通知函数没有定义，则调用这个链接。支持短代码，会自动转义处理。注：如果要（打开商品页、订单页）则只能在通知函数内定义。注：服务号和APP做分离，是为了以后维护扩展方便。服务号类似于微信公众号，具有自定义功能，非常复杂。现在如果将两者混淆在一起，以后会做功能接入会有很多遗留问题。
14、全局push通知管理新增第五个通知方式【service：宫论服务号】服务号与微信公众号差不多一个概念，当订单或交易发生变化。会通过服务号通知用户，并记录下订单变化。用户可以通过服务号列表，查看自己的订单交易变化。涉及到【账户安全、资金变化、交易状态、发货记录】都必须强制性支持服务号消息。该通知配置目前有三个字段。1、service_open负责开启或关闭。2、service_title：服务号消息标题，可以根据应用场景，提前预设标题参数(支持EMOJI)。3、service_id：【宫论服务号】key标识，如果未填写，或填写的服务号不存在也视为未开启！

2024年4月9日
1、通过xc_do_action注册动作回调钩子时，为了防止与过滤钩子发生冲突命名。回调动作函数的命名方式是在原有函数名称后面加上"_callback"。例如，如果原函数是"xc_test()"，那么回调函数就是"xc_test_callback()。通过add_action来挂载注册动作钩子，关联函数一定要注意加【_callback】否则是无效的。
2、宫论已实现【自动初始动作钩子】的设计，执行流程如下。如果某个函数或脚本需要回调动作，则在返回结果前【注：只在处理结果成功的情况下才执行回调】插入【xc_do_action(__FUNCTION__, $result, func_get_args());】即可，后续可以通过add_action来注册挂载回调函数。示例：如果原函数是"xc_test($user_id)"，那么回调注册函数就是"xc_test_callback($result, $user_id)"。
3、通过xc_do_action自动挂载【do_action】需要注意以下事项。1、回调动作函数的命名方式是在原有函数名称后面加上"_callback"。例如，如果原函数是"xc_test()"，那么回调函数就是"xc_test_callback()"。2、回调动作函数的参数数量比原函数多一个。原函数的参数会被传递给回调函数，但是回调函数的第一个参数是一个新的参数"$result"，它是回调事件的返回结果。3、如果原函数是"xc_test($user_id)"，那么回调函数就是"xc_test_callback($result, $user_id)"。4、当通过add_action注册回调函数时，需要注意参数的数量。如果原函数有3个参数，那么注册回调函数时，参数的数量就应该是4。5、注册的回调动作钩子不会接收返回结果，只管执行业务逻辑，不负责效验是否执行成功。同时回调动作钩子是同步执行的。
4、开发文档已集成【宫论动态注册（过滤钩子）：xc_apply_filters】【宫论动态注册（动作钩子）：xc_do_action】的使用方法，并且提供了完整详细的示例和大量备注来介绍这两个钩子的运行机制。后续很多函数脚本都会集成这两种方法来处理回调数据。自定义函数和统一脚本文档都已新增【钩子动作】单栏，如果某个函数或脚本已集成（过滤钩子、动作钩子）则需要再此处填写对应备注，方便后续维护。
5、xc_notify_hook钩子已接入[过滤钩子]，允许通过add_filter来接管函数的执行。在下发通知前，如果需要对指定通知进行进行拦截处理，可以使用add_filter注册函数处理。【注：如果不是指定通知或想拦截的对象类型，则直接返回字符：callback即可，钩子会回调到原有函数处理。不影响处理结果】。
6、xc_notify_hook已完成短信PUSH的业务对接，整个执行流程如下。先通过xc_is_push_sms查询通知的用户是否支持当前短信场景，如果不支持将返回错误码信息并中断执行。如果支持【返回code=0】则通过xc_phone_push发起短信发送请求，因为业务场景不一样，传递的变量将根据消息场景来生成。如果短信发送失败，则将错误原因记录下来，并中断后续的业务执行。
7、统一消息发送钩子场景现在会以数组（$result['push']）形式来记录通知执行状态。比如短信通知，如果执行失败（接口报错、用户超速、场景不支持）等都会记录到 $result['push']['sms']这个数组内部。只要执行失败那么['push']['sms']['code']必定等于1，并且[msg]必定附带错误详情。如果通知消息发送成功，则['push']['sms']['code']等于0。注：因为通知场景涉及五个类型，如果要依次监听所有的通知类型是否执行成功，必须采用数据结构来处理返回结果。短信通过['push']['sms']来获取消息状态，邮件便是通过['push']['email']来获取状态。
8、xc_phone_push短信发送接口优化：第一个变量$phone默认为手机号，但是有很多场景需要通过user_id来下发短信通知，因此该变量现在允许【user_id/phone】两种存在。函数会对phone进行单独处理，如果该变量是数字 但不是手机号。那么将通过get_userdata方法来查询检测变量是否是用户，如果是用户则通过xc_is_login_phone方法来获取对方手机号，如果获取失败则提示【短信发送失败：对方未绑定手机号】。获取成功则将手机号重新赋值到$phone，继续依次执行后续业务。
9、考虑到notify（宫论消息接口）存在数百个通知场景，如果每个场景都在内部方法中来封装短信逻辑，那么将来维护会非常困难。为了接口的统一管理和维护，特定新增一个【xc_notify_hook_sms】方法，专门处理notify_hook钩子的短信业务，这个函数返回的结果是标准[sms]数组结构，可以直接将结果赋值到【$result['push']['sms']】。大致结构如下【code、msg、id、table_name】
10、xc_notify_hook_sms接口优化，现在只需要传递四个变量即可。【1、$user_id:需要通知的用户账户ID、2、type：短信通知场景标识（通过接口传递的变量赋值即可）。3、variable_1：短信第一个变量。4、variable_2：短信第二个变量】手机号和短信模版通过xc_is_push_sms方法来获取。正常情况下，只需要专注【variable：短信变量参数即可】，其它处理逻辑不在notify_hook中执行。
11、xc_email_push邮件发送接口优化：第一个变量$email默认为邮箱账户，但是有很多场景需要通过user_id来下发邮件通知，因此该变量现在允许【user_id/email】两种存在。函数会对email进行单独处理，如果该变量是数字 但不是邮箱。那么将通过get_userdata方法来查询检测变量是否是用户，如果是用户则通过xc_is_login_email方法来获取对方邮箱账户，如果获取失败则提示【邮件发送失败：对方未绑定邮箱】。获取成功则将邮箱重新赋值到$email，继续依次执行后续业务。
12、考虑到邮件发送场景非常复杂，如果没有标识（应用场景）追踪，很难对邮件进行分类处理。因此xc_email_push数据表新增一个字段【type：邮件应用场景】，宫论邮件发送接口：xc_email_push 同时新增第四个变量变更为type，可选参数（默认为空）。如果传递了参数，会在xc_insert_sql创建邮件发送记录时，将type写入到数据表中。
13、统一消息发送接口-邮件业务的封装已完成，xc_notify_hook涉及到邮件通知的处理一律转发到【xc_notify_hook_email】方法处理，该方法会返回标准的【email】数组结构，可以直接将返回结果继承到$result['push']['email']。该方法需要主动传递四个变量。【1、$user_id:需要通知的用户账户ID、2、type：邮件通知场景标识（通过接口传递的变量赋值即可）。3、email_content：邮件的正文内容（一般为HTML）。4、attachment：附件（仅支持服务器文件）】默认情况下，仅需要提供email_content变量即可。
14、xc_notify_hook_email处理流程如下：1、通过xc_is_push_email方法来查询用户是否被允许发送邮件。如果当前场景不支持发送，则将['email']['code']=1、['email']['msg']=不支持原因。如果支持的话，则通过xc_email_push执行邮件发送请求，邮箱地址和邮箱标题通过xc_is_push_email方法获取。如果发送成功则返回【code、msg、id、table_name】四个变量，并赋值到$result['email']。如果发送失败则只返回【code=1、msg=错误原因】