小小乐

最低多少钱？最低多少钱？

测试看看最低多少钱？

内容测试出

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）。钩子将以凭证作为查询标准 来核验用户的请求是否安全可靠！

消息调整不

消息调整测试

很棒，很可以。很优秀！