小小乐

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

测试看看最低多少钱？

内容测试出

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，这一操作代表本次人脸识别已顺利完成，并且确保数据的状态在整个处理过程中保持一致性，从而进一步提升系统的健壮性和可靠性。场景规则：针对不同的支付场景以及业务需求进行个性化处理。比如在实名认证场景下，需要创建一个独立的实名认证记录表，将用户的相关认证信息详实地写入其中，这不仅确保了数据的完整性和可追溯性，还可以为以后的审计和数据分析提供有力的支持。同时，还需同步更新用户元数据中的对应标识字段，以反映最新的认证状态，确保数据的一致性和及时性，从而完成整个认证处理工作。由于不同的人脸识别场景所涉及的业务逻辑差异较大，因此有必要在设计中做出明确的区分处理，让人脸识别回调功能能够灵活适应不同的业务需求。

2024年7月24日
1、在人脸找回账户页面中，现有机制会脱敏显示身份证信息，这可能导致一定的隐私泄露风险。现阶段，该页面仅需传递ID变量即可发起SQL查询，存在隐私安全隐患。因此，为提升安全性，对该页面的访问机制进行调整。即除了需要传递ID，还需传递code（加密的身份证号码）。在执行SQL查询时，将通过这两个字段进行匹配验证，以确保只有在正确传递这两个参数的情况下，才能查看脱敏后的信息。
2、后台新增字段：人脸找回账户备注信息字段（xc_real_retrieve_account_desc），该字段支持短代码和HTML格式，可以填写一些找回账户的详细说明，例如付款流程和重置账户的机制。当用户通过找回功能进行人脸实名操作时，页面将显示这部分内容，以便用户了解相关操作步骤和注意事项。这一功能的引入旨在提升用户体验，确保用户在找回账户时能够获得清晰、详细的指导，从而顺利完成账户找回操作。
3、在后台系统中新增了一项协议，名为【实名人脸找回账户协议】，其唯一标识为：face_retrieve_account。协议的具体地址目前尚待补充，现已用占位符#填空。在personal_recovery（人脸找回账户）页面中，系统将通过do_shortcode方法来嵌入和展示该协议的详细内容。用户在发起下一步操作之前，必须阅读并同意此协议的全部条款，否则将无法继续进行账户找回流程。
4、修复【个人实名认证页面】和【人脸找回账户页面】在鉴权失败时不输出相应错误提示的问题。目前，这两个页面在鉴权失败时执行了 xc_empty 函数，但由于未使用 echo，导致错误提示信息无法显示。为解决这一问题，需要在函数调用处添加 echo 以确保错误提示能够正确显示。此外，这两个页面还集成了【ｅquire_once xc_local_link('ajax_page.php')】页面访问事件拦截功能，如果用户进行非法请求，将会触发规则拦截机制，阻止非法访问行为。
5、xc_hooke_real_personal（个人实名认证钩子，增加一个变量，type：默认值为personal）。人脸识别流程非常复杂，且在后期可能会有较大的变动。为了避免在每个场景下重新执行完整的流程，减少工作量，也为便于业务维护，需要采用更加灵活的处理方式。具体来说，在执行人脸识别时，通过type变量来确定业务场景，根据不同的场景采取相应的事件拦截措施。这样可以实现一个通用规则与各个场景规则的配合，确保不同场景下能够调用合适的处理逻辑。
6、账户找回业务中，触发的人脸识别请求标识定义为：retrieve。在进行前后端交互时，都需要通过这个标识来区分具体业务。而原有的人脸实名认证业务标识将变更为【personal】。由于人脸识别SDK涉及的业务范围非常广泛，而且后续会有更多的集成需求，因此在此次进行找回密码和重置功能开发时，必须做好业务分离工作，确保在以后的业务场景中，可以高效、一步到位地完成接入。
7、前端人脸识别钩子【xc_hooke_real_personal】现已支持“retrieve”功能。当用户发起账户找回请求时，前端系统将执行以下拦截验证步骤。首先，通过xc_is_protocol核实用户是否已勾选找回协议。如果用户未勾选相应协议，则会弹出提示信息【请查阅并勾选页面相关协议】。接着，系统会使用xc.is_login方法验证用户的登录状态。如果用户已登录，系统将提示【处理失败：找回功能仅限未登录用户】。最后，系统会检测当前页面是否包含元素page-content.personal_recovery。如果页面未包含此元素，系统将提示【处理失败：非法请求】。
8、在通用人脸识别功能中，当钩子被触发时，系统会首先初始化一个名为real的对象，并使用let关键字将其声明为局部作用域变量。这个对象包含以下通用参数：real.name（身份证姓名）、real.code（身份证号码）、real.type（人脸识别场景）。其中，real.name和real.code是通过页面中的表单元素来获取的，具体提取的元素会根据不同的人脸识别场景有所区别。在获取这些参数后，系统会使用正则表达式对参数进行有效性验证，以确保输入的数据没有包含非法字符。
9、人脸找回账户页面新增了两个字自定义属性：id 和 idcard。这两个属性通过 GET 请求中的变量进行提取。在前端发起人脸识别函数请求时，系统会将这两个参数封装并提取到 real 对象中。如果这些参数中有任何一个缺失，系统将返回错误提示，以确保参数的完整性。在服务端开始执行人脸识别操作时，首先需要对这两个参数变量进行验证，确保它们的正确性和有效性。
10、服务端在进行人脸识别操作时，现已引入基于场景的拦截策略，该策略允许针对不同的人脸识别场景实施个性化的处理措施。在通用规则的基础上，每个具体的识别场景都可以设定独立的拦截和返回策略。例如，在个人实名认证（personal）场景下，系统会特别检测后端字段[xc_real_personal]。如果该字段未开启，系统将会返回提示信息【管理员已关闭了【人脸识别认证】接口】，从而确保在未经授权的情况下，相关接口无法被调用。
11、在最新的人脸识别配置页面中，新增了一个重要字段：xc_real_retrieve_account（是否开启人脸找回账户）。这一功能允许用户通过人脸识别接口找回并重置账户。如果该选项被关闭，则用户将无法使用人脸识别功能来找回其账户。这项设置作为一个全局开关，确保在前端和服务端都能得到充分的验证和拦截。在用户提交找回账户申请时，前端会首先对该选项进行拦截检查，确保不允许通过关闭此选项的用户提交找回账户的请求。同时，服务端在收到请求后也会进行严格的拦截检测，进一步防止任何非法的提交行为。
12、服务端已完成账户找回功能中的人脸识别基础拦截规则。除了通用拦截规则以外，进行账户找回处理请求时，还会额外进行以下检测：首先，查询【xc_real_retrieve_account】字段的状态，如果该字段未开启，则立即返回错误提示【认证失败：管理员关闭了人脸找回账户功能】。其次，检测xc_is_login接口是否已返回UID，如果已返回UID则提示用户【认证失败：找回账户前请先退出登录】。第三步，构建wpdb查询，检测提交的身份证号和验证码是否匹配数据库中的记录。如果查询结果不存在匹配的记录，则返回错误提示【认证失败：身份证信息不匹配】。若上述所有检测均通过，则会将user_id变量标记为实名用户，此标记将在后续支付业务处理中使用。
13、在redis配置页面的安全拦截检测配置组中，新增了一个用于拦截人脸识别接口请求（idcard_face）的拦截器。该拦截器通过IP地址作为标识进行拦截。具体配置为：当一个用户在五分钟内进行人脸识别请求的次数达到或超过10次时，将触发拦截机制，进入主锁状态，主锁持续时间为300秒（即五分钟）。如果在主锁状态过后，用户仍然在短时间内频繁请求，也会触发副锁机制，副锁持续时间为5秒。使用这项配置后，每次用户进行人脸识别请求时，会触发redis_security_check检测。为了确保系统安全且避免滥用，每次请求的最短间隔时间为5秒，且在五分钟时间内最多只能进行10次请求。超过这一限制后，系统将自动拦截用户请求，并向用户发送超速提醒，提醒内容中会包含具体的时间信息，帮助用户了解下次可以正常进行请求的时间。

消息调整不

消息调整测试

很棒，很可以。很优秀！