SAAS system and multi-portal multi-organization management method thereof

Abstract

The invention provides an SAAS system and a multi-portal multi-organization management method thereof. The SAAS system comprises a front end, a gateway, a server and a database. The method comprises the steps that a front end receives an access request and determines a corresponding portal identifier so as to determine a portal uniquely corresponding to a custom domain name; the gateway intercepts an interface calling request of the user terminal to extract the user identity token, the target interface and the portal identifier from the interface calling request, and authenticates the interface calling request; when the authentication result is that the authentication is passed, the server analyzes the interface calling request to obtain a service demand parameter, so as to obtain an institution code which can be accessed by the user terminal under the current portal in combination with the user identity token to form an institution list; the server assembles an initial SQL statement according to the business demand parameters and the mechanism list; and when the initial SQL statement conforms to a preset isolation rule, the server injects the mechanism list into the initial SQL statement as a filtering condition, and the database executes the current SQL statement to obtain target data and returns the target data to the user terminal.

Description

Technical Field

[0001] This application relates to the fields of computer software and cloud computing technology, and in particular to a SaaS system and its multi-portal, multi-organization management method. Background Technology

[0002] In multi-tenant scenarios under Software as a Service (SaaS), the common approaches are one portal per instance or a single portal with a unified domain name and shared access. Specifically, one portal per instance deploys a complete front-end, gateway, and database instance independently for each portal (e.g., brand, tenant). A single portal with a unified domain name and shared access uses the same domain name and database for all portals, with logical isolation only achieved through the tenant field. However, one portal per instance suffers from hardware duplication, cumbersome upgrades, and linearly increasing maintenance costs with the number of portals; while a single portal with a unified domain name and shared access cannot provide independent entry points for different brands, data isolation granularity stops at the portal level, making further segmentation by different organizations (e.g., headquarters, branches, stores, etc.) difficult, and cross-layer penetration queries challenging. Summary of the Invention

[0003] This application provides a SaaS system and its multi-portal, multi-organization management method, which achieves data isolation and penetration query for multi-level organizations under the same database instance by binding portals to custom domains, multi-level authentication, dynamic organization lists, and SQL injection interception.

[0004] In a first aspect, embodiments of this application provide a multi-portal, multi-organization management method for a SaaS system. The SaaS system includes a front-end, a gateway, a server, and a database. The management method includes: the front-end receiving an access request from a user terminal to a custom domain name, and determining a corresponding portal identifier based on the custom domain name to identify a portal uniquely corresponding to the custom domain name; the gateway intercepting an interface call request from the user terminal to extract a user identity token, a target interface, and the portal identifier from the interface call request, wherein the interface call request carries the portal identifier; and the gateway authenticating the interface call request based on the user identity token, the target interface, and the portal identifier. The system obtains an authentication result, which is either authentication passed or authentication failed. When the authentication result is successful, the server parses the interface call request to obtain business requirement parameters. Based on the user identity token and business requirement parameters, the server obtains the organization codes accessible to the user terminal under the current portal to form an organization list. Based on the business requirement parameters and the organization list, the server assembles an initial SQL statement. When the initial SQL statement meets preset isolation rules, the server injects the organization list as a filter condition into the initial SQL statement to obtain the current SQL statement. The database executes the current SQL statement to obtain the target data and returns it to the user terminal.

[0005] Secondly, embodiments of this application provide a SaaS system, which includes a front-end, a gateway, a server, and a database. The server is communicatively connected to the front-end, the gateway, and the database, and includes a memory and a processor. The memory is used to store computer programs, and the processor is used to execute the computer programs to implement the multi-portal and multi-organization management method of the SaaS system described above.

[0006] The aforementioned SaaS system and its multi-portal, multi-organization management method determine the portal identifier within the database through a custom domain name, dynamically generate an organization code list after three-level authentication, and intercept and inject organization scope placeholders, thereby achieving independent entry points for multiple portals and data isolation for multiple organizations, while also accommodating cross-layer penetration queries, significantly reducing deployment and maintenance costs. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0008] Figure 1A flowchart illustrating the multi-portal, multi-organization management method of the SaaS system provided in this application embodiment.

[0009] Figure 2 A flowchart of step S101 provided for an embodiment of this application.

[0010] Figure 3 A flowchart of step S103 provided in the embodiments of this application.

[0011] Figure 4 A flowchart of step S105 provided in the embodiments of this application.

[0012] Figure 5 A flowchart of step S106 provided in the embodiments of this application.

[0013] Figure 6 A flowchart of step S107 provided in the embodiments of this application.

[0014] Figure 7 A flowchart of step S108 provided for an embodiment of this application.

[0015] Figure 8 This is a structural block diagram of the preset permission system provided in the embodiments of this application.

[0016] Figure 9 A schematic diagram of a preset permission system provided in an embodiment of this application.

[0017] Figure 10 This is a structural block diagram of the SaaS system provided in the embodiments of this application.

[0018] Figure 11 This is a schematic diagram of the internal structure of the server for the multi-portal, multi-organization management method of the SaaS system provided in the embodiments of this application.

[0019] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0021] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar planned objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data are interchangeable where appropriate; in other words, the described embodiments are implemented according to a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, may also include other content; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of a person skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0023] Please refer to Figure 1This is a flowchart illustrating a multi-portal, multi-organization management method for a SaaS system provided in this application embodiment. This application provides a multi-portal, multi-organization management method for a SaaS system. Under a SaaS system 1000, this application proposes a multi-portal, multi-organization management method. The front-end 101 determines the corresponding portal identifier through a custom domain name, forming independent entry points for different portals (such as brands, tenants, etc.). A three-level authentication is performed via a gateway 102 to dynamically generate different organization codes (such as headquarters, branches, stores, etc.) under the current portal, forming an organization list. An interceptor injects the organization list into SQL statements, which are then executed in the database 103, achieving multi-portal brand isolation and multi-organization data penetration query within the same database 103. In this application, the SaaS system 1000 includes a front-end 101, a gateway 102, a database 103, and a server 100. The database 103 is used to store business data with organization codes. Business data can be policy data, claims data, or channel data, etc. Each organization code is globally unique within the database, and each organization code is hierarchically linked through its corresponding superior organization number, forming a tree-like relationship of headquarters-branch offices-stores, thus supporting downward recursive aggregation and cross-level penetration queries. Server 100 is communicatively connected to front-end 101, gateway 102, and database 103, and is used to execute the multi-portal, multi-organization management method of the SaaS system. The characteristics of server 100 will be described in detail below. The management method includes steps S101-S108.

[0024] In step S101, the front end receives the user terminal's access request for the custom domain name and determines the corresponding portal identifier based on the custom domain name to identify the portal that uniquely corresponds to the custom domain name.

[0025] In step S101, the access request can be a request received by the front-end 101 from a user terminal via a browser to a fully custom domain name or a patterned subdomain. The custom domain name can be either a fully custom domain name or a patterned subdomain. The custom domain name can be a platform-unified, dynamically generated patterned subdomain (such as saas-pta8257.bandins.com, saas-pta8260.bandins.com, etc., with a unified format), or a fully custom domain name exclusive to each brand (such as ibao-xxx.bandins.com), to achieve complete independence for different manufacturers and brands, giving each manufacturer its own dedicated access point. In this application, each request initiated by the user terminal automatically carries terminal information such as the UA, OS, and screen resolution generated by the browser. By obtaining the portal identifier, the portal uniquely corresponding to the custom domain name is determined, achieving a one-to-one mapping of "domain name as portal." Portal identity can be instantly locked without additional login fields, thereby preventing cross-referencing and unauthorized access between different portals, laying an unforgeable foundation for subsequent multi-level data isolation and brand operation statistics.

[0026] Please refer to Figure 2 This is a flowchart of step S101, a sub-step provided in the embodiments of this application. The front end receives the user terminal's access request for a custom domain name and determines the corresponding portal identifier based on the custom domain name, including steps S1011-S1014.

[0027] In step S1011, the front end reverse proxies the access request to the deployed front end application through routing.

[0028] In step S1011, after receiving a user access request, a custom domain name can be pre-matched using a preset directive via routing, and the request is reverse-proxied to the deployed front-end application without modification, thus achieving seamless forwarding for the user and lossless domain name transmission. In this application, the routing module can be Nginx. The preset directive can be the pre-configured `server_name` directive in the domain routing module. The deployed front-end application can be a static package of a single-page application compiled based on frameworks such as React / Vue, responsible for the unified encapsulation of initial screen rendering, domain name resolution, portal identifier injection, and subsequent API call requests.

[0029] Step S1012: Use the front-end application to extract the domain name of the current window and obtain the custom domain name.

[0030] In step S1012, the front-end application extracts the current domain name on the first screen and performs a local verification according to a preset whitelist to ensure that the portal identifier obtained subsequently strictly corresponds to the user's actual access address, preventing portal misalignment due to proxy layer tampering. In this application, the extraction of the current domain name can be achieved through the browser's native Application Programming Interface (API), which can be "window.location.hostname".

[0031] Step S1013: Using the custom domain name as the query parameter, call the preset mapping interface to query and obtain the portal identifier corresponding to the custom domain name.

[0032] In step S1013, the preset mapping interface is used to reflect the mapping relationship between custom domain names and portal identifiers. For example, when the custom domain name is "ibao-xxx.bandins.com", after retrieving the current domain name using the "window.location.hostname" command, the preset mapping interface " / portal / queryByDomain?domain=ibao-xxx.bandins.com" can be used to query the corresponding portal identifier by using the custom domain name as a query parameter. In this application, the SAAS system 1000 maintains a dynamically addable and deleteable mapping table to reflect the mapping relationship between custom domain names and portals, and to provide a query option for the preset mapping interface. The mapping table can be stored in a database or in a cache. If the corresponding portal identifier is not found, it directly returns "not found information" to ensure that only domain names that have been registered can access the site. The "not found information" can be set independently, such as "404" or "404 not found".

[0033] Step S1014: Inject the portal identifier into the front-end global context so that the interface call request carries the portal identifier.

[0034] In step S1014, the interface call request is a request initiated by the user terminal after the access request. In this application, after obtaining the portal identifier, it is immediately written into the global context and appended to the request header of each subsequent interface access request, realizing full-link reuse of one-time resolution. Gateway 102 can directly obtain the tamper-proof portal identity without resolving the domain name again.

[0035] In step S102, the gateway intercepts the user terminal's interface call request to extract the user identity token, target interface, and portal identifier from the interface call request.

[0036] In step S102, the interface call request carries a portal identifier. Gateway 102, as the sole entry point for user terminals to access the SAAS system 1000, forcibly intercepts all interface call requests. The user identity token contains a user ID, a role array, and an expiration time, used to prove which user terminal initiated the request. The target interface refers to the backend business interface that the user intends to call, which can be represented as a combination of HTTP method and request path, such as "POST / policy / quote". In this application, gateway 102 quickly determines the specific function of this access by parsing the combination of HTTP method and request path in the target interface, thereby completing the subsequent "query whether the user has the right to perform this operation under this portal".

[0037] In step S103, the gateway authenticates the interface call request based on the user identity token, the target interface, and the portal identifier to obtain the authentication result.

[0038] In step S103, the authentication result is either authentication passed or authentication failed. In this application, authentication via gateway 102 ensures that the interface call request originates from a registered portal, confirms that the user terminal belongs to that portal and that the user's identity token has not expired, and confirms the current user terminal's authorization to the target interface and even button operations under that portal. Only when all three conditions are met is the request allowed. Thus, gateway 102 can intercept illegal domain names, cross-tenant unauthorized access, and unauthorized operations all at once, advancing the attack surface before the business logic, significantly reducing the security burden on each microservice, and supporting fine-grained permission control at the button level, thereby improving system security.

[0039] Please refer to Figure 3 This is a flowchart of step S103 provided in the embodiments of this application. The gateway authenticates the interface call request based on the user identity token, the target interface, and the portal identifier to obtain the authentication result, including steps S1031-S1034.

[0040] In step S1031, the gateway verifies the legitimacy of the portal identifier and obtains the first authentication result.

[0041] In step S1031, the gateway 102 performs a hash comparison between the portal identifier of the interface call request and the preset whitelist to confirm whether the value exists or whether the format is illegal.

[0042] In step S1032, the gateway performs validity and attribution verification on the user identity token to obtain the second authentication result.

[0043] In step S1032, the gateway 102 verifies the user identity token using the public key, and actively queries whether the user identity token has been actively revoked. It then verifies whether the user identity token is consistent with the portal identifier of this request, thus completing the validity verification and attribution verification to prevent forgery, expiration, or cross-tenant reuse.

[0044] In step S1033, the gateway calls the preset permission system to query the user identity token’s functional permissions for the target interface and corresponding operations under the portal identifier, obtains the third authentication result, and retrieves the role identifier and the corresponding list of accessible organizations corresponding to the user identity token.

[0045] In step S1033, the gateway 102 carries the user identity token and the target interface, remotely calls the preset permission system 10, and queries the authorization record of "whether the role has the interface and corresponding button operation under this portal".

[0046] Step S1034: The authentication result is determined to be successful if and only if the first authentication result, the second authentication result, and the third authentication result are all successful; otherwise, the authentication result is determined to be unsuccessful.

[0047] In step S1034, gateway 102 only forwards the request if the first, second, and third authentication results are all successful. If any step fails, a unified error code is immediately assembled and returned to frontend 101, ensuring that illegal domains, expired identities, or unauthorized operations are intercepted before entering the backend business. It can be understood that the three authentications are completed sequentially within the same gateway process. That is, each time gateway 102 performs authentication, it only calls the preset permission system 10 once, thereby controlling the authentication latency within a single remote interaction. This avoids multiple round trips caused by multi-level permission queries, reduces gateway 102's waiting time, and reduces the load on the preset permission system 10. Simultaneously, it ensures that all security checks are completed at once before the business logic, improving overall throughput and simplifying troubleshooting.

[0048] like Figure 8 and Figure 9 As shown, the preset permission system 10 in this application includes a function permission management module 11, a data permission management module 12, a role management module 13, a portal management module 14, and a permission publishing module 15.

[0049] The Functional Permission Management Module 11 is used to create functional permissions. Functional permissions include a permission code (e.g., the field "func_code"), an interface address (e.g., the field " / policy / quote"), and a request method (e.g., the field "POST"). The combination of these three (e.g., "POST / policy / quote") describes the access rights to the target interface and corresponding operations. For example, permissions such as "create order" and "view financial statements" are implemented through different field contents. In this application, the Functional Permission Management Module 11 allows operations personnel to create functional permissions through a visual interface during the configuration phase. Each functional permission can be associated with multiple microservice interfaces, and the permissions are persistently stored after creation, providing a foundation for subsequent role binding and portal publishing.

[0050] The data permission management module 12 is used to create data permissions. Data permissions include a scope code (corresponding to the field "scope_code", which is an exhaustive pre-defined constant such as "DEALER", "ALL", "SELF", etc.) and an organization range expression (corresponding to the field "org_range_expr"), used to generate a list of organizations accessible under the current portal. In this application, the organization range expression can be used to summarize the codes of lower-level organizations level by level to generate a list of organizations accessible under the current portal, providing a scope basis for data isolation and cross-level queries, adapting to the data access needs of different levels of organizations such as OEMs / groups and distributors.

[0051] The role management module 13 is used for permission packaging and association, supporting the binding of at least one functional permission and at least one data permission to the same role (such as roles like "Sales Manager" or "Finance Specialist"). Specifically, employee accounts correspond one-to-one with basic users, and basic users need to be granted permissions by being assigned specific roles. For example, the role corresponding to the "Order Management" menu can be bound to multiple functional permissions such as "Query Orders" and "Create Orders" as well as corresponding data permissions, realizing the association relationship between employees, basic users, roles, and permissions.

[0052] The portal management module 14 is used to bind at least one role to each portal and generate a portal menu snapshot. The portal menu snapshot includes at least the menu tree visible to the corresponding portal and its corresponding functional permissions, and uses the bound role as the default permission template for that portal. In this application, the menu tree consists of menu nodes at different levels. Each application in the SAAS system 1000 is composed of menu trees at different levels, such as first-level, second-level, and third-level. The portal can select the required menu tree and all subordinate functional permissions from the application to customize and generate a unique portal menu snapshot. For example, the portal menu snapshot can be divided into the following levels: 1. Upstream organization (OEM / Group management); 2. Business organization (Dealer management); 3. Employee management organization. Among them, an upstream organization can create and associate multiple dealers, and can be associated with the corresponding portal through the portal management module 14 as the root organization, representing the top-level organizational unit in the SAAS system 1000; the business organization is the subordinate organization that specifically carries out business under the upstream organization, and each dealer belongs to an upstream organization (OEM / Group); the employee management organization creates employee accounts for dealers, and each employee account corresponds to a user for logging into the SAAS system 1000. The data scope of the portal menu snapshot is determined by the scope encoding of data permissions, thus achieving dual isolation between functionality and data permissions.

[0053] The permission publishing module 15 is used to write the portal identifier, role identifier and corresponding organization list into the cache, so that the gateway can complete the function authentication and obtain the organization list, providing a fast query basis for gateway authentication and efficiently obtaining the access scope of the organization.

[0054] In some feasible embodiments, the user identity token can be issued after the user terminal successfully logs in, and it has an expiration time and refresh mechanism. The gateway caches the parsed target interface. If the same request is received again within a short time window from the same portal, the same user, and the same interface, the authentication result obtained from the previous authentication can be reused directly to reduce the number of calls to the preset permission system 10 and improve throughput.

[0055] Step S104: When the authentication result is successful, the server parses the interface call request to obtain the business requirement parameters.

[0056] In step S104, after gateway 102 authenticates the data, it performs standardized extraction of the target interface, QueryString, and JSON Body to generate business requirement parameters. These parameters may include key fields such as query scope (e.g., "My Stores" or "All Stores in the Region"), product codes, and pagination information, providing a unique and structured input for the subsequent dynamic calculation of the organization list, enabling full-link reuse through a single parsing.

[0057] In step S105, the server obtains the organization codes that the user terminal can access under the current portal based on the user identity token and business requirement parameters to form an organization list.

[0058] Please refer to Figure 4 This is a flowchart of sub-step S105 provided in the embodiments of this application. The server obtains the organization codes that the user terminal can access under the current portal based on the user identity token and business requirement parameters to form an organization list, including steps S1051-S1053.

[0059] Step S1051: Determine the query range identifier based on the business requirement parameters.

[0060] In step S1051, the query scope identifier is used to characterize the corresponding data query scope. The parsed business requirement parameters in this application may contain query scope fields such as "scope=DEALER" or "scope=ALL". The system maps these to different query scopes such as "My Stores" and "All Stores in the Region", generating corresponding query scope identifiers to define the boundaries for subsequent calculation of accessible institution codes.

[0061] Step S1052: Invoke the preset permission system to parse and obtain several organization codes that match the query range identifier based on the user identity token and the query range identifier.

[0062] In step S1052, gateway 102 sends the user identity token and query scope identifier to the preset permission system 10. It first retrieves the data permission policies bound to the role under this portal, then recursively summarizes the organizational nodes that meet the scope, and returns several globally unique organizational codes, thus automatically deducing "who + what scope to query" and "which organizational codes to return." In this application, organizational codes, such as "'org_001'" and "'org_002'", correspond to different levels of organizations. For example, "'org_001'" represents the headquarters, and "'org_002'" represents a branch office, etc. The recursive summarization of organizational nodes that meet the scope in this application can start from the user-bound portal through the preset permission system 10, prioritizing the collection of all lower-level organizational codes along the organizational tree depth, to return several globally unique organizational codes.

[0063] Step S1053: Arrange the codes of several organizations into an organization list in order.

[0064] In step S1053, the organization codes returned by the preset permission system 10 are arranged in ascending order of hierarchical depth. For example, when organization codes such as 'org_001', 'org_003', and 'org_008' are returned, the front-end application directly concatenates them into a list of organizations in the form of ['org_001', 'org_003', 'org_008'] according to hierarchical depth, ensuring that the same query statement completes accurate data isolation and sharing within the database 103.

[0065] Step S106: The server assembles the initial SQL statement based on the business requirement parameters and the list of organizations.

[0066] Please refer to Figure 5 This is a flowchart of step S106, provided in an embodiment of this application. The server assembles the initial SQL statement based on business requirement parameters and the organization list, including steps S1061-S1063.

[0067] Step S1061: Construct a query object corresponding to the business requirement parameters.

[0068] In step S1061, the query object at least includes a table name, a field list, and query conditions. The table name specifies the physical database table to be queried (e.g., policy, dealer, claim, etc.). The field list specifies the data to be returned or filtered (e.g., org_code, policy_no, premium, status, etc.). The query conditions are business-dimensional filtering expressions (e.g., "status = 1 AND create_time>= '2025-06-01'", "WHERE org_code IN ('org_xxx)", etc.), and include query fields. In this application, the table name, field list, and business conditions are instantiated and encapsulated into a query object all at once based on business requirement parameters. The query fields can be WHERE fields.

[0069] Step S1062: Add an organization scope placeholder to the query field.

[0070] In step S1062, the organization scope placeholder is used to receive the corresponding organization list. In this application, the organization scope placeholder can be ".in("org_code", #{orgList})", which is a dynamic SQL syntax of MyBatis, and is replaced by "org_code IN (...)" by the interceptor during execution. This is achieved by reserving organization scope placeholders in the WHERE field of the query object. The organization scope placeholders correspond one-to-one with the organization list sent from the front end 101, ensuring that the actual organization codes can be seamlessly injected before the SQL statement is executed, thus achieving filtering based on both business conditions and data scope.

[0071] Step S1063: Serialize the query object into an initial SQL statement and mark the corresponding initial SQL statement as requiring institutional isolation type.

[0072] In step S1063, placeholders for the scope of organizations are added to the query conditions to receive the corresponding list of organizations. The query object is serialized into an SQL statement and marked as requiring organization isolation type for subsequent identification.

[0073] Step S107: When the initial SQL statement meets the preset isolation rules, the server injects the list of institutions as a filter condition into the initial SQL statement to obtain the current SQL statement.

[0074] Please refer to Figure 6 This is a flowchart of sub-step S107 provided in the embodiments of this application. The preset isolation rule is whether the SQL statement is marked as requiring institutional isolation. When the initial SQL statement meets the preset isolation rule, the server injects the list of institutions as a filter condition into the initial SQL statement to obtain the current SQL statement, including steps S1071-S1073.

[0075] Step S1071: Identify the initial SQL statement through the interceptor and intercept SQL statements that have been marked as requiring institutional isolation.

[0076] In step S1071, the interceptor runs on server 100. Before the SQL statement is sent to database 103, the interceptor scans the query objects of the SQL statement. The interceptor is only triggered when the query object is marked as requiring organizational isolation, ensuring that subsequent injection actions only apply to requests explicitly required by the business logic.

[0077] Step S1072: Fill in the corresponding placeholders for the organization range in the list of organizations to form the current SQL statement.

[0078] In step S1072, the interceptor substitutes the organization codes in the organization list one by one into the preset organization range placeholders, assembles and appends them to the query conditions to form the current SQL statement, thereby achieving data isolation within the same database instance 103.

[0079] Step S1073: For initial SQL statements that are not marked as requiring institutional isolation, keep the original statements executed.

[0080] In step S1073, if the statement is not marked as requiring institutional isolation, the interceptor directly allows the original SQL statement to run without any rewriting, so as to ensure that public queries such as global configuration are still executed as full table, taking into account the needs of both sharing and isolation scenarios.

[0081] In step S108, the database executes the current SQL statement, obtains the target data, and returns it to the user terminal.

[0082] In step S108, the target data is at least one of different business data such as policy data, claims data, or channel data, and different portals within the same database 103 can only access data within the scope of the institution code corresponding to their respective portal identifiers. The target data only contains data within the scope corresponding to the institution list. In this application, the target data is business data within the scope limited by the institution list, such as a policy list formed from policy data: [{policyNo: "P2506001", orgCode: "org_001", premium: 3200}, …….

[0083] Please refer to Figure 7 This is a flowchart of step S108, a sub-step provided in the embodiments of this application. Steps S1081-S1082 include executing the current SQL statement in the database, obtaining the target data, and returning it to the user terminal.

[0084] Step S1081: Submit the current SQL statement to the database for execution and obtain the returned result set.

[0085] In step S1081, the returned result set includes several organization codes and corresponding business data. In this application, the current SQL statement is submitted to database 103 after being hardened by isolation conditions to obtain the returned result set, ensuring that each record can be compared with each organization code in the organization list, providing a basis for subsequent filtering. The current SQL statement already contains the "org_code IN" segment, returning only business data within a limited range.

[0086] Step S1082: Retain the institution codes that exist within the corresponding range of the institution list to form target data.

[0087] In step S1082, only records whose organization codes exist within the range of the organization list in the returned result set are retained. After removing all the remaining out-of-bounds data, the target data is formed and returned to the user terminal. This ensures that only the organization codes within the corresponding range of this portal are visible under the same instance and the same SQL statement, thereby achieving precise isolation and return.

[0088] To facilitate understanding, the following will explain how to implement multi-portal and multi-organization management methods in SaaS system 1000.

[0089] First, the user terminal initiates an access request to the custom domain "ibao-xxx.bandins.com" through a browser. Frontend 101, after being routed via reverse proxy, uses the browser's native application programming interface "window.location.hostname" to extract the domain name and calls the preset mapping interface " / portal / queryByDomain" to obtain the portal identifier. This portal identifier is then injected into the frontend's global context, ensuring that subsequent interface calls include this portal identifier in the corresponding request header. Next, gateway 102, acting as the sole entry point, intercepts the interface call request and performs authentication: portal identifier validity verification → user identity token validity and ownership verification → call... The default permission system 10 is used to query the target interface and button operation permissions. Only when all three are authenticated is access granted. After authentication is granted, the gateway parses the business requirement parameter “scope=DEALER” and calls the same default permission system 10. It recursively summarizes the accessible organization codes “'org_001'”, “'org_003'” and “'org_008'” under the current portal in combination with the query scope identifier, and forms an organization list in order. Then, the query object corresponding to the business requirement parameter is constructed as follows: (1) Table name: policy; (2) Field list: org_code / policy_no / premium; (3) Query condition: status=1. Then, an organization scope placeholder ".in("org_code", #{orgList})" is added to the query field to obtain the initial SQL statement marked as requiring organization isolation. Finally, the interceptor recognizes the mark of requiring organization isolation, and the server 100 calls the MyBatis Mapper interface and fills the organization list into the organization scope placeholder to generate the current SQL statement. After execution in the database 103, only the business data of the organization codes that exist in the corresponding range of the organization list in the returned result set are retained, thereby completing the isolation of multiple portal independent entry points and multiple organization data within the same database 103 instance.

[0090] Please refer to Figure 10 This is a structural block diagram of the SaaS system provided in the embodiments of this application. This application also provides a SaaS system 1000. The SaaS system 1000 includes a front-end 101, a gateway 102, a database 103, and a server 100. The server 100 is communicatively connected to the front-end 101, the gateway 102, and the database 103. In this application, there can be one or more user terminals 101. The server 100 can be a computer device.

[0091] Please refer to Figure 11 This is a schematic diagram of the internal structure of the server in the multi-portal, multi-organization management method of the SaaS system provided in the embodiments of this application.

[0092] like Figure 11 As shown, server 100 includes memory 901 and processor 902. Processor 902 is used to execute computer program instructions stored in memory 901 to implement a multi-portal, multi-organization management method for the SaaS system.

[0093] The memory 901 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 901 can be an internal storage unit of a computer device, such as a hard disk. In other embodiments, the memory 901 can be an external storage device of a computer device, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., configured in the computer device. Furthermore, the memory 901 can include both internal and external storage units of a computer device. The memory 901 can be used not only to store application software and various types of data installed on the computer device, such as the code for multi-portal, multi-organization management methods of a SaaS system, but also to temporarily store data that has been output or will be output.

[0094] Furthermore, server 100 also includes bus 903. Bus 903 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0095] Furthermore, server 100 may also include a display component 904. Display component 904 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an organic light-emitting diode (OLED) touchscreen, etc. Display component 904 may also be appropriately referred to as a display device or display unit, used to display information processed in server 100 and to display a visual user interface.

[0096] Furthermore, server 100 may also include communication component 905. Communication component 905 may optionally include wired communication component and / or wireless communication component (such as Wi-Fi communication component, Bluetooth communication component, etc.), typically used to establish communication connections between server 100 and other computer devices.

[0097] Figure 11 Only a server 100 with some components and a multi-portal, multi-organization management method for implementing a SaaS system is shown. Those skilled in the art will understand that... Figure 11 The structure shown does not constitute a limitation on server 100 and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0098] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, in the form of a computer program product.

[0099] 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 flow or function according to embodiments of the present invention is generated. The computer device may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0102] The unit described as a separate component may or may not be physically separate. The component shown as a unit may or may not be a physical unit; that is, it may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist independently, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard disks, read-only storage media (ROM), random access storage media (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0105] In the above embodiments, the portal identifier is determined by a custom domain name in the database. After three-level authentication, an organization code list is dynamically generated, and the injected organization range placeholders are intercepted. This achieves independent entry points for multiple portals and data isolation for multiple organizations, while also accommodating cross-layer penetration queries, significantly reducing deployment and maintenance costs.

[0106] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0107] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0108] The above-listed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A multi-portal, multi-organization management method for a SaaS system, characterized in that, The SaaS system includes a front-end, gateway, server, and database; the management method includes: The front end receives the user terminal's access request for the custom domain name, and determines the corresponding portal identifier based on the custom domain name, so as to identify the portal that uniquely corresponds to the custom domain name; The gateway intercepts the user terminal's interface call request to extract the user identity token, target interface, and portal identifier from the interface call request, and the interface call request carries the portal identifier; The gateway authenticates the interface call request based on the user identity token, the target interface, and the portal identifier to obtain an authentication result, which is either authentication successful or authentication unsuccessful. When the authentication result is successful, the server parses the interface call request to obtain the business requirement parameters; The server obtains the organization codes that the user terminal can access under the current portal based on the user identity token and business requirement parameters to form an organization list; The server assembles the initial SQL statement based on the business requirement parameters and the list of organizations. When the initial SQL statement meets the preset isolation rules, the server injects the list of institutions as a filter condition into the initial SQL statement to obtain the current SQL statement; The database executes the current SQL statement, obtains the target data, and returns it to the user terminal.

2. The management method as described in claim 1, characterized in that, The front-end receives access requests from user terminals for custom domain names and determines the corresponding portal identifier based on the custom domain name, including: The front-end reverse proxies the access request to the deployed front-end application via routing; The domain name of the current window is extracted using the front-end application to obtain the custom domain name, which is either a fully custom domain name or a patterned subdomain. Using the custom domain name as the query parameter, the preset mapping interface is called to query and obtain the portal identifier corresponding to the custom domain name; The portal identifier is injected into the front-end global context so that the interface call request carries the portal identifier, and the interface call request is a request initiated by the user terminal after the access request.

3. The management method as described in claim 1, characterized in that, The gateway authenticates the interface call request based on the user identity token, the target interface, and the portal identifier to obtain an authentication result, including: The gateway performs a validity check on the portal identifier and obtains a first authentication result; The gateway performs validity and attribution verification on the user identity token to obtain a second authentication result. The gateway invokes the preset permission system to query the user identity token's functional permissions for the target interface and corresponding operations under the portal identifier, obtains the third authentication result, and retrieves the role identifier and the corresponding list of accessible organizations corresponding to the user identity token. The authentication result is deemed to be successful if and only if the first authentication result, the second authentication result, and the third authentication result are all successful; otherwise, the authentication result is deemed to be unsuccessful.

4. The management method as described in claim 3, characterized in that, The preset permission system includes: The function permission management module is used to create function permissions. The function permission includes a permission code, an interface address, and a request method to describe the access rights to the target interface and the corresponding operation. The data permission management module is used to create data permissions, which include scope codes and organization scope expressions to generate a list of organizations that can be accessed under the current portal. The role management module is used to bind at least one functional permission and at least one data permission to the same role simultaneously. The portal management module is used to bind at least one role to each portal and generate a portal menu snapshot, wherein the portal menu snapshot at least includes the menu tree visible to the corresponding portal and its corresponding function permissions; and The permission publishing module is used to write the portal identifier, role identifier and corresponding organization list into the cache so that the gateway can complete the function authentication and obtain the organization list.

5. The management method as described in claim 3, characterized in that, The server, based on the user identity token and business requirement parameters, obtains a list of organizations accessible to the user terminal under the current portal, including: The query range identifier is determined based on the business requirement parameters, and the query range identifier is used to represent the corresponding data query range; The preset permission system is invoked to parse and obtain several organization codes that match the query range identifier based on the user identity token and the query range identifier; The organization codes are arranged in order to form the organization list.

6. The management method as described in claim 1, characterized in that, The server assembles an initial SQL statement based on the business requirement parameters and the list of organizations, including: Construct a query object corresponding to the business requirement parameters. The query object includes at least a table name, a field list, and query conditions. The table name is used to specify the physical database table to be queried, the field list is used to specify the data to be returned or filtered, and the query conditions include query fields. Add an organization scope placeholder to the query field; the organization scope placeholder is used to receive the corresponding list of organizations. The query object is serialized into the initial SQL statement, and the corresponding initial SQL statement is marked as requiring institutional isolation.

7. The management method as described in claim 6, characterized in that, The preset isolation rule is whether the SQL statement is marked as requiring institutional isolation. When the initial SQL statement meets the preset isolation rules, the server injects the list of institutions as a filter condition into the initial SQL statement to obtain the current SQL statement, including: The initial SQL statement is identified by an interceptor, and SQL statements that have been marked as requiring institutional isolation are also intercepted. Fill the corresponding placeholders in the list of institutions to form the current SQL statement; For initial SQL statements that are not marked as requiring institutional isolation, keep the original statements executed.

8. The management method as described in claim 1, characterized in that, The database executes the current SQL statement, obtains the target data, and returns it to the user terminal, including: The current SQL statement is submitted to the database for execution to obtain a return result set, which includes several organization codes and corresponding business data. The institution codes that exist within the corresponding range of the institution list are retained to form the target data.

9. The management method as described in claim 8, characterized in that, The target data is at least one of policy data, claims data, or channel data, and different portals within the same database can only access data within the scope of the institution code corresponding to their respective portal identifiers.

10. A SaaS system, characterized in that, The SaaS system includes a front-end, a gateway, a server, and a database. The server is communicatively connected to the front-end, the gateway, and the database, including: Memory, used to store computer programs; and A processor for executing the computer program to implement the multi-portal, multi-organization management method of the SaaS system as described in any one of claims 1-9.

Images