Multi-platform client access method and system based on URL (Uniform Resource Locator) routing and storage medium
By establishing a unified routing mechanism and server-side risk control engine through a multi-platform client access method based on URL routing, the shortcomings of cross-platform clients in terms of consistency, single rules, and security are resolved, and unified control and real-time risk protection for multi-platform access are achieved.
Patent Information
- Application Number
- CN202511582253.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-31
- Publication Date
- 2026-02-10
AI Technical Summary
Existing client routing technologies have significant shortcomings in cross-platform consistency, single routing rules, dynamic configurability, and security risk prevention and control. They lack unified standards and real-time risk identification and security management mechanisms.
A multi-platform client access method based on URL routing is adopted. By establishing a unified routing mechanism and server-side risk control engine, multi-platform access permission management, real-time risk assessment and remote policy control are realized. Client functions are abstracted into logical functional units and given unique names. The server establishes a routing storage association table to perform permission and precondition verification.
It achieves unified access control for clients across multiple platforms, improves cross-platform consistency, dynamic configurability and security, and provides centralized management and real-time risk protection capabilities.
Smart Images
Figure CN121509329A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communications, and more particularly to a method, system, and storage medium for accessing multi-platform clients based on URL routing. Background Technology
[0002] In existing technologies, client-side routing typically relies on local routing table mapping mechanisms, enabling page-to-page navigation and initial decoupling of business modules. However, such routing schemes still have many limitations: for example, route mapping only supports page and pop-up navigation, not some logical execution units such as simple function calculations, application permissions like camera permissions, and other input / output models; different platforms such as Android, iOS, HarmonyOS, Flutter, Web, and mini-programs often employ their own independent routing implementations, lacking a unified standard; routing rules are mostly statically configured, with weak dynamic update capabilities, making it difficult to support remote policy control and canary releases; furthermore, existing technologies generally lack real-time risk identification and security control mechanisms for routing access behavior, resulting in insufficient protection against security threats such as malicious calls and unauthorized access. In summary, existing client-side routing technologies still have significant shortcomings in cross-platform consistency, single routing rules, dynamic configurability, and security risk prevention, urgently requiring an improved routing method that achieves cross-platform consistency, centralized management, and secure access control. Summary of the Invention
[0003] Purpose of the invention: In order to overcome the shortcomings of the existing technology, the present invention provides a method, system and storage medium for accessing multi-platform clients based on URL routing. By establishing a unified routing mechanism and server-side risk control engine, it realizes access permission management, real-time risk assessment and supports remote policy control of client routing response across multiple platforms.
[0004] Technical solution: To achieve the above objectives, the present invention provides a multi-platform client access method based on URL routing, comprising the following steps:
[0005] Step 1: Abstract several functions of the clients on different platforms into several logical functional units, and use URLs to uniquely name and identify each logical functional unit.
[0006] Step 2: Clients on different platforms register their respective logical functional units, establishing a mapping relationship between logical functional unit identifiers and routing paths in the routing table.
[0007] Step 3: The server obtains the mapping relationship between the logical functional unit identifiers and the routing paths in the clients of different platforms, and establishes a routing storage association table; and the server obtains the interface data and interface access permissions corresponding to several logical functional units in the clients of different platforms.
[0008] Step 4: The server obtains the identifiers of several logical functional units in the clients of different platforms, and associates and binds the identifier of each logical functional unit in the clients of different platforms with the interface data corresponding to that logical functional unit to form a context association between several routes and interface data.
[0009] Step 5: The client initiates a routing request. The server performs access permission management and precondition verification on the routing request. If the verification is successful, the server records the client's current route and returns the corresponding target route to the client. The client then executes the target route.
[0010] Step 6: The client initiates an interface request. The server performs access permission management, precondition and context verification on the interface request. If the verification is successful, the server returns the corresponding interface data to the client, and the client can continue to access the interface.
[0011] Furthermore, the logical functional units are represented in the form of pages, pop-ups, background services, functions, logic blocks, and system API calls; URLs are used to uniquely name and identify several logical functional units, and a grouping plus name naming method is used to uniquely name the logical functional units.
[0012] Furthermore, in step two, clients on different platforms can parse the received route to obtain the route path based on the mapping relationship between the logical function unit identifier and the route path in the route, and match the logical function unit according to the parsed route path, and the client executes the corresponding logical function unit.
[0013] Furthermore, in step three, the established route storage association table includes the route version, route path, route prerequisites, route access permissions, and the mapping relationship between the logical functional unit identifier and the route path in the route of the client on different platforms; the route prerequisites include login account, real name, geographical location, and risk verification.
[0014] Furthermore, when a client initiates a routing request, it includes the following steps:
[0015] Step 1-1: Perform route access permission verification on the route request. If the route access permission verification fails, return an unauthorized route to the client. If the route request access permission verification passes, perform precondition verification.
[0016] Steps 1-2: Perform route precondition validation on the route request. If the route precondition validation fails, the server returns the precondition validation route to the client. If the precondition validation passes, the server returns the corresponding target route to the client. The client then parses the route and executes the corresponding logical function unit based on the returned target route.
[0017] Furthermore, when a client initiates an interface request, the following steps are included:
[0018] Step 2-1: Perform interface access permission verification on the interface request. If the interface access permission verification fails, return an unauthorized route to the client. If the interface access permission verification passes, perform precondition verification.
[0019] Step 2-2: Perform precondition validation on the interface request. If the precondition validation fails, return the precondition validation route to the client. If the precondition validation passes, perform context association validation.
[0020] Steps 2-3: Perform interface context association verification on the interface request. If the interface context association verification fails, return a verification route to the client. If the context association verification passes, the interface request is verified and the server returns the corresponding interface data to the client.
[0021] Furthermore, a multi-platform client access system based on URL routing, the apparatus for implementing the aforementioned multi-platform client access method based on URL routing, includes:
[0022] Routing registration module: Used for clients on different platforms to register several logical functional units, and to establish a mapping relationship between logical functional unit identifiers and routing paths in the routing table;
[0023] Route resolution and verification module: When the server receives a route request, it verifies the route access permissions and route prerequisites, and generates the target route;
[0024] The route distribution module is used by the server to distribute the target route generated in the route resolution and verification module to the client.
[0025] Context association module: Used to associate user operations with the corresponding interface data that implements the route, and to verify risky operations.
[0026] Furthermore, a storage medium stores an executable program, which, when executed by a processor, enables the access method for a multi-platform client based on URL routing.
[0027] Beneficial effects: The URL routing-based multi-platform client access method of the present invention uses the URL routing-based multi-platform client access system as a unified input-output model routing system, enabling logical functional units that conform to the model to be routed or executed. At the same time, through centralized management of routing access permissions, precondition interception, and context association by the server, it realizes refined security access control and centralized management, solving problems such as inconsistent routing standards, single rules, and weak risk control capabilities across platforms; thus, it achieves the technical effect that multi-platform clients can access the same server. Attached Figure Description
[0028] Figure 1 This is a flowchart illustrating the access method for multi-platform clients based on URL routing. Detailed Implementation
[0029] The invention will now be further described with reference to the accompanying drawings.
[0030] like Figure 1 As shown, the access method for multi-platform clients based on URL routing includes the following steps:
[0031] Step 1: Abstract several functions of the clients on different platforms into several logical functional units, and use URLs to uniquely name and identify each logical functional unit; the different platforms include Android, iOS, HarmonyOS, Flutter, Web, and mini-programs, etc.
[0032] Step 2: Clients on different platforms register their respective logical functional units, establishing a mapping relationship between logical functional unit identifiers and routing paths in the routing table. For example, the identifier of the logical functional unit for making a phone call is defined as / app / call?mobile=13399998888, where / app / call is set as the routing path and mobile is the phone number to be dialed.
[0033] Step 3: The server obtains the mapping relationship between the logical functional unit identifiers and the routing paths in the clients of different platforms, and establishes a routing storage association table; and the server obtains the interface data and interface access permissions corresponding to several logical functional units in the clients of different platforms.
[0034] Step 4: The server obtains the identifiers of several logical functional units in the clients of different platforms, and associates and binds the identifier of each logical functional unit in the clients of different platforms with the interface data corresponding to that logical functional unit to form a context association between several routes and interface data.
[0035] Step 5: The client initiates a routing request. The server performs access permission management and precondition verification on the routing request. If the verification is successful, the server records the client's current route and returns the corresponding target route to the client. The client then executes the target route.
[0036] Step 6: The client initiates an interface request. The server performs access permission management, precondition and context verification on the interface request. If the verification is successful, the server returns the corresponding interface data to the client, and the client can continue to access the interface.
[0037] The logical functional units are represented in various forms, including pages, pop-ups, background services, functions, logic blocks, and system API calls. URLs are used to uniquely name and identify several logical functional units, and a grouping and naming method is used to uniquely name the logical functional units.
[0038] For example, the logical function unit for the login page is named / main / login?zzkjtpp=1¶m=1, the logical function unit for obtaining camera permissions is named / require / camera?zzkjtpp=1, and the logical unit for calculating complex coupons is named / coupon / compute?zzkjtpp=1&id=1.
[0039] The logical functional unit format includes logical unit paths, parameter key-value pairs, etc. Logical functional units include basic network request modules, login modules, location modules, real-name authentication modules, risk verification modules, and any functional units conforming to the input-output model, such as pages, pop-ups, and logic blocks, which are divided according to installation business functions. The risk verification module includes puzzle and trajectory verification. Login pages, update pop-ups, background audio playback services, complex coupon combination calculations, obtaining camera permissions, and making phone calls are used as routes. The corresponding function of each logical functional unit is the route. For example, if the client wants to implement the function of making a phone call, it sends the "make phone call" request as a route to the server. The server then performs access permission management and precondition verification based on the received route. After successful verification, it returns the target route. The client parses the target route to obtain the target route path and executes the logical functional unit corresponding to that route path.
[0040] Taking the identifier of a logical functional unit and the corresponding mapping relationship of the routing path as an example, the identifier of a certain logical functional unit is as follows: https: / / mobile-battery.zzkj.com / main / login?zzkjtpp=1¶m=1;
[0041] The URL uses the HTTPS protocol as the secheme. Considering that HTTPS routes can be directly accessed by browsers, there are compatibility issues between old and new versions in the client app. Therefore, the old version route in the app can be redirected to the web version. `mobile-battery.zzkj.com` represents the current business scope. `main / login` represents the route path, ensuring it is unique within the business scope. A question mark (?) is used as the input parameter, such as `zzkjtpp=1` followed by `param=1`. `zzkjtpp=1` indicates different platform responses; for example, `zzkjtpp=1` represents the native platform response route, while `zzkjtpp=0` or no value indicates the web platform response route. This allows specifying response routes for the native and web platforms for the client app's logical functional units. `param=1` indicates that any parameter can be input, and it can be encrypted, encoded, etc., freely customized according to actual business needs.
[0042] In step two, clients on different platforms can parse the received route to obtain the route path based on the mapping relationship between the logical function unit identifier and the route path in the route, and then match the logical function unit according to the parsed route path. The client then executes the corresponding logical function unit. For example, if a client app receives the target route https: / / mobile-battery.zzkj.com / main / login?zzkjtpp=0¶m=1, the route path parsed from the target route is / main / login; zzkjtpp=0, matching the logical function unit as the login page, which is executed in a web mode. In this case, it is dispatched to the app's native webview for execution.
[0043] In step three, the established route storage association table includes the route version, route path, route prerequisites, route access permissions, and the mapping relationship between the logical functional unit identifier and the route path in the route of the client on different platforms; the route prerequisites include login account, real name, geographical location, and risk verification.
[0044] In step four, the server obtains the identifiers of several logical functional units in the clients of different platforms, and associates and binds the identifier of each logical functional unit in the clients of different platforms with the interface data corresponding to that logical functional unit, forming a context association between the route and the server's interface; for example, if the login route requires the interface https: / / mobile-battery.zzkj.com / api / login, then the login route is associated and bound with the login interface data.
[0045] When a client initiates a routing request, the following steps are included:
[0046] Step 1-1: Perform route access permission verification on the route request. If the route access permission verification fails, return an unauthorized route to the client. If the route request access permission verification passes, perform precondition verification.
[0047] Steps 1-2: Perform route precondition validation on the route request. If the route precondition validation fails, the server returns the precondition validation route to the client. If the precondition validation passes, the server returns the corresponding target route to the client. The client then parses the route and executes the corresponding logical function unit based on the returned target route.
[0048] Steps 1-2: Perform pre-condition validation on the routing request. If the pre-condition validation fails, the server returns the pre-validation route to the client. If the pre-condition validation succeeds, the server returns the corresponding target route path to the client. The client then parses the route and executes the corresponding logical functional unit based on the returned target route path. The pre-condition validations are for login account, real name, geolocation, and risk verification. If the login account validation fails, the server returns the login route, and the client re-logins. After successful login, the routing request continues. Other pre-condition validations are performed in the same way as the login account validation.
[0049] For example, if the client has a button B, and the client clicks button B, the server will receive the button B. The specific steps are as follows:
[0050] When the server receives a request from button B, if it has already recorded button B and its route, or if button B's request includes a route, it sequentially verifies the route access permissions and route preconditions. Assuming the client clicks button B on an activity that selects existing users, access to the route requires the user to have purchased a device and be logged in. The route path and parameters are ` / main / coupon-activity?zzkjtpp=0`. The server needs to perform login verification. If the preconditions are not met, the server returns a login route to the client, including a route indicating successful login.
[0051] / main / login?zzkjtpp=0¶m=1&target=%2Fmain%2Fcoupon-activity%3Fzzkjtpp%3D0; After the client receives the login route returned by the server, it is redirected to the login page. After the client successfully logs in, it continues to respond to routes.
[0052] In the routing process, the server needs to perform permission checks on the selected group of long-term users. If the permissions are not met, the server can return other routes to the client, such as more active routes. After receiving the target route returned by the server, the client executes the target route. It can be seen that the client's routing request and the target route ultimately returned by the server can be different. Therefore, different conditions can be inserted into the preconditions, and the system can dynamically adapt to more flexible business capabilities.
[0053] When a client initiates an API request, the following steps are included:
[0054] Step 2-1: Perform interface access permission verification on the interface request. If the interface access permission verification fails, return an unauthorized route to the client. If the interface access permission verification passes, perform precondition verification.
[0055] Step 2-2: Perform precondition validation on the interface request. If the precondition validation fails, return the precondition validation route to the client. If the precondition validation passes, perform context association validation.
[0056] Steps 2-3: Perform interface context association verification on the interface request. If the interface context association verification fails, return a verification route to the client. If the context association verification passes, the interface request is verified and the server returns the corresponding interface data to the client.
[0057] For example, the device page route is / main / device-info?zzkjtpp=1, and the service interface data is / api / device / detail; the personal center page route is / main / center-info?zzkjtpp=1, and the service interface data is / api / user / info. If the server records the current route as the device page route / main / device-info?zzkjtpp=1, and the interface request initiated is / api / user / info, then the interface request is determined to be abnormal, and a risk control route is returned to the client, such as the slider verification route, allowing the user to manually remove the risk control.
[0058] The precondition verification includes verification of login account, real name, geolocation, and risk verification. First, login account verification is performed. If login account verification fails, a login route is returned to the client, which attempts to log in again. Upon successful login, another routing request is made. Login account verification is performed again within this routing request. If login account verification fails more than three times, a risk verification is performed. If login account verification passes, real name verification is performed. If real name verification fails, a real name route is returned to the client, which performs real name verification. Upon successful real name verification, another routing request is made. Real name verification is performed again within this routing request. If real name verification fails more than three times, a risk verification is performed. If real name verification passes, geolocation verification is performed. If geolocation verification fails, a geolocation route is returned to the client, which confirms its geolocation. Upon confirmation, another routing request is made. Geolocation verification is performed again within this routing request. If geolocation verification fails more than three times, a risk verification is performed.
[0059] The risk verification process involves the server sending a risk route to the client, the client parsing the risk route and executing its operations, and then sending risk-passed data back to the server. Once the server receives this data, the risk verification is considered successful. This risk verification can be performed on the platform's client side using a slider verification or a CAPTCHA verification.
[0060] A multi-platform client access system based on URL routing, the apparatus being used to implement the aforementioned multi-platform client access method based on URL routing, comprising:
[0061] Routing registration module: Used for clients on different platforms to register several logical functional units, and to establish a mapping relationship between logical functional unit identifiers and routing paths in the routing table;
[0062] Route resolution and verification module: When the server receives a route request, it verifies the route access permissions and route prerequisites, and generates the target route;
[0063] The route distribution module is used by the server to distribute the target route generated in the route resolution and verification module to the client.
[0064] Context association module: Used to associate user operations with the corresponding interface data that implements the route, and to verify risky operations.
[0065] A storage medium containing an executable program that, when executed by a processor, enables the aforementioned URL-routing-based multi-platform client access method.
[0066] Example
[0067] Taking the "Create Order" page function as an example, this section explains the interaction between the client and server on different platforms. First, the "Create Order" page function is abstracted into a logical functional unit, and each unit is uniquely named. Each platform's client also abstracts the "Create Order" page function into a logical functional unit and assigns it a unique name. A mapping relationship is established between the logical functional units of the "Create Order" page in each platform's client and the routing path in the "Create Order" page's route. The server establishes a route storage association table based on the mapping relationship between the logical functional units of the "Create Order" page and the routing path in the "Create Order" page's route. This table includes the route version, routing path, route preconditions, route access permissions, and the mapping relationship between the logical functional unit identifier and the routing path in the "Create Order" page's route in each platform's client. The route preconditions include login account, real-name authentication, geographical location, and risk verification. The server obtains the interface data and access permissions corresponding to the logical functional units of the order creation page in the clients of different platforms; the server obtains the identifiers of the logical functional units of the order creation page in the clients of different platforms, and associates and binds the identifiers of the logical functional units of the order creation page in the clients of different platforms with the interface data corresponding to the logical functional units, forming a contextual association between the route of the order creation page and the interface data.
[0068] When a client on any platform accesses the "Create Order" page, a routing request is first made. The client sends a routing request for the "Create Order" page. Upon receiving this request, the server performs access permission management and precondition validation. If access permission management fails, an unauthorized route ` / main / no / authorized?target=1001` is returned to the client. The client parses the unauthorized route and executes the operation based on its path, displaying a generic "No Permission" page. If login verification fails in the precondition validation, the route ` / main / login?target=1001` is returned to the client. The client parses the route, executes the operation, and displays the login page for login. If real-name verification fails in the precondition validation, the route ` / main / realname?target=1001` is returned to the client. The client parses the route, executes the operation, and displays the real-name login page for real-name login.
[0069] When the access permission management and precondition validation of the route pass, the server returns the target route for the Create Order page. Because the server stores the route in an association table, it knows the route path in the Create Order page route, and the target route contains the route path in the Create Order page route. After receiving the target route, the client of this platform parses it to obtain the route path in the Create Order page route. The client then executes the Create Order page function based on the route path in the Create Order page route and displays the Create Order page.
[0070] After the platform's client displays the created order page, it makes interface requests, including requests for product information and order placement data for the created order page. When the server receives these requests, it performs access control and precondition checks. If the access control and precondition checks pass, it performs interface context association checks. This check compares the interface requests received by the server with the route for the created order page. If the comparison result is inconsistent with the context association of the route and interface data, the interface context association check fails. When all three checks—access control, preconditions, and interface context association—pass, the server returns the product information and order placement data to the client. The client then displays these data on the created order page, completing the client's order page creation functionality.
[0071] The above description is merely a preferred embodiment of the present invention. Those skilled in the art can make several modifications and optimizations based on the above disclosure without departing from the basic principles described above. These modifications and optimizations should be considered within the scope of protection as understood by the present invention.
Claims
1. A method for accessing multi-platform clients based on URL routing, characterized in that: Includes the following steps: Step 1: Abstract several functions of the clients on different platforms into several logical functional units, and use URLs to uniquely name and identify each logical functional unit. Step 2: Clients on different platforms register their respective logical functional units, establishing a mapping relationship between logical functional unit identifiers and routing paths in the routing table. Step 3: The server obtains the mapping relationship between the logical functional unit identifiers and the routing paths in the clients of different platforms, and establishes a routing storage association table; and the server obtains the interface data and interface access permissions corresponding to several logical functional units in the clients of different platforms. Step 4: The server obtains the identifiers of several logical functional units in the clients of different platforms, and associates and binds the identifier of each logical functional unit in the clients of different platforms with the interface data corresponding to that logical functional unit to form a context association between several routes and interface data. Step 5: The client initiates a routing request. The server performs access permission management and precondition verification on the routing request. If the verification is successful, the server records the client's current route and returns the corresponding target route to the client. The client then executes the target route. Step 6: The client initiates an interface request. The server performs access permission management, precondition and context verification on the interface request. If the verification is successful, the server returns the corresponding interface data to the client, and the client can continue to access the interface.
2. The method for accessing multi-platform clients based on URL routing according to claim 1, characterized in that: The logical functional units are represented in the form of pages, pop-ups, background services, functions, logic blocks, and system API calls; URLs are used to uniquely name and identify several logical functional units, and a grouping plus name naming method is used to uniquely name the logical functional units.
3. The method for accessing multi-platform clients based on URL routing according to claim 1, characterized in that: In step two, clients on different platforms can parse the received route to obtain the route path based on the mapping relationship between the logical function unit identifier and the route path in the route, and match the logical function unit according to the parsed route path, and the client executes the corresponding logical function unit.
4. The method for accessing multi-platform clients based on URL routing according to claim 1, characterized in that: In step three, the established route storage association table includes the route version, route path, route prerequisites, route access permissions, and the mapping relationship between the logical functional unit identifier and the route path in the route of the client on different platforms; the route prerequisites include login account, real name, geographical location, and risk verification.
5. The method for accessing multi-platform clients based on URL routing according to claim 1, characterized in that: When a client initiates a routing request, the following steps are included: Step 1-1: Perform route access permission verification on the route request. If the route access permission verification fails, return an unauthorized route to the client. If the route request access permission verification passes, perform precondition verification. Steps 1-2: Perform route precondition validation on the route request. If the route precondition validation fails, the server returns the precondition validation route to the client. If the precondition validation passes, the server returns the corresponding target route to the client. The client then parses the route and executes the corresponding logical function unit based on the returned target route.
6. The method for accessing multi-platform clients based on URL routing according to claim 1, characterized in that: When a client initiates an API request, the following steps are included: Step 2-1: Perform interface access permission verification on the interface request. If the interface access permission verification fails, return an unauthorized route to the client. If the interface access permission verification passes, perform precondition verification. Step 2-2: Perform precondition validation on the interface request. If the precondition validation fails, return the precondition validation route to the client. If the precondition validation passes, perform context association validation. Steps 2-3: Perform interface context association verification on the interface request. If the interface context association verification fails, return a verification route to the client. If the context association verification passes, the interface request is verified and the server returns the corresponding interface data to the client.
7. A multi-platform client access system based on URL routing, the apparatus being used to implement the multi-platform client access method based on URL routing as described in any one of claims 1 to 6, characterized in that: include: Routing registration module: Used for clients on different platforms to register several logical functional units, and to establish a mapping relationship between logical functional unit identifiers and routing paths in the routing table; Route resolution and verification module: When the server receives a route request, it verifies the route access permissions and route prerequisites, and generates the target route; The route distribution module is used by the server to distribute the target route generated in the route resolution and verification module to the client. Context association module: Used to associate user operations with the corresponding interface data that implements the route, and to verify risky operations.
8. A storage medium, characterized in that: It stores an executable program, which, when executed by a processor, implements the URL routing-based multi-platform client access method according to any one of claims 1 to 6.