2024年7月27日
1、xc_face_ok_hook 钩子的优化处理：如果人脸识别成功后，其场景为找回账户，那么在创建 token 的过程中，将会把生成的 token 令牌写入到 cookie【face_retrieve】中。cookie 的有效期被设置为会话有效期，即用户会话结束后，cookie 自动失效。这个包含 token 的 cookie 将用于后端的鉴权操作，尤其在处理如充值请求时，系统会首先检查 token 的有效性。如果检测到 token 存在任何异常，系统还会尝试通过 cookie 进行二次解密操作。
2、前端新增了一个事件：xc_face_retrieve_password()。当用户在【人脸核验 - 重置账户】页面填写了密码和确认密码后，可以点击页面底部的菜单选项【更新账户密码】来触发这个事件。该方法将首先进行前端的必要参数核验，以确保用户输入的数据符合预期和安全要求。参数核验通过后，方法会发起一个ajax请求，将账户重置的相关请求和数据发送到服务端进行进一步处理。
3、成功进入人脸识别重置账户页面后，系统将首先调用 get_redis_meta 方法来鉴权 token 的合法性。若 token 合法，将从中提取 $redis_data['user_id'] 并使用 xc_get_avatar 获取对应用户的详细信息数据。假如 token 无效，或者 xc_get_avatar 无法获取到有效内容，系统会立刻返回非法请求的提示信息。而当这些信息成功获取后，系统将在页面中创建三个表单，帮助用户重置账户信息。第一个表单是 real_account_reset_nickname，用于显示重置账户的用户昵称，且该表单是不可修改的，确保显示信息的准确性和防篡改性。第二个表单是 real_account_reset_password_1，用于输入用户希望设置的新密码。第三个表单是 real_account_reset_password_2，用于二次确认新密码，以确保用户输入的新密码没有错误。
4、在前端验证功能xc_face_retrieve_password中，验证规则如下详述：首先，检测页面元素('.content.real_account_reset')是否存在，若存在，则将其引用通过let关键字保存为变量content。接下来，构建一个data数组对象，以便后续的内容存储和数据操作。在第三步中，检查content的长度是否等于0，如果content为空，则会返回错误信息【非法请求-01】。随后的步骤中，检查变量xc.user_id是否存在，若存在则立即返回错误信息【非法请求-02】。之后，从content中提取自定义属性token，并将其存储到data.token中。如果提取token失败，则返回错误信息【非法请求-03】。紧接着，从content中获取两个表单输入值，即password-1和password-2，并将这些值存储到data对象中。最后一步，验证两个密码表单输入值是否一致，或者其中是否存在任何为空的情况。如果有任何不一致或者为空的情况发生，将返回相应的错误信息。
5、服务端在处理人脸重置密码请求，不像以往一样封装钩子来处理。而是直接在API接口中执行验证信息，减少HOOK的脚本库执行压力。执行标准流程如下。1、首先验证提交的【retrieve】参数是否符合要求，如果不符合要求则返回对应错误。2、获取token，并进行读取。如果提权失败则视为鉴权失败，拒绝后续的请求。3、从token中获取user_id参数，并执行xc_is_password检测，确保用户的输入密码，是安全可靠的。
6、在服务端处理用户的人脸重置账户请求时，首先进行一系列基础拦截和验证操作，以确保请求的合法性和安全性。在完成这些初步检查后，系统会调用一个名为xc_update_password_hook的钩子函数来执行密码重置操作。这一步骤至关重要，因为它直接关系到用户账户的安全。当系统尝试重置密码时，如果操作失败，系统将捕捉并返回相应的错误信息，以便前端处理和提示用户。然而，如果密码重置操作成功，系统接下来会调用另一个钩子函数，即xc_login_hook。这个钩子用于将当前用户的状态更新为已登录状态，从而确保用户可以立即使用新密码进行后续操作。整个过程完成后，服务端会向前端返回一个统一的响应格式，其中包含code=0，表示操作成功，以及msg=账户密码已重置成功，以告知用户其密码已成功更新。
7、宫论密码重置钩子xc_update_password_hook进行优化，增加第三个变量。type：重置密码的来源场景，默认为空。当前密码的重置场景有好几个，为了以后业务的溯源，这里要加入一个场景标识。后续建数据库也好进行追踪。目前有三个重置密码场景，分别为：face:人脸重置密码|sms:短信重置账户|email:邮件重置账户。之前对应的业务代码已适配这个改动，重置密码的时候，会自动传输type值过去。注：后续的重置密码场景接入，都必须做注释说明。
8、前端发起人脸重置账户密码请求时，会通过xc_loading_show拉起指示器【处理中】，当后端返回结果时会通过xc_loading_hide关闭指示器。防止请求执行过程中用户重复点击。后端如果判断密码修改失败，则通过xc_msg返回错误提示。如果密码修改成功，则会提示【账户密码重置成功】。并延迟1500毫秒进行页面刷新xc_reload。强制用户访问首页，刷新页面所有缓存信息。
9、人脸识别重置账户密码细节补充：1、服务端：在成功完成密码重置操作后，服务端会主动删除当前的token令牌，并替换新的token，同时清除cookie中的记录，以此确保安全，避免潜在的安全风险。这一步骤的关键在于避免旧的令牌和cookie可能被恶意使用，从而确保用户账户的安全性不受影响。2、前端：在接收到密码重置成功的确认信息后，前端界面会自动更新。这一更新包括移除real_account_reset_btn元素上的onclick事件，这个元素承载着【更新账户密码】的按钮功能。与此同时，该按钮的文字也将被更改为“密码重置成功”，明确地提示用户此次操作已经完成。
10、xc_account_reset_hook账户重置钩子目前的设计仅会执行与邮箱和手机号关联信息的解绑动作，而不会调用delete_user_meta方法来删除包含【login_security】和【login_address_security】这两个字段的元数据。在实际的业务场景中，移除登录限制（如限制异地登录或禁止账户密码登录）应该通过专门的密码重置功能来实现。这种方法能够更好地控制账户安全性
11、在服务端如果核验人脸识别成功，并且当前操作场景是【retrieve: 找回账户】，系统将会生成一个带有link字段的链接。这个链接通过do_shortcode短代码生成，并且附带一个token参数。前端在处理服务器返回结果时，也会进行相应的判断。如果操作场景是找回账户，则会检查返回结果中是否包含link字段。如果存在link字段，前端将调用xc_mobile_url(link)来进行页面跳转，引导用户进入账户密码重置页面。需要注意的是，这个跳转将会有一个延迟，为1.5秒，以确保用户有足够的时间看到当前提示信息，进而顺利进行后续操作。
12、为了避免实名验证接口的资源浪费，当用户通过xc_hooke_real_personal成功获取到certifyId时，会首先检测当前的实名验证场景是否为【retrieve】。如果检测到场景确实为【retrieve】，系统将尝试通过xc_GetCookie方法获取face_retrieveycookie。如果该方法能够成功获取face_retrieveycookie，则说明当前已经存在相应的token。在这种情况下，程序并不会继续执行xc_hooke_face_sdk以发起新的面部识别请求，而是会提取现有的token。接下来，系统会将这个token封装成一个用于重置账户的链接，并进行页面跳转操作，从而跳过这次验证。
13、进入account_reset.php账户重置页面后，如果传递的token参数无法通过get_redis_meta读取，则表明该令牌无效或者已过期。在这种情况下，系统会首先拦截用户的操作并提示【非法请求，请重新操作!】以告知用户当前的操作无法继续。同时，系统还会通过setcookie函数将token令牌删除并清空，以确保浏览器中的cookie不会保留无效或过期的令牌，从而避免用户在后续操作中继续使用无效的令牌，导致重复跳转的情况发生。

2024年7月26日
1、当用户成功完成人脸识别之后，系统会触发xc_face_ok_hook钩子来执行相应的业务处理逻辑。如果人脸识别的当前场景为“retrieve”，则意味着用户此次操作的目的是为找回或重置账户。为确保操作的安全性和权限控制，该钩子会生成一个专用的token令牌。此令牌的生成方式是基于当前时间戳，通过MD5算法进行加密处理，确保其唯一性和不可预测性。生成的令牌将被赋予一个2小时的有效期限，以防止潜在的安全风险或滥用。用户进行账户资料重置操作期间，该令牌将作为鉴权使用的关键凭据，确保只有合法持有该令牌的请求才能对账户信息进行更改。这种机制不仅提升了操作的安全性，还提高了系统的整体可靠性和用户体验。
2、为了确保token令牌在传输和使用过程中不会被非法篡改或者伪造，现有人脸识别核验生成令牌的方式进行了全面优化和安全提升。首先，令牌标识使用MD5加密算法进行安全加密处理，具体实现为对'retrieve:' . $id进行MD5加密，从而生成唯一且加密的标识字符，确保其在传输过程中的完整性和安全性。其次，令牌的内容被设计为一个复杂且多层的数组结构，内部包含了多个关键信息元素：当前用户的相关信息、用户的IP地址、设备指纹信息、用户代理（User Agent）参数、人脸识别ID主键以及令牌生成的时间记录。这种多维度的信息集合不仅提升了令牌的安全性，还确保了来源的唯一性和不可篡改性。
3、服务端新增了一个名为 xc_account_reset_hook() 的账户重置钩子，这个钩子需要接收一个参数，即user_id（操作对象的唯一标识）。当用户执行找回账户、重置账户、申诉账户等相关操作时，账户将会被重置。在这个重置过程中，涉及到对大量账户资料的处理。由于这些操作场景非常多样化，因此我们需要封装一个统一的钩子来进行业务逻辑的集中处理和管理。这个钩子xc_account_reset()将返回一个标准的数组结构，其中code字段与处理结果相关联：code值为0时表示处理成功，code值为1时表示处理失败；msg字段用于提供失败情况下的错误原因和详细信息。
4、xc_binding_phone_ok_hook：对于手机号换绑操作的钩子进行了全面优化，新增了一个重要变量：user_id，该变量表示操作对象的用户，默认为空。当user_id为空时，将自动读取当前操作用户的user_id；当user_id不为空时，则按照指定的用户进行操作。变量type表示处理方式，此次除了rebind（换绑）和bind（首次绑定）之外，又增加了一个新的处理场景：unbind（解绑）。这样，用户在解绑手机号时，也会符合钩子的触发机制。为了确保业务的一致性，尤其是缓存设计的一致性，现在所有关于手机号的操作——无论是更换、绑定还是解绑——都必须经过此钩子进行处理。
5、xc_binding_email_ok_hook：邮箱换绑操作钩子进行了全面优化处理，与手机号换绑操作的优化一样，系统新增了一个名为user_id的操作对象变量。在这一改进中，如果操作过程中该变量不存在，则系统会自动读取当前正在进行操作的用户信息。优化还进一步拓展了type处理场景，新增加了一种解绑（unbind）操作类型，专门处理用户邮箱的移除请求。在收到解绑请求时，系统将会通过调用wp_update_user方法，将用户绑定的邮箱地址从其账户信息中彻底移除。
6、账户重置钩子xc_account_reset_hook，触发时会通过xc_binding_email_ok_hook和xc_binding_phone_ok_hook两个方法，将用户的手机号绑定和邮箱绑定资料清空处理。账户需要重置，说明用户的手机号和邮件都已经不可用了。因此，必须将现有绑定信息移除，以便用户可以重新进行绑定操作。需要注意的是，重置账户是一个非常敏感的操作，必须特别谨慎地进行处理。
7、在进行用户账户重置操作时，系统会主动移除用户以下两个关键字段，以确保账户的正常使用和登录顺畅。首先，移除字段“login_security”，该字段用于存储用户的登录配置信息；其次，移除字段“login_address_security”，此字段包含用户的登录地址配置。这两个字段包含用户设置的安全措施，比如禁止密码登录、限制地区登录。
8、修复用户注册后，人脸识别免费额度没有发放给用户的问题。由于每次调用人脸识别SDK都需要支付费用，平台不可能无限制地为用户提供补贴。为了解决这个问题，通过后台的xc_face_free_number字段设置了每个用户在注册时的免费使用次数，上限为X次，超出部分则需要用户自行购买资源包。正确的执行流程应为：在用户注册时，系统会检测是否存在可用的免费额度，如果存在，则在注册成功时将该免费额度发放给用户。用户在进行人脸识别操作时，系统会自动抵扣免费额度。而之前的业务逻辑中存在语法错误，导致免费额度未能正确发放给用户。现已针对该问题进行了修正处理，确保用户在注册后可以顺利获得并使用对应的免费额度。
9、当用户尝试通过人脸识别找回账户时，系统首先会通过is_account_status函数来读取用户的账户状态信息。如果系统返回的code值为1，则表示该用户的账户当前处于异常状态。在这种情况下，系统会进一步对具体的账户状态进行判断。如果用户的账户状态为banned（被封禁），系统将返回消息：【'你的帐号【' . avatar['nickname_type'] . '】已被限制登录，封禁时间：' .avatar[ ′ nickname t ​ ype ′ ]. ′ 】已被限制登录，封禁时间： ′ .ban_time . '<br>封禁原因：' . $account_status['reason']】。该消息明确告知用户其账户已被限制登录的原因及具体封禁时间。如果用户的账户状态为deleted（已注销），系统将返回消息：【该帐号已被注销，无法找回】。此功能的设计目的是为了防止那些已经被平台注销或拉黑的用户通过人脸识别功能来重置账户并重新获得访问权限，从而确保平台的安全和秩序。
10、在人脸识别成功后，如果当前的场景为retrieve（即进行账户找回操作），将会触发名为xc_account_reset_hook的方法，执行账户重置过程。账户重置完成后，系统会返回一组详细的信息到前端界面。这些信息包括：code字段，其值为0，表示操作成功；token字段，包含了具体的重置令牌信息，确保安全的账户重置过程；msg字段，值为“刷脸成功：前往重置账户”，用于提示用户刷脸操作已成功，可以进行下一步的账户重置；type字段，明确指出当前操作的人脸识别场景，确保信息的准确传达；id字段，包含了人脸数据表的主键ID，用于唯一标识具体的生物识别记录；最后是table_name字段，指明了存储相关数据的数据表名称。
11、新增页面：【/global/account_reset.php】账户重置页面。此页面的访问权限依赖于传递的TOKEN令牌，必须通过校验TOKEN令牌才能成功访问该页面。若请求中缺失该TOKEN令牌参数，将返回错误信息：非法请求。页面的唯一标识为：account_reset。当用户通过人脸识别完成身份验证后，服务端会生成并发放一个专属的token令牌并传递给前端。前端接收到这个token令牌后，利用该令牌进行鉴权访问此账户重置页面。在这个页面上，用户可以安全地设置新的账户密码，从而完成整个账户重置的过程。
12、账户重置页面已经通过require_once引入了ajax_page.php脚本。为了防止出现非法请求或重复请求，在进入特定页面时会通过get_redis_meta函数来解析token令牌，并从中提取user_id、id等关键字段内容。然后，这些关键字段的信息会以自定义属性的形式写入到页面的page-content元素中，方便后续前端代码进行调用和处理。如果获取这些关键字段内容的操作失败（比如令牌无效或者令牌过期），则会通过xc_empty函数在页面中显著地显示出【非法请求】字样，以警示用户并防止进一步的操作，从而确保系统的安全性。
13、在账户重置页面新增一个提示框，标题为：账户重置说明。提示框的内容涵盖四个重要信息【1、账户当前已关联的【手机号/邮箱】已完成解绑操作。2、账户的登录配置文件已重新设置，所有登录限制已被取消。3、密码修改成功后，账户便可以使用新密码直接登录。4、完成重置操作后，建议及时绑定新的手机号或邮箱。】

2024年7月25日
1、无论在什么场景下，在完成基础拦截请求后，系统会通过get_user_meta函数来读取用户字段face_number。如果该字段为空或者次数小于1，则会触发保护机制。此时系统将返回一个带有code=1和msg=实名认证需先支付实名费用的响应，提醒用户需要先进行实名认证付款操作，再继续进行认证。需要特别注意的是，如果当前用户是游客，系统必须提前赋值user_id，以防止因缺失用户身份信息而始终返回欠费提示。
2、如果人脸识别次数包不足，不需要通过前端二次进行支付业务关联，而是直接通过add_payment_order_hook来创建付款订单。在尝试创建付款订单时，若遇到失败情况，则应返回相应的错误提示，以便及时处理和排查问题。成功创建订单后，将返回一个包含支付令牌的响应【jump：payment】，并且前端会直接跳转至付款页面以完成支付流程，从而简化操作步骤，提高用户体验，确保支付环节的顺畅进行。
3、修复与人脸核验相关的问题，当用户在找回账户页面触发 xc_hooke_real_personal 事件时，页面会错误地后退至登录页面。此错误的根源在于前端处理【核验请求】时，误将 xc.is_login 逻辑设置为通用规则。这种处理方式导致了一个问题，即在找回账户的游客模式下，系统也会强制用户重新登录。因此，需要调整逻辑，使其在游客模式下不会触发重新登录流程，从而优化用户体验，确保找回账户功能的正常运行。
4、xc_hook_Framework_back 重大BUG 修复。这个方法专门用于监听并接管【Framework7的后退事件】。在这个钩子中有一个监听行为，通过使用 :last 选择器来获取当前页面的元素，并对这些元素进行相应的业务逻辑处理。例如，它会判断用户是否已经关闭了某些菜单项。如果用户未关闭这些菜单，则会阻止用户退出。然而，之前获取当前页面元素的方法存在一些问题，导致在某些页面上无法正确获取元素，从而引发监听元素不存在的情况，进而使得预期的业务行为未能被触发。此次修复解决了上述问题，保证了监听行为的正常运行。
5、xc_face_check_hook钩子优化：在处理账户找回请求时，该钩子将执行一系列优化步骤。首先，在获取到用户的身份证数据后，系统将提取身份证上的姓名和身份证号码，即name和code。接着，系统会对这些信息进行解密操作，确保数据的合法性和安全性。随后，系统会将解密后的身份证姓名与号码同用户在表单中输入的信息进行逐一对比。如果发现身份证上记录的姓名或号码与用户输入的信息有任何不匹配，系统将立即返回【身份证信息不匹配，无法完成验证】的提示信息。
6、修复重复进入宫论统一支付页面时出现的付款截止倒计时叠加问题。当前情况是，每次重新进入支付页面，页面的计时器会自动增加1，而不是在用户后退时自动注销旧的计时器。为了解决这个问题，需要通过back行为钩子来监听用户的后退事件。一旦检测到页面存在计时器，系统将立即将其暂停并移除。
7、支付成功回调业务配置：当支付类型为【face_number】时，系统将首先读取支付用户的face_number字段。如果该字段为空或者不存在，则会将其初始化为0。这一步确保在后续处理过程中，face_number字段有一个合理的初始值。然后，系统会调用update_user_meta函数来更新用户的meta数据，此时会增加用户的face_number值。通过这个过程，系统实现对用户人脸识别额度的充值，确保用户可以继续使用基于人脸识别的支付功能。
8、在APP端登录页出现的错误提示【Undefined variable $xc_login_protocol in】问题进行了修复。具体情况是：在华为手机上，APP默认不允许用户协议被预先勾选，需要用户主动点击复选框以示同意，而在其他设备上，用户协议则是默认勾选的。造成这一问题的关键在于变量xc_login_protocol的使用。这个变量用于确定是否需要默认勾选用户协议，但它仅在非华为设备上才会被创建，因此在华为手机上就会出现该变量未定义的情况，从而引发错误提示。为了解决这个问题，采用了三元运算符进行处理，即在变量不存在的情况下，将其赋值为空字符串‘’，从而避免了因变量未定义而带来的错误。这种处理方式不仅能确保在不同设备上的用户体验一致性，还能够有效防止因变量未定义导致的其他潜在问题，从而提升代码的健壮性和稳定性。
9、修复了在支付宝订单支付成功后无法正确回调的问题。经过详细的栈追踪和分析，发现回调日志并没有被触发，这意味着支付宝的异步通知没有成功接收到。进一步排查过程中，发现问题的根源在于异步回调文件访问过程中存在一个致命性的错误返回，导致系统未能正确接收和处理支付宝的回调信息。经过认真修正和多次测试，目前该问题已彻底解决，支付宝订单的异步回调功能已恢复正常，能够顺利接收并处理支付成功后的通知。
10、为了确保用户在支付成功后能够及时收到通知，采取了websocket方式来通知用户，然而，这种通知依赖于user_id来下发，这就带来了一个潜在的问题，即如果用户处于未登录状态（在某些支付场景下，游客用户也是可以进行支付的），那么支付成功后，页面将无法收到任何通知，从而无法进行交互。为了进一步解决这个问题，设计了一个机制：能够同步接收支付结果的付款渠道（如APP内付款、微信公众号内支付）都会在支付成功后首先判断用户状态。如果发现用户未登录，系统将自动触发一个名为xc_hook_payment_success的事件。这个事件的触发能够保证即便是在未登录的情况下，用户也能够及时接收到支付成功的相关反馈，从而优化支付体验并确保操作的一致性和流畅度。
11、（人脸识别资源包）在用户成功完成付款后，会触发【xc_hook_payment_success】前端回调钩子，实现了对付款成功事件的监听。付款成功后，用户界面将通过此钩子进行相应的页面交互操作，确保用户体验连贯顺畅。当用户购买人脸识别资源包成功，不仅会执行通用操作规则，还会触发特定的页面行为。系统会在延迟两秒之后自动执行页面后退操作，将用户带回到人脸识别认证页面，使用户能够继续进行下一步的认证操作。
12、宫论第二个支付场景：【face_number】已顺利完成接入。这一成就得益于采用了统一支付架构，使得接入过程变得极为高效快捷。在这一过程中，开发人员无需过多关注具体的支付流程和方法，只需要专注于支付回调的业务处理即可。未来的支付业务同样方便，只需在后台新增支付场景，并配好相应的参数信息。接下来，对付款成功的回调事件进行单独处理，就能顺利完成一次新的支付场景对接。
13、人脸识别核验成功钩子xc_face_ok_hook进行重构优化，增加通用业务回调和场景业务回调。通用规则：首先，将xc_face数据表进行状态回调，将其标记为OK，这一操作代表本次人脸识别已顺利完成，并且确保数据的状态在整个处理过程中保持一致性，从而进一步提升系统的健壮性和可靠性。场景规则：针对不同的支付场景以及业务需求进行个性化处理。比如在实名认证场景下，需要创建一个独立的实名认证记录表，将用户的相关认证信息详实地写入其中，这不仅确保了数据的完整性和可追溯性，还可以为以后的审计和数据分析提供有力的支持。同时，还需同步更新用户元数据中的对应标识字段，以反映最新的认证状态，确保数据的一致性和及时性，从而完成整个认证处理工作。由于不同的人脸识别场景所涉及的业务逻辑差异较大，因此有必要在设计中做出明确的区分处理，让人脸识别回调功能能够灵活适应不同的业务需求。

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

测试看看最低多少钱？

内容测试出