A method, system, medium and product for temporarily releasing WeChat applet authentication

Abstract

A method, system, medium and product for temporary release of WeChat applet authentication, relating to the technical field of network authentication. The method comprises: when a terminal accesses a WiFi network, creating a network session for the terminal, activating a first policy to provide a network access portal; based on the portal, extracting target parameters in a network request to form a multi-dimensional feature vector, matching the multi-dimensional feature vector with a preset authentication intent to obtain a confidence level, when the confidence level exceeds a preset matching threshold, disabling the first policy and activating a second policy; based on a temporary release channel, continuously monitoring traffic data to a WeChat applet backend service, obtaining target features from the traffic data, when the target features match a preset verification success feature, activating a third policy to enable the terminal to obtain complete Internet access, and after a preset delay, asynchronously cleaning up session data of the second policy. The above technical solution provides convenient network authentication access for the terminal.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network authentication, and in particular to a temporary release method and system for WeChat applet authentication, a medium and a product. BACKGROUND

[0002] With the rapid development of Internet technology, the application of wireless networks is becoming more and more widespread, and WiFi networks have become an indispensable network access method in people's daily life and work. As a lightweight application form, WeChat applets have been widely used in various fields due to their characteristics of not needing to be downloaded and installed and being convenient to use, further enriching the content and form of network services.

[0003] When a terminal device accesses a WiFi network, authentication is usually required to ensure network security and the effectiveness of management. Traditional authentication methods mainly include a username and password-based authentication method, in which the user needs to manually input an account and password for identity verification, and a short message verification code-based authentication method, in which the user receives a verification code after inputting a mobile phone number and completes authentication by inputting the verification code.

[0004] The existing authentication methods have some obvious defects. The traditional authentication methods are complex to operate, and the user needs to manually input a large amount of information, which not only increases the user's operation burden but also easily leads to input errors, resulting in authentication failure. Moreover, in some scenarios, the user may be unable to successfully complete authentication due to forgetting the password or not receiving the verification code, affecting the user's network use experience. SUMMARY

[0005] The present application provides a temporary release method and system for WeChat applet authentication, which provides convenient network authentication access for terminals, reasonably allocates network resources, and ensures network security and stability.

[0006] In a first aspect, the present application provides a temporary release method for WeChat applet authentication, which comprises:

[0007] predefining a domain name system policy template set, the domain name system policy template set including a first policy for terminal initial network connectivity detection, a second policy for ensuring WeChat applet operation, and a third policy after successful authentication, creating a network session for the terminal when the terminal accesses a WiFi network, preloading the domain name system policy template set into the network session, and activating the first policy to provide a network access portal;

[0008] based on the entrance to the terminal issued all network request real-time deep packet inspection and context analysis, extraction of the network request in the target parameter constitutes a multi-dimensional feature vector, the multi-dimensional feature vector and the preset authentication intent matching to get confidence, when the confidence exceeds the preset matching threshold, disable the first strategy, and activate the second strategy to establish the temporary release channel of wechat applet;

[0009] based on the temporary release channel continues to monitor the traffic data to the wechat applet backend service, from the traffic data to obtain the target feature, and judge whether the target feature matches the preset verification success feature;

[0010] when the target feature matches the preset verification success feature, activate the third strategy to make the terminal get complete internet access permission, and after a preset delay time, asynchronous cleaning session data of the second strategy.

[0011] The above technical scheme, through the first strategy intelligent identification and response to different terminal network alive request, effectively induce terminal pop-up authentication portal page, fundamentally solve the problem of authentication entrance can't call up due to terminal difference. Using deep packet inspection and context analysis technology, accurate identification of user's applet authentication intent, and automatically switch to the second strategy to establish a temporary release channel, ensure that the required network resources of wechat applet are reliably released, and ensure the smooth completion of the authentication process. In the temporary release channel, through multi-dimensional monitoring and feature matching, cross verification of the authentication success signaling of the applet backend is carried out, so that only the real successful authentication can trigger the final release, and the decision is accurate and reliable. After switching, introduce delay cleaning, realize the smooth and non-sensing transition from temporary release to complete release, and completely avoid the bad experience of network connection jitter or interruption after successful authentication.

[0012] In some embodiments, the real-time deep packet inspection and context analysis based on the entrance to the terminal issued all network request, extraction of the target parameter in the network request constitutes a multi-dimensional feature vector, specifically includes:

[0013] application layer protocol analysis is carried out on the network request, and heterogeneous original parameters are obtained from the header field and payload content in the analysis, the heterogeneous original parameters include terminal type identifier, request target domain name, resource path and source page;

[0014] the heterogeneous original parameters are converted into structured data objects, and the structured data objects are added to the historical request sequence corresponding to the network session in time sequence;

[0015] link the discrete request objects as a behavior link according to a page jump relationship if a source page in the network request points to a resource path of an authentication portal page in the history request sequence;

[0016] generate a first feature sub-vector representing a static feature of a network request based on the terminal type identifier, the request target domain name, and the resource path, generate a second feature sub-vector representing a dynamic behavior sequence of a user based on a sequence of request target domain names contained in the behavior link, and splice the first feature sub-vector and the second feature sub-vector to form the multi-dimensional feature vector.

[0017] By using the technical solution, heterogeneous and non-standardized data (such as headers and payloads in different formats) in original network messages are uniformly converted into structured data objects that are machine-readable and have clear meanings through application layer protocol analysis and parameter structuring. By establishing a behavior link starting from an authentication portal, discrete and independent network requests initiated by a user at different time points are connected into a coherent and ordered operation sequence according to their inherent page jump logic. This enables the system to understand the complete operation path and intention evolution process of the user rather than looking at individual requests in isolation. By generating a static feature sub-vector and a dynamic behavior sequence sub-vector and splicing them, the instantaneous features of individual requests and the long-term behavior pattern features across requests are combined. This constitutes a comprehensive feature view that describes both the current state and historical behavior, providing unprecedented rich information dimensions for accurate intention recognition.

[0018] In some embodiments, the linking of the discrete request objects as a behavior link includes:

[0019] traversing the history request sequence, and determining a first request object whose resource path matches a uniform resource locator of the authentication portal page as a starting node of the behavior link;

[0020] for each request object after the starting node in the history request sequence, checking whether a source page parameter points to a resource path of a last node of a behavior link that has been constructed;

[0021] if yes, adding the currently checked request object as a new last node of the behavior link, otherwise, recording the currently checked request object as a pending node and creating a new potential behavior link for the pending node;

[0022] starting an idle duration timer for each behavior link, and when there is a target behavior link that has not expanded a new node before the idle duration timer expires, determining that the target behavior link has been invalidated and removing the target behavior link from a context of the network session.

[0023] With the above technical solution, the request for the first matching authentication portal page is established as the only starting node, establishing a clear and reliable reference point for the entire behavior analysis. This ensures that all subsequent behavior analysis is conducted in the correct authentication context, fundamentally avoiding the interference of irrelevant traffic or incorrect sessions. By introducing the pending node and potential behavior link mechanism, the system can handle multiple parallel operation sequences that the user may open (e.g., opening new tabs simultaneously). This gives the system the ability to recognize and respond to complex, nonlinear user behavior, greatly enhancing its robustness and adaptability in real network environments. By setting an idle duration timer for each behavior link and automatically cleaning up invalid links, the system implements lifecycle management of behavior context. This effectively prevents system resources from being occupied by outdated and obsolete session data, thereby improving the overall efficiency and accuracy of the system.

[0024] In some embodiments, the matching of the multi-dimensional feature vector with the preset authentication intent includes:

[0025] The multi-dimensional feature vector is input into a Boolean decision channel, a probability decision channel, and a sequence decision channel, respectively. The Boolean decision channel compares the request target domain name in the multi-dimensional feature vector with a set of predefined key domain names, outputs a binary decision signal, the probability decision channel outputs a preliminary probability value based on the network request static features, and the sequence decision channel outputs a sequence fit score based on the matching integrity of the behavior link and the preset authentication process template. The set of key domain names includes official domain names required for WeChat applet operation and feature domain names used to distinguish network detection behaviors of different terminal manufacturers.

[0026] A dynamic weight is assigned to the binary decision signal, the preliminary probability value, and the sequence fit score, respectively. When the binary decision signal is true, the dynamic weight of the binary decision signal is set to the maximum value, otherwise, the weight proportion of the preliminary probability value and the sequence fit score is adjusted according to the real-time load of the current network session, and the output results of the three channels are combined into an intent confidence according to a weighted fusion strategy.

[0027] The intent confidence is smoothed to obtain an intermediate confidence, and the intermediate confidence is weighted and averaged with a baseline confidence based on the current time period and terminal historical reputation to output the confidence.

[0028] The technical scheme is adopted, three parallel decision channels of Boolean, probability and sequence are set up, and judgment is made from three indispensable dimensions of deterministic rules (whether a key domain name is hit), statistical possibility (static feature matching degree) and behavior logic (operation flow integrity). This ensures the comprehensiveness of the decision basis, so that the system can grasp the hard rules, handle the fuzzy situation, and understand the behavior context, forming a strong complementary advantage. By setting the dynamic weight rule of "Boolean channel one vote", a safety red line and an efficiency shortcut are set for the decision system. Once the key domain name is hit, a high confidence conclusion is directly given regardless of the results of other channels. This ensures the absolute release of the key request (reliability), and avoids unnecessary complex calculation on the explicit request (high efficiency). By dynamically adjusting the weights of the probability and sequence channels according to the real-time system load, intelligent trade-off between calculation accuracy and response speed can be made. When the load is high, the probability model with higher efficiency is preferred, and when the load is low, the sequence analysis with higher accuracy but more time-consuming is fully utilized, so that the system can adapt to different operating environments and maintain the best performance.

[0029] In some embodiments, the target feature is obtained from the traffic data, and it is judged whether the target feature matches the preset verification success feature, specifically including:

[0030] In the temporary release channel, the security link connection state of the encrypted network request and the interactive response of the application network request are monitored in parallel;

[0031] When the success response packet corresponding to the interactive response is obtained, the success response packet is analyzed at the application layer load, and the business status code field and the user identity field are extracted;

[0032] The user identity field is sent to an independent authentication verification microservice decoupled from the WeChat applet backend for authenticity verification, and the returned verification result is received;

[0033] When the security link connection state is successful, the business status code field represents success, and the authenticity verification result is true, it is determined that the target feature matches the verification success feature.

[0034] By means of the technical scheme, the success of the authentication process is verified from two independent layers by monitoring the connection state of the secure link (transmission layer) and the application interaction response (service layer). In the context that encrypted communication has become a standard, the service status code and user identity, which are the two most core service evidences, are directly extracted by analyzing the application layer load of the successful response packet. This enables the system to penetrate the encryption channel, accurately read and understand the internal service semantics, and provides a direct basis for judgment. By sending the user identity to the authentication verification microservice independent of the WeChat applet backend for verification, the key architecture decoupling is realized. This enables the network release system to perform secondary confirmation through an independent component that specializes in security verification, effectively preventing security risks caused by the breach of the business backend, and achieving separation of duties and security enhancement.

[0035] In some embodiments, the activating the third policy to enable the terminal to obtain complete Internet access includes:

[0036] Switching the domain name system resolution server address of the terminal from a first address serving the second policy to a public network domain name system server address;

[0037] Initiating a domain name system resolution request for a preset public network domain name to the terminal, and determining whether the terminal can obtain a response from the public network domain name system server address;

[0038] After confirming that the terminal can obtain a response from the public network domain name system server address, increasing the permission level of the network session, allowing the terminal to access resources on the Internet, and marking the state of the network session as authenticated.

[0039] By means of the technical scheme, the domain name system resolution address of the terminal is switched from the first address serving the applet to the public DNS server, which fundamentally changes the network access capability of the terminal. This means that the terminal can no longer only resolve specific domain names that are released, but can query any domain name on the Internet, which is a core operation from limited access to complete access. The system actively initiates a detection request for a public network domain name to the terminal, and this mechanism is used to verify whether the DNS switching has actually taken effect on the terminal, ensuring that the terminal has started using the new, fully functional DNS service.

[0040] In some embodiments, the asynchronously cleaning the session data of the second policy after the preset delay time includes:

[0041] In the authentication process, the network traffic of the network session is sampled in a fixed time window, and the total number of data packets in each time window is counted. The total number of data packets is compared with a plurality of preset threshold intervals to map to the corresponding traffic activity level.

[0042] According to the traffic activity level, a predefined negative correlation mapping table is queried to determine the delay time;

[0043] An asynchronous cleanup task is started, and a cleanup operation is performed to release the domain name system resolution resource occupied by the second policy when the delay time is reached.

[0044] According to the technical solution, the fixed delay time is replaced by a delay time dynamically calculated according to real-time network traffic activity, so that the resource recovery strategy can perceive and adapt to the actual use behavior of each user. Through the negative correlation mapping mechanism that "the higher the traffic activity, the shorter the cleanup delay", the user behavior is associated with the urgency of resource recovery. The user with active behavior is considered to have quickly completed the authentication core task, and the resource can be recovered as soon as possible; otherwise, the user with inactive behavior may still be slowly interacting, and the resource needs to be kept for a longer time to prevent interruption. This reflects the context-aware intelligence of the system. The asynchronous cleanup mechanism ensures that resource recovery does not block the main process and does not affect the speed of the user obtaining complete access permission.

[0045] In a second aspect, an embodiment of the present application provides a computer system, including a memory, a processor and a computer program stored in the memory; the processor executes the computer program to implement the steps of the method described in any possible implementation manner of the first aspect.

[0046] In a third aspect, an embodiment of the present application provides a computer readable storage medium, having a computer program / instruction stored thereon, which is executed by a processor to implement the steps of the method described in any possible implementation manner of the first aspect.

[0047] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program / instruction, which is executed by a processor to implement the steps of the method described in any possible implementation manner of the first aspect.

[0048] It can be understood that the computer system provided in the second aspect, the storage medium provided in the third aspect and the computer program product provided in the fourth aspect are all used to execute the method provided in the present application. Therefore, the beneficial effects that can be achieved are referred to the beneficial effects in the corresponding method, which will not be described here.

[0049] The one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0050] 1. By activating the first strategy dedicated to the initial network connectivity detection of the terminal, the specific network detection request issued by various manufacturers' terminals can be intelligently responded. The operating system of the terminal can be successfully induced to believe that the network has been connected, and the limited indicators such as exclamation marks or crosses on the WiFi icon can be automatically eliminated, and the user can be reliably prompted to open the online authentication portal page. This provides a unified and smooth authentication starting point for all terminal users;

[0051] 2. By deep packet detection and intelligent algorithm, after the user clicks the WeChat applet authentication, the intention can be accurately identified. The system can automatically and instantly disable the first strategy, and activate the second strategy dedicated to guarantee the operation of the WeChat applet. This establishes a temporary and pure network channel, ensures that all domain names and servers necessary for the operation of the applet can be normally accessed, thereby greatly improving the success rate and loading speed of the WeChat applet;

[0052] 3. In the temporary release channel, the communication traffic between the applet and the back-end server is actively monitored and analyzed. The business signaling representing that the user has truly completed the authentication can be accurately captured and parsed from the encrypted network traffic. This ensures that the system will only trigger the final release operation after confirming that the user identity authentication has been successfully completed, effectively preventing false release or early release;

[0053] 4. After confirming the successful authentication, the third strategy is activated to switch the DNS resolution of the terminal to the public network server. The user instantly obtains complete Internet access permission, and through an asynchronous cleaning mechanism, the system does not immediately remove the temporary channel for guaranteeing the applet authentication after giving the user full permission, but waits for a short delay. This ensures that all ongoing network requests in the applet can be successfully completed, and completely avoids the sudden interruption or error of the applet operation due to resource cleaning at the moment of obtaining full network access permission. BRIEF DESCRIPTION OF DRAWINGS

[0054] Figure 1 is a flowchart of a temporary release method of WeChat applet authentication in an embodiment of the present application;

[0055] Figure 2 is a flowchart of WeChat applet connecting WiFi in an embodiment of the present application;

[0056] Figure 3 is a flowchart of scanning code to start the applet to connect WiFi in an embodiment of the present application;

[0057] Figure 4 is a flowchart of computer connecting WiFi through applet in an embodiment of the present application;

[0058] Figure 5is a flowchart of a hotel roaming process in the embodiments of the present application.

[0059] Figure 6 is a schematic diagram of an exemplary hardware structure of a computer system in the embodiments of the present application. DETAILED DESCRIPTION

[0060] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to be limiting of the present application. As used in the specification and the appended claims of the present application, the singular forms "a," "an" and "the" are intended to include both singular and plural forms, unless the context clearly indicates otherwise. It will be further understood that the terms "and / or" as used herein refers to any or all possible combinations of one or more of the associated listed items.

[0061] Hereinafter, the terms "first" and "second" are only for the purpose of description and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, the meaning of "a plurality of" is two or more, unless otherwise specified.

[0062] The method of the embodiments of the present application will be described below in conjunction with Figure 1 .

[0063] Figure 1 is a flowchart of a temporary release method for WeChat applet authentication in the embodiments of the present application, as Figure 1 shown, the temporary release method for WeChat applet authentication includes the following steps:

[0064] S101, predefine a domain name system policy template set, the domain name system policy template set includes a first policy for terminal initial network connectivity detection, a second policy for ensuring WeChat applet running, and a third policy after authentication success, when the terminal accesses a WiFi network, create a network session for the terminal, pre-load the domain name system policy template set into the network session, and activate the first policy to provide a network access portal;

[0065] S102, based on the portal, perform real-time deep packet inspection and context association analysis on all network requests issued by the terminal, extract target parameters in the network requests to form a multi-dimensional feature vector, match the multi-dimensional feature vector with a preset authentication intent to obtain a confidence degree, when the confidence degree exceeds a preset matching threshold, disable the first policy, and activate the second policy to establish a temporary release channel for WeChat applet;

[0066] S103, based on the temporary release channel, continuously monitor the traffic data to the micro message program backend service, obtain target features from the traffic data, and judge whether the target features match the preset verification success features;

[0067] S104, when the target features match the preset verification success features, activate the third strategy to enable the terminal to obtain complete Internet access permission, and asynchronously clean up the session data of the second strategy after a preset delay time.

[0068] Predefined policy template set: At the system level, a set of DNS (Domain Name System) policies with three different purposes has been configured in advance. The first policy (probing alive policy): The core is a "domain-IP" mapping table, which contains specific domain names used by major terminal manufacturers (such as Vivo, OPPO, Xiaomi, Huawei / Honor, etc.) to check network connectivity. The second policy (applet guarantee policy): Contains all official and business domain names necessary for the normal operation of WeChat applets. The third policy (global release policy): It is the normal public DNS resolution policy. When a user's mobile terminal connects to WiFi, the network side system creates a separate network session for it, similar to establishing an independent file folder. The system loads the above policy template set into the session and immediately enables the first policy. At this time, when the terminal's operating system sends network connectivity probing requests to the manufacturer's server, these requests will be captured by the first policy and the domain name will be resolved to a preset accessible IP address. This action makes the terminal operating system believe that the network is smooth, so the exclamation mark or cross on the WiFi icon disappears, the status bar displays WiFi connected, and the online authentication portal page can be automatically popped up or manually called out. After the user sees the authentication portal page and operates it, the system monitors and deeply analyzes all HTTP (Hypertext Transfer Protocol) / HTTPS (Hypertext Transfer Protocol Secure) requests sent by the terminal in real time. It extracts key parameters such as User-Agent (terminal type identification), Host (request target domain name), URL (Uniform Resource Locator) path, and Referer (source page). These parameters are combined into a multi-dimensional feature vector and matched with the authentication intent fingerprint library. This matching process calculates a confidence level to quantify how likely the current request is a user's attempt to start WeChat applet authentication. When the confidence level exceeds the preset threshold (e.g., 90%), the system determines that the user's intent is clear. At this time, the system disables the first policy and activates the second policy. The activation of the second policy means that the system has established a temporary release channel for the operation of WeChat applets. In this channel, all necessary network access for applet connection to WeChat server, code download, API (Application Program Interface) call, etc. can be correctly released, thereby ensuring that WeChat applets can be normally loaded and run, complete the authentication process, and effectively solve the problem of applet call failure. The system continues to monitor network traffic through the channel to the WeChat applet backend service. When the user completes the operation of allowing information acquisition in the applet and submits it, the applet backend returns a signal indicating authentication success. The system captures and analyzes the specific verification success feature from the returned traffic data through deep packet inspection technology. This feature may be a specific HTTP success status code, a "success" identifier carried in the response packet payload, or an encrypted security token.Once the authentication is confirmed successful, the system activates the third policy immediately. This means the system will turn off the special DNS shunting function set for temporary release, and switch the DNS server of the terminal to the normal public DNS. The terminal has thus obtained full internet access and can freely browse any website. At the same time of activating the third policy, the system will start a timer and asynchronously clean up the session data and cache rules related to the second policy after a preset delay (e.g. 2-5 seconds). The delay cleaning is a key design to ensure user experience. It ensures that a small amount of network requests that may still be in progress within the applet at the moment of permission switching can be completed smoothly, fundamentally avoiding the phenomenon of "applet error or lag after successful authentication". After the cleaning is completed, the system resources are released and the user session enters a stable and clean authenticated state.

[0069] In some embodiments, the real-time deep packet inspection and context association analysis of all network requests issued by the terminal based on the entry includes extracting target parameters in the network requests to form a multi-dimensional feature vector, specifically including:

[0070] Performing application layer protocol analysis on the network requests to obtain heterogeneous raw parameters from the header fields and payload content, the heterogeneous raw parameters including terminal type identifier, request target domain name, resource path, and source page;

[0071] Converting the heterogeneous raw parameters into structured data objects, and adding the structured data objects to the historical request sequence corresponding to the network session in chronological order;

[0072] If the source page in the network request points to the resource path of the authentication portal page in the historical request sequence, linking discrete request objects into behavior links according to the page jump relationship;

[0073] Based on the terminal type identifier, the request target domain name, and the resource path, generating a first feature sub-vector representing the static features of the network request, and based on the request target domain name sequence contained in the behavior link, generating a second feature sub-vector representing the user dynamic behavior sequence, and splicing the first feature sub-vector and the second feature sub-vector to form the multi-dimensional feature vector.

[0074] The system parses each HTTP / HTTPS request sent by the terminal, strips off the communication protocol shell, and directly obtains the information carried inside. From the parsed request, a variety of different types (heterogeneous) of raw information are extracted, including terminal type identifier, request target domain name, resource path, and source page. Terminal type identifier: mainly parsed from the User-Agent header field of the request, which can indicate whether the request is from Vivo, OPPO, Xiaomi, or Huawei / Honor mobile phones of specific brands and models, which is the basis for understanding the differences in behavior of different terminal devices. Request target domain name: obtained from the Host header field, which indicates the target server object that the terminal attempts to access, such as accessing connect.vivo.com.cn (Vivo probe server) or wx.qlogo.cn (WeChat avatar server). Resource path: the path part of the URL, which indicates the specific resource or interface on the server, such as requesting the main HTML file of the portal page ( / portal / index.html) or an API interface for submitting authentication ( / auth / api / login). Source page: obtained from the Referer header field, which is the key to context association, indicating the source of the current request. The above extracted disordered raw parameters are uniformly encapsulated into a fixed format, machine-friendly data structure (object). Each structured request object is added to a list dedicated to the current network session in chronological order. This list constitutes the complete and ordered operation log since the user connected to WiFi, providing a time sequence background for subsequent analysis. The system checks whether the source page of the current request points to the resource path of the request that has been confirmed as the "authentication portal page" in the historical request sequence. If the above condition is true, it means that the current request is triggered by the user from the authentication portal page. The system links this discrete request object to the request chain starting from the portal page based on this page jump relationship, forming a growing behavior link. The system integrates all the information collected and processed to generate a feature vector for intelligent decision-making. Generate the first feature sub-vector (static feature): based on terminal type identifier, request target domain name, resource path, generate a feature sub-vector. It depicts a static snapshot of a single request. Generate the second feature sub-vector (dynamic behavior sequence feature): based on the request target domain name sequence contained in the behavior link, generate another feature sub-vector. This sequence describes the domain names visited by the user in sequence from the starting point. It depicts the user's dynamic behavior pattern and operation habit. For example, a "portal page domain name → WeChat official domain name" sequence strongly implies the intention of WeChat applet authentication. The above two sub-vectors are concatenated to form a final multi-dimensional feature vector containing rich information.After the series of processing, the system successfully promotes the underlying network packets to high-level semantic behavior intention representation.

[0075] In some embodiments, the linking of the discrete request objects into behavior links according to page transition relationship comprises:

[0076] Traversing the historical request sequence, the first request object whose resource path matches the authentication portal page uniform resource locator is determined as the start node of the behavior link;

[0077] For each request object following the start node in the historical request sequence, it is checked whether the source page parameter points to the resource path corresponding to the end node of the currently built behavior link;

[0078] If yes, the currently checked request object is added as a new end node of the behavior link, otherwise, the currently checked request object is recorded as a pending node, and a new potential behavior link is created for the pending node;

[0079] For each of the behavior links, a idle duration timer is started, and when there is no target behavior link expanding a new node before the idle duration timer expires, it is determined that the target behavior link has been invalidated and the target behavior link is removed from the context of the network session.

[0080] The system scans (traverses) all the historical request sequences recorded for this session from head to tail, looking for the first request object whose "resource path" exactly matches the known authentication portal page URL. In the messy history record, the starting point of the user's authentication journey is precisely anchored. In the standard process, all the user's subsequent authentication behaviors should originate from this access to the portal page. Determining this request as the "starting node" ensures that all subsequent analysis is built on the correct context. Avoiding some irrelevant, accidental or by the browser preloaded request misjudged as the starting point of behavior, ensures the purity of the theme of the behavior link. After the starting node, for each subsequent request in the historical sequence, the system performs a key check: check whether the "source page" parameter of the current request is exactly directed to the "resource path" of the last node (i.e. the end node) of the current behavior link that has been built. Verify whether the current request is triggered directly by the user on the last operation page. This ensures that each link in the behavior link has a clear cause and jump relationship, and reconstructs the user's real operation path. For example, assuming that the current end node of the link is the portal page portal / index.html, and the next request is to load a picture on the page static / button.png, and the source page is portal / index.html, the check passes. If the source page of the next request is still portal / index.html, it means that it is also triggered directly by the portal page. If the check passes, it means that the request is a natural continuation of the current behavior link. The system will append it as a new end node to the existing link, making the link grow forward. If the check does not pass, it means that the request is out of the current main behavior link. This may be because the user has opened a new browser tab, clicked a button on the page that points to an external link, or some kind of asynchronous loading. Instead of simply discarding the request, the system records it as a "pending node". At the same time, a new "potential behavior link" is created starting from this "pending node". For the main link, ensure its logical coherence and accuracy. For abnormal jumps, have fault tolerance and parallel processing capabilities. The system acknowledges that there may be multiple lines of user behavior, and opens up independent analysis channels for these potential new sequences, greatly enhancing robustness in complex real network environments. The system binds a free duration timer to each behavior link (including the main link and all potential links). Each time a new node is successfully appended to the link, the timer is reset. If a link fails to expand new nodes before the timer expires, the system determines that the link has failed (the user has abandoned the operation process) and removes it from the session context. Release memory and computing resources in time, avoid the system being occupied by a large number of abandoned and outdated links.

[0081] In some embodiments, the matching the multi-dimensional feature vector with the preset authentication intent obtains a confidence level, and the confidence level comprises:

[0082] The multi-dimensional feature vector is respectively input into a Boolean decision channel, a probability decision channel and a sequence decision channel. The Boolean decision channel compares a request target domain name in the multi-dimensional feature vector with a predefined key domain name set, outputs a binary decision signal. The probability decision channel outputs a preliminary probability value based on the network request static feature. The sequence decision channel outputs a sequence fitness score based on the matching integrity of the behavior link and the preset authentication process template. The key domain name set includes an official domain name required for WeChat applet operation and a characteristic domain name for distinguishing network detection behaviors of different terminal manufacturers.

[0083] A dynamic weight is respectively assigned to the binary decision signal, the preliminary probability value and the sequence fitness score. When the binary decision signal is true, the dynamic weight of the binary decision signal is set to a maximum value. Otherwise, according to the real-time load condition of the current network session, the weight proportion of the preliminary probability value and the sequence fitness score is adjusted. According to a weighted fusion strategy, the output results of the three channels are combined into an intent confidence level.

[0084] The intent confidence level is smoothed to obtain an intermediate confidence level. The intermediate confidence level and a baseline confidence level based on a current time period and terminal historical credit are weighted and averaged to output the confidence level.

[0085] The system will send the multi-dimensional feature vector characterizing the network behavior into three independent decision channels for analysis, each providing opinions from different dimensions. The Boolean decision channel only focuses on the "request target domain name" in the feature vector, which performs an exact match with a predefined set of key domain names. The set of key domain names includes WeChat applet official domain names and terminal manufacturer probe feature domain names. WeChat applet official domain names: such as wx.qlogo.cn, res.wx.qq.com, etc. Hitting these domain names is strong evidence of authentication intent. Terminal manufacturer probe feature domain names: such as connect.vivo.com.cn, cp.cloud.oppo.com, etc. Hitting these domain names, combined with the context, can be used to identify terminal types and exclude interference. The Boolean decision channel outputs a binary decision signal (True or False), which outputs True (representing strong affirmation) as soon as it hits the key domain names in the whitelist, otherwise it outputs False. The probability decision channel mainly analyzes the static features in the feature vector (such as terminal type, single request resource path, etc.). It is usually a trained machine learning model (such as a classifier) that calculates the matching degree of these features with historical authentication behavior data. The probability decision channel outputs a preliminary probability value between 0 and 1, which represents "how likely is the authentication intent based on the instantaneous features of the current request". The sequence decision channel analyzes the behavior link, i.e. the user's series of coherent operations starting from the portal page, and compares the actual request domain name sequence with a pre-defined authentication process template. The template defines the ideal steps to successfully invoke the applet, for example: [portal page domain name] -> [WeChat JS-SDK resource domain name] -> [applet-specific business domain name]. The sequence decision channel outputs a sequence fit score, the higher the score, the more consistent the user's actual operation sequence with the standard template, which can effectively identify abnormal behaviors that look normal individually but are illogical when combined. If the Boolean channel outputs True (hits the key domain name), it is given the maximum weight of the opinion, which directly dominates the final conclusion. This is because hard rules have the highest authority and reliability. If the Boolean channel outputs False, the weights of the probability decision channel and the sequence decision channel are dynamically adjusted according to the current system real-time load. High load: prioritize efficiency, increase the weight of the probability channel which calculates faster. Low load: prioritize accuracy, increase the weight of the sequence channel which analyzes more deeply and accurately. According to the set weights, the output values of the three channels are weighted and combined into a unified intent confidence, which preliminarily reflects the system's overall judgment of the authentication intent. The intent confidence is input into a signal smoothing filter (such as a moving average filter) to eliminate confidence spikes caused by network transient jitter, browser preloading, etc. accidental factors, to get a more stable and reliable intermediate confidence.The smoothed intermediate confidence is weighted averaged with a baseline confidence. The baseline confidence is related to the current time period and the terminal's historical reputation, for example, if a request from an unknown terminal is received during late night, the baseline confidence will be lowered, and the system will be more cautious; if the device has a successful authentication record in the past, the baseline confidence will be higher. The final calibrated confidence is used to compare with a preset threshold to determine whether to trigger a policy switch.

[0086] In some embodiments, the target feature is obtained from the traffic data, and it is determined whether the target feature matches a preset verification success feature, specifically comprising:

[0087] In the temporary release channel, the security link connection state of the encrypted network request and the interactive response of the application network request are monitored in parallel;

[0088] When the success response packet corresponding to the interactive response is obtained, the success response packet is analyzed in the application layer load, and the business status code field and the user identity field are extracted;

[0089] The user identity field is sent to an independent authentication verification microservice decoupled from the WeChat applet backend for authenticity verification, and the returned verification result is received;

[0090] When the security link connection state is successful, the business status code field represents success, and the authenticity verification result is true, it is determined that the target feature matches the verification success feature.

[0091] Monitoring the security link connection state of encrypted network requests: All encrypted network requests based on protocols such as HTTPS are monitored to determine whether the TLS security link between the terminal and the WeChat server is successfully established. This is done by capturing and analyzing specific signaling sequences in the TLS handshake protocol (such as Client Hello, Server Hello, Change Cipher Spec, Finished). Monitoring the interaction response of application-type network requests: The specific business requests between the terminal and the WeChat applet backend service (such as API calls to submit mobile phone numbers and verification codes) are monitored. Specifically, the captured HTTP response packets returned by the server after these business requests are completed. When the interaction response is monitored and confirmed as a successful response packet (for example, the HTTP status code is 200), the system will analyze the payload (Payload) of the response packet. This payload is usually a JSON or XML formatted data body, which contains detailed results of business execution. Extract key fields from the successful response packet, including the business status code field and the user identity field. Business status code field: Parse fields such as "code": 0 or "status": "success" from the payload. This code is more specific than the HTTP status code and is defined by the business logic of the WeChat applet, indicating whether the authentication is successful or failed at the business level. User identity field: At the same time, parse the user's unique identifier associated with this successful authentication, such as an encrypted OpenID, UnionID, or session token (Token). The system will send the user identity field returned by the WeChat applet backend to an authentication verification microservice independent of the WeChat applet backend. The independent microservice will perform cryptographic verification, check the validity period and signature of the token to ensure that it is real, legal and not expired. Finally, the system will summarize the evidence collected in the previous three steps and perform logical decision-making. Only when the following three conditions are met at the same time, the authentication is finally determined to be successful: the security link connection state is successful, ensuring that the communication pipeline itself is secure and connected; the business status code field represents success, ensuring that the WeChat applet's business logic confirms that the authentication operation is successful; the authenticity verification result is true, ensuring that the token representing the user's identity is real and valid.

[0092] In some embodiments, the activating the third policy to enable the terminal to obtain full Internet access includes:

[0093] Switching the domain name system resolution server address of the terminal from a first address serving the second policy to a public network domain name system server address;

[0094] Initiating a domain name system resolution request for a preset public network domain name to the terminal, and determining whether the terminal can obtain a response from the public network domain name system server address;

[0095] Upon confirming that the terminal can obtain a response from the public DNS server address, the permission level of the network session is raised, the terminal is allowed to access resources on the Internet, and the status of the network session is marked as authenticated.

[0096] Switching the DNS server address of the terminal from the "first address" serving the second policy to a public DNS server address. During the validity of the second policy, the DNS query of the terminal is directed to a dedicated, internal DNS server (the first address). This server is like a special navigation that only includes WeChat-related locations, and it can only correctly resolve the domain names necessary for the operation of WeChat mini programs. For any other Internet domain name, it may not be able to resolve or may resolve to an incorrect address. In order to give the terminal full Internet access permission, its DNS query must be handed over to a global, public navigation that includes all website addresses, i.e., a public DNS server. This is the core operation of permission upgrade. Through this switch, the terminal can now obtain the correct IP address of any legal domain name on the Internet, which is a prerequisite for accessing these resources. After switching the DNS configuration, the system does not passively wait, but actively initiates a DNS resolution request to the terminal for a preset public domain name and judges whether the terminal can obtain a correct response from the new public DNS server. This step is to verify whether the switching operation has truly taken effect on the terminal. Due to DNS cache, network delay, or configuration push failure, the actual DNS resolution behavior of the terminal may not have changed immediately. The system sends a resolution request to the terminal for a known public domain name (such as www.example.com or www.qq.com) and listens to its response. If the IP address returned by the terminal is the correct address from the public DNS, it proves that the switch is successful. If the returned address is still the old internal DNS address or the resolution fails, it indicates that the switch has not taken effect. After confirming that the DNS switch has taken effect, the system raises the permission level of the network session: at the policy execution point of the system, the permission identification of this specific network session is raised from temporary release to full access. This means that the network device will allow IP packets of this session to access any IP address on the Internet, rather than being limited to the IP in the previous whitelist. Allowing the terminal to access resources on the Internet: this is a direct manifestation after permission upgrade. From now on, any application on the terminal, such as a browser or an APP, can freely establish a connection with any server on the Internet and exchange data. Marking the status of the network session as authenticated: in the session manager of the system, the status field of the session is updated to authenticated. This marks that the user has completed the entire process of authenticated release.

[0097] In some embodiments, the asynchronously cleaning the session data of the second policy after the preset delay time specifically comprises:

[0098] In the authentication process, the network traffic of the network session is sampled in a fixed time window, and the total packet quantity in each time window is counted. The total packet quantity is compared with a plurality of preset threshold intervals to map a corresponding traffic activity level;

[0099] According to the traffic activity level, a predefined negative correlation mapping table is queried to determine the delay time;

[0100] An asynchronous cleaning task is started, and a time is counted from activating the third policy. When the delay time is reached, a cleaning operation is performed to release the domain name system resolution resources occupied by the second policy.

[0101] The system periodically takes a "snapshot" sample of all network traffic belonging to this network session with a fixed time window (e.g., every 30 seconds). Within each time window, the system does not care about the specific content of the packets, but simply counts the total number of packets flowing through this session. This is a bottom-level network metric that effectively reflects the frequency of user interactions. The number of packets counted is compared with a pre-set multiple threshold intervals. For example: [0-10) packets / window → low activity; [10-100) packets / window → medium activity; [100 and above) packets / window → high activity. This step converts abstract user behavior into an objective, quantifiable traffic activity level. This is like establishing a dynamic profile for the user's network usage habits. High activity means that the user is interacting frequently with the applet (e.g., downloading resources, multiple API calls), while low activity may mean that the user is reading static pages or operations have been completed. The system determines a specific delay time based on the determined traffic activity level by querying a pre-defined negative correlation mapping table. Negative correlation mapping example: high activity → short delay time (e.g., T_high = 2 seconds); medium activity → medium delay time (e.g., T_medium = 5 seconds); low activity → long delay time (e.g., T_low = 10 seconds). For high-activity users, the system determines that they may be quickly and intensively completing the authentication process. Therefore, after their successful authentication, the waiting time can be shortened more aggressively to quickly reclaim resources and improve system efficiency. For low-activity users, the system determines that their operation pace is slow and they may still have unfinished requests or upcoming requests after successful authentication. Therefore, the waiting time needs to be extended more conservatively to prioritize the continuity of their experience and avoid network errors in the applet due to premature resource reclamation. While activating the third strategy (i.e., the terminal has obtained complete Internet access permission), the system starts an asynchronous cleanup task in the background and begins timing. Asynchronous means that this task will not block the main process, and the user's Internet access will not be affected. Delayed execution: the system waits until the timer reaches the dynamic delay time calculated in the second step. After the time is up, the cleanup task is executed, releasing the dedicated DNS resolution resources occupied by the second strategy. This includes unbinding the session from the internal DNS server and cleaning up related routing rules or session entries. The core purpose of introducing a delay is to provide a safe buffer period. During this period, the second strategy (applet-specific channel) and the third strategy (global Internet channel) are activated in parallel. This ensures that the user's any ongoing requests in the applet (such as uploading images, the last step of confirmation) can be completed smoothly using the temporary channel at the moment they obtain full Internet access permission, achieving an absolutely smooth and non-intrusive transition from temporary release to complete release.Compared with using a fixed, long delay time set for security, this delay based on activity dynamically calculated can recycle resources earlier in most cases, thereby significantly improving the system's resource utilization efficiency without sacrificing experience.

[0102] Figure 2 is a flowchart of the process of connecting WiFi through the WeChat applet in the embodiments of the present application, as shown in Figure 2 After the guest connects to the hotel Wi-Fi, the phone will automatically pop up an authentication portal page, and the guest clicks "WeChat applet connects Wi-Fi" on the authentication page. The system calls the WeChat applet, the guest allows the applet to obtain his mobile phone number, displays the member registration page, and prompts to input the surname, name, email and other information. The applet displays the member registration form and requires the guest to supplement personal information. The system queries whether the guest is already a hotel member according to the mobile phone number: yes → directly enter the next authentication step; no → enter the next step to determine whether to register as a member. The system determines whether the guest is willing to register as a member: yes → submit a member registration request, and after successful registration, continue the authentication; no → directly enter the authentication process. If the guest chooses to register as a member, the system submits his information to the member system through an interface to complete member registration. After successful authentication, the page jumps to the completion page in the applet, prompting the guest that he has successfully connected to Wi-Fi. The system records the guest's identity information and device MAC address, allowing him to roam in the hotels under the group for 180 days without repeating the authentication.

[0103] Figure 3 is a flowchart of the process of calling the applet to connect WiFi by scanning the code in the embodiments of the present application, as shown in Figure 3 The guest scans a specific public number QR code, and after following, he will automatically receive a message containing a "WeChat applet connects Wi-Fi" card. The guest clicks the card to enter the authentication process. Alternatively, the guest can directly scan a QR code dedicated to the applet to call the applet immediately, skipping the step of following the public number. Through any of the above two ways, the guest will be redirected to the WeChat applet and asked to allow the applet to obtain his mobile phone number. The applet will show the guest the membership agreement and guide him to register as a member. The system determines whether the guest is already a member according to the mobile phone number: yes → directly submit an authentication request; no → prompt the guest to register as a member. The system asks the guest whether he is willing to register as a member immediately: yes → submit a member registration request through an interface, and after successful registration, enter the authentication step; no → directly enter the authentication step. After completing the membership determination, the system submits a network access authentication request. After success, the page jumps to the completion page of the applet. (Branch step) If the guest chooses to register, the system completes the submission of the member information at this step. After successful authentication, the system records the user's identity and device information, allowing him to roam in the hotels under the group for 180 days without repeating the authentication.

[0104] Figure 4 is a flowchart of the process of connecting WiFi through the applet by the computer in the embodiment of the application, as shown in Figure 4 After the computer connects to Wi-Fi, an authentication page pops up, the guest scans the two-dimensional code on the page with the mobile phone (using 4G traffic), the mobile phone will jump to the WeChat applet and allow the phone number to be obtained; the system then determines whether the phone number has the right to access the Internet, if not, it will pop up an interface on the mobile phone to allow the computer to access the Internet, after the guest confirms to allow, the computer can successfully access the Internet; at the same time, the system will perform the member status judgment and registration process in parallel, guiding non-member guests to complete member registration.

[0105] Figure 5 is a flowchart of the process of roaming across hotels in the embodiment of the application, as shown in Figure 5 When the guest stays in a hotel under the group again and connects to Wi-Fi, the system will first detect whether the terminal device is within the 180-day roaming validity period; if it has been registered for roaming, the system will automatically identify its identity, complete the registration in the current hotel and directly release the Internet access, realizing the no-sense authentication; if it has not been registered or the roaming has expired, the system will guide the guest to re-authenticate (such as WeChat applet authentication) to restore its Internet access right and roaming status.

[0106] The above describes a temporary release method of WeChat applet authentication in the embodiment of the application, and the computer system in the embodiment of the application is described in detail in combination with the above temporary release method of WeChat applet authentication.

[0107] Please refer to Figure 6 for an exemplary hardware structure diagram of the computer system in the embodiment of the application.

[0108] In some embodiments, the computer system 600 includes a computer device, which can be a terminal device. The computer device includes a processor 601, a memory 602, a sensor module 603, a communication module 604, an input device 605, and an output device 606 connected through a system bus. The processor 601 of the computer device is used to provide computing and control capabilities. The memory 602 of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The database is used to store data.

[0109] Those skilled in the art can understand that Figure 6The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. A specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0110] In some embodiments of the present application, a computer readable storage medium is provided, including instructions which, when executed on the computer system 600, can cause the computer system 600 to perform the temporary release method of WeChat applet authentication in the embodiments of the present application.

[0111] In some embodiments of the present application, a computer program product is also provided, which, when executed on the computer system 600, causes the computer system 600 to perform the temporary release method of WeChat applet authentication in the embodiments of the present application.

[0112] The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the foregoing embodiments of the present application have been described in detail, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

[0113] In the above embodiments, all or part of them can be realized by software, hardware, firmware or any combination thereof. When realized by software, all or part of them can be realized in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another, for example, the computer instructions can be transferred from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (for example, floppy disk, hard disk, magnetic tape), optical media (for example, DVD), or semiconductor media (for example, solid state disk) and the like.

[0114] Those skilled in the art can understand that all or part of the processes in the above-mentioned method embodiments can be implemented by a computer program instructing relevant hardware to complete, the program can be stored in a computer readable storage medium, and the program can include the processes of the above-mentioned method embodiments when executed. The aforementioned storage medium includes ROM or random storage memory RAM, magnetic disc or optical disc and various storage code medium.

Claims

1. A method for temporarily allowing WeChat Mini Program authentication, characterized in that, include: A predefined Domain Name System (DNS) policy template set is provided. The DNS policy template set includes a first policy for initial network connectivity detection of the terminal, a second policy for ensuring the operation of the WeChat Mini Program, and a third policy after successful authentication. When the terminal accesses the WiFi network, a network session is created for the terminal, the DNS policy template set is preloaded into the network session, and the first policy is activated to provide a network access entry point. Based on the entry point, real-time deep packet inspection and context association analysis are performed on all network requests sent by the terminal. Target parameters in the network requests are extracted to form a multi-dimensional feature vector. The multi-dimensional feature vector is matched with a preset authentication intent to obtain a confidence level. When the confidence level exceeds a preset matching threshold, the first strategy is disabled and the second strategy is activated to establish a temporary access channel for the WeChat mini program. Based on the temporary access channel, continuously monitor the traffic data to the WeChat Mini Program backend service, obtain target features from the traffic data, and determine whether the target features match the preset verification success features. When the target feature matches the preset verification success feature, the third strategy is activated to enable the terminal to obtain full Internet access, and after a preset delay time, the session data of the second strategy is asynchronously cleared.

2. The temporary release method for WeChat Mini Program authentication according to claim 1, characterized in that, The process of performing real-time deep packet inspection and contextual analysis on all network requests issued by the terminal based on the entry point, and extracting target parameters from the network requests to form a multi-dimensional feature vector, specifically includes: The network request is parsed using an application layer protocol, and heterogeneous raw parameters are obtained from the parsed header fields and payload content. The heterogeneous raw parameters include terminal type identifier, target domain name, resource path and source page. The heterogeneous raw parameters are converted into structured data objects, and the structured data objects are added to the historical request sequence corresponding to the network session in chronological order. If the source page in the network request points to the resource path of the authentication portal page in the historical request sequence, then the discrete request objects are linked into a behavioral link based on the page jump relationship. Based on the terminal type identifier, the target domain name of the request, and the resource path, a first feature sub-vector representing the static characteristics of the network request is generated. Based on the sequence of target domain names of the request contained in the behavior link, a second feature sub-vector representing the dynamic behavior sequence of the user is generated. The first feature sub-vector and the second feature sub-vector are concatenated to form the multidimensional feature vector.

3. The temporary release method for WeChat Mini Program authentication according to claim 2, characterized in that, The step of linking discrete request objects into behavioral chains based on page navigation relationships includes: Traverse the historical request sequence and determine the first request object that matches the resource path with the Uniform Resource Locator of the authentication portal page as the starting node of the behavior chain; For each request object in the historical request sequence after the starting node, verify whether the source page parameter points to the resource path corresponding to the end node of the currently constructed behavior link; If so, the currently verified request object is added as a new end node of the behavior chain; otherwise, the currently verified request object is recorded as a pending node, and a new potential behavior chain is created for the pending node. An idle duration timer is started for each of the aforementioned behavior links. If a target behavior link does not extend a new node before the idle duration timer expires, the target behavior link is determined to be invalid and removed from the context of the network session.

4. The temporary release method for WeChat Mini Program authentication according to claim 3, characterized in that, The step of matching the multidimensional feature vector with the preset authentication intent to obtain the confidence level includes: The multidimensional feature vectors are input into the Boolean decision channel, the probabilistic decision channel, and the sequence decision channel, respectively. The Boolean decision channel compares the target domain name in the multidimensional feature vector with a predefined set of key domain names and outputs a binary judgment signal. The probabilistic decision channel outputs a preliminary probability value based on the static features of the network request. The sequence decision channel outputs a sequence matching score based on the matching completeness of the behavior link with the preset authentication process template. The set of key domain names includes the official domain name required for the operation of the WeChat mini program and the feature domain name used to distinguish the network probing behavior of different terminal manufacturers. A dynamic weight is assigned to the binary determination signal, the preliminary probability value, and the sequence matching score. When the binary determination signal is true, the dynamic weight of the binary determination signal is set to the maximum value. Otherwise, the weight ratio of the preliminary probability value and the sequence matching score is adjusted according to the real-time load of the current network session. The output results of the three channels are combined into an intent confidence score according to the weighted fusion strategy. The intention confidence is smoothed to obtain an intermediate confidence level. The intermediate confidence level is then weighted and averaged with the baseline confidence level based on the current time period and the terminal's historical reputation to output the confidence level.

5. The temporary release method for WeChat Mini Program authentication according to claim 1, characterized in that, The step of obtaining target features from the traffic data and determining whether the target features match preset verification success features specifically includes: Within the temporary access channel, the secure link connection status of encrypted network requests and the interactive response of application network requests are monitored in parallel. When the success response packet corresponding to the interaction response is obtained, the application layer payload is parsed to extract the business status code field and the user identity identifier field. The user identity field is sent to an independent authentication and verification microservice decoupled from the WeChat Mini Program backend for authenticity verification, and the returned authenticity verification result is received. When the security link connection status is successful, the service status code field indicates success, and the authenticity verification result is true, the target feature is determined to match the verification success feature.

6. The temporary release method for WeChat Mini Program authentication according to claim 5, characterized in that, Activating the third strategy to grant the terminal full internet access includes: Switch the domain name system resolution server address of the terminal from the first address serving the second policy to the public domain name system server address; Initiate a Domain Name System (DNS) resolution request for a preset public domain name to the terminal, and determine whether the terminal can obtain a response from the public domain name system server address; After confirming that the terminal can obtain a response from the public domain name system server address, the privilege level of the network session is elevated, allowing the terminal to access resources on the Internet, and the status of the network session is marked as authenticated.

7. The method according to claim 1, characterized in that, The step of asynchronously clearing the session data of the second strategy after a preset delay time specifically includes: During the authentication process, network traffic of the network session is sampled at fixed time windows, and the total number of data packets in each time window is counted. The total number of data packets is compared with multiple preset threshold intervals to map to the corresponding traffic activity level. Based on the traffic activity level, a predefined negative correlation mapping table is queried to determine the delay time; An asynchronous cleanup task is initiated, starting the timer from the activation of the third strategy. Once the delay time is reached, a cleanup operation is performed to release the domain name system resolution resources occupied by the second strategy.

8. A computer system comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-7.

Images