Multi-domain name switching method and storage medium

Abstract

The invention discloses a multi-domain name switching method and a storage medium. The invention relates to the field of SAAS technology development. According to the service requirement of the APP, the domain name type is determined, the domain name type comprises a main domain name, a sub-domain name and a corresponding purpose, and the purpose comprises API request and static resource loading. And creating an exclusive domain name configuration item for each APP in a management system of the platform, and recording domain name information and the application. An A record is created on the DNS server for each assigned domain name. According to the method, the compliance domain name is dynamically acquired and applied, so that the APP is ensured to comply with the latest data protection regulations and industry standards at any time and any place, and the compliance risk caused by improper use of the domain name is effectively reduced. Moreover, the homologous strategy and the CORS strategy strictly limit illegal cross-domain requests, ensure that data interaction conforms to network security specifications, and reduce potential compliance problems.

Description

Technical Field

[0001] The present invention relates to the field of SAAS technology development, specifically to the field of interface domain name technology of multiple APP applications and their webview kernels, and in particular to a multi-domain name switching method and a storage medium. Background Art

[0002] Webview is an embedded browser component that allows applications to display web content directly inside it instead of jumping to an external browser application. This technology is widely used in the field of mobile application development, especially those scenarios that need to integrate web content or implement "hybrid apps". Webview is based on WebKit or other browser engines (such as Blink), which are responsible for parsing HTML, CSS and executing JavaScript to render a complete web experience inside the APP.

[0003] On the Android platform, WebView initially used the system's built-in WebKit kernel, but as Android versions are updated, modern WebViews gradually switch to using the Chromium kernel, which provides better performance and support closer to the latest Web standards. WKWebView on the iOS platform is a high-performance Webview component provided by Apple, also based on the WebKit engine.

[0004] When an app with the Webview kernel opens a web page, it will initiate a network request to the specified URL to obtain resource files such as HTML, CSS, JavaScript, and request backend interface data through technologies such as Ajax. If the app opens the same page, that is, the URL remains unchanged, then according to the cache mechanism of the HTTP / HTTPS protocol and the browser's homology policy, Webview will usually try to load existing resources from the local cache to reduce network requests and speed up page loading. For dynamic content, even if the URL is the same, the latest data will be pulled from the server again because it may involve dynamically changing parts such as timestamps, random parameters, or version control parameters.

[0005] Because of this phenomenon, the traditional technology has the following technical problems: the webpage loaded by Webview may contain third-party scripts or tracking codes, which may cause user data to be illegally collected by third parties, violating data protection regulations such as GDPR and CCPA. In addition, if the content displayed by Webview is not directly controlled by the APP, such as from a third-party website, non-compliant content may appear.

[0006] To this end, the present invention provides a multi-domain name switching method and a storage medium. Summary of the invention

[0007] In view of this, the present invention hopes to provide a multi-domain name switching method and storage medium to solve or alleviate the technical problems existing in the prior art, that is, how to achieve dynamic switching of resources and interfaces according to APP applications when multiple APP applications access a single page, meet compliance requirements, and at least provide a beneficial option for this; the technical solution of the present invention is implemented as follows:

[0008] 1. Overview:

[0009] The present invention ensures the full compliance of data processing of Webview kernel APP through centralized management and dynamic implementation of technical means. The core lies in the platform side configuration and sending compliant domain names to APP, which replaces the default settings accordingly, actively manages the main domain name of page and internal resource requests before and after webview loading, uniformly uses secure and compliant domain name access paths, combines HTTPS encryption and data minimization principles, supplemented by log records and regular audits, and forms a compliance control system from domain name resolution to data transmission chain, effectively preventing data security and privacy leakage risks.

[0010] (II) Technical solution:

[0011] In order to achieve the above technical objectives, the technical solution of the present invention is as follows:

[0012] 2.1 Step S1, domain name configuration and resolution management:

[0013] Before the application is released, the administrator allocates and configures a unique compliant domain name for each APP on the platform side.

[0014] Utilize DNS services to resolve these domain names to corresponding IP addresses, ensuring fast and stable access paths. At the same time, implement DNSSEC security enhancement technology to prevent DNS hijacking.

[0015] 2.1.1 Step S100, domain name planning and allocation:

[0016] According to the business needs of the APP, determine the domain name type, including the main domain name, subdomain name and the corresponding purpose, which includes API requests and static resource loading. Create a dedicated domain name configuration item for each APP in the platform's management system, and record the domain name information and the purpose.

[0017] 2.1.2 Step S101, DNS record creation and configuration:

[0018] For each assigned domain name, create an A record, AAAA record (for IPv6), or CNAME record on the DNS server, pointing to the actual IP address of the application server or the load balancer address.

[0019] Set the TTL time of the DNS record to balance the resolution speed so as to quickly respond to changes in the server IP.

[0020] 2.1.3 Step S102, implement DNSSEC security enhancement:

[0021] Generate the public and private keys required for DNSSEC on the DNS server to sign DNS records.

[0022] Use the private key to digitally sign the DNS record, generate a DS record, and upload it to the domain name registrar to complete the establishment of the signature verification chain. Use the DNSSEC verification tool to confirm that the DNS record has been correctly signed and can be verified by the global DNS system, ensuring the integrity and tamper-proofing of the domain name resolution process.

[0023] 2.2 Step S2, dynamic domain name management on APP side:

[0024] When the APP is started for the first time or updated each time, the current compliant domain name configuration is obtained from the platform through an API request to ensure that the APP uses the latest compliant domain name.

[0025] The APP will replace the default or old domain name configuration in the application with the compliant domain name obtained, preparing for the subsequent Webview loading.

[0026] 2.2.1 Step S200, read the API interface:

[0027] On the platform side, the RESTful API interface uses the HTTPS protocol to return the latest compliant domain name configuration information and perform API Key verification on the request.

[0028] The returned data structure includes the domain name type (such as API request domain name or static resource domain name), domain name string, and validity period information.

[0029] 2.2.2 Step S201, execute API call logic:

[0030] S2010, first startup processing: When the APP is installed and started for the first time, an initialization task is triggered. This task is responsible for initiating a request to the API interface on the platform side to obtain the compliant domain name configuration;

[0031] S2011, Update mechanism: Establish an APP version update detection mechanism. When a new version is detected to be available, re-execute the above domain name acquisition logic after the update;

[0032] S2012, Domain name configuration storage and replacement: After the APP successfully obtains the compliant domain name, it stores it locally (SharedPreferences, SQLite database or file system) as the domain name source for subsequent Webview loading;

[0033] S2013, dynamic replacement: Based on the network request library or Webview loading logic, the hard-coded default or old domain name in the application is replaced with the latest compliant domain name.

[0034] 2.3 Step S3, Webview page loading:

[0035] Before loading the webview web page, the APP proactively replaces the main domain name of the page request with the domain name obtained from the platform to ensure that even the domain name in the web link meets the compliance requirements.

[0036] When Webview loads a page, all external HTTP / HTTPS requests (including page elements, images and / or scripts) will be initiated using the replaced compliant domain name.

[0037] 2.3.1 Step S300, initialize Webview settings:

[0038] When initializing the Webview component in the app, you can set a custom WebViewClient or WebChromeClient by overriding or extending its default behavior to intercept and modify network requests.

[0039] 2.3.2 Step S301, request interception and domain name replacement:

[0040] The APP implements interception logic and executes interception requests before loading web resources (such as HTML, images, scripts, etc.).

[0041] The interception logic includes checking the domain name part of the requested URL. If it does not match the compliant domain name stored in the current APP, a regular expression or string replacement is used to replace the original domain name in the request URL with a compliant domain name.

[0042] 2.3.3 Step S302, resource loading and redirection processing:

[0043] When a dynamic request is initiated through JavaScript in the page, the JavaScript interface of Webview is called and processed, and the domain name replacement logic is applied to each request in the redirect chain to prevent compliance from being lost during the jump process.

[0044] 2.3.4 Step S304, HTTPS and certificate verification:

[0045] Read the SSL certificate verification logic of the configured Webview, process the verification of custom certificates or public trusted certificates, and avoid loading failures due to certificate problems.

[0046] 2.4 Step S4, internal resource and interface access control:

[0047] If a request to an API interface or additional resources is initiated through a JavaScript script within the page, by monitoring and replacing the domain name part in the request, ensure that these requests also follow the outer layer's compliant domain name rules, avoiding cross-domain issues while maintaining compliance.

[0048] 2.4.1 Step S400, JavaScript injection and monitoring:

[0049] When Webview is initialized, a custom Java object is injected into Webview through the addJavascriptInterface method, which contains methods for monitoring and controlling network requests.

[0050] In the webpage JavaScript, use this injected object to wrap or proxy all requests to API interfaces and resources. You can define a safeFetch function to replace the native fetch or XMLHttpRequest to ensure that all requests are sent through this function.

[0051] 2.4.2 Step S401, domain name check and replacement before request:

[0052] Inside the safeFetch function, first check whether the domain name of the request URL is compliant. If not, replace it with a compliant domain name using the same logic as in step S3.

[0053] Configure the CORS policy on the server side to allow requests from the compliant domain name of the page loaded by the Webview. The Access-Control-Allow-Origin response header contains or matches the compliant domain name of the app to support cross-domain requests.

[0054] 2.5 Step S5, security policy implementation:

[0055] Implement the same-origin policy and CORS policy in the webview environment to restrict illegal cross-domain requests.

[0056] 2.5.1 Step S500, execute CORS policy:

[0057] On the API server side, configure the CORS (cross-origin resource sharing) policy to allow requests from specific sources (i.e., the domain name of the compliant Webview loading page). This includes setting fields such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers in the HTTP response header, thereby achieving precise control over the allowed request types and header information.

[0058] In the custom WebViewClient, override the onLoadResource method to make the loaded resources comply with CORS rules.

[0059] 2.5.2 Step S501, execute JavaScript security policy:

[0060] Through the web page <meta> Set CSP in the tag or HTTP response header, define a whitelist, clearly specify the resource types and sources allowed to be loaded, enhance the security of web content, and further limit illegal cross-domain loading.

[0061] 2.5.3 Step S502, execute cross-frame scripting strategy:

[0062] Based on X-Frame-Options or Content-Security-Policy frame-ancestors, API interfaces and sensitive resources are prohibited from being loaded in non-same-origin iframes to prevent attacks such as clickjacking.

[0063] 2.6 Step S6, data communication:

[0064] Data communication is carried out through HTTPS protocol.

[0065] 2.6.1 Step S600, HTTPS protocol is enforced:

[0066] Override the shouldOverrideUrlLoading or shouldInterceptRequest method in the custom WebViewClient to force all network requests to be made through the HTTPS protocol in the APP's Webview configuration.

[0067] Check the protocol of the request URL on every communication, and if the result is wrong, reject or redirect to the HTTPS version.

[0068] 2.6.2 Step S601, Certificate Verification and SSL Pinning:

[0069] When making an HTTPS connection, Webview verifies the validity of the server certificate, including checking whether the certificate is issued by a trusted CA and whether the certificate has expired.

[0070] Implement SSL certificate pinning, hard-code the server's public key fingerprint or certificate into the app, and compare it with the received server certificate to enhance the defense against man-in-the-middle attacks.

[0071] (III) Mechanism for solving technical problems:

[0072] 3.1 Unified management and personalized configuration (S1&S2):

[0073] At the platform level, a dedicated compliant domain name is allocated and configured for each APP to ensure that the resource requests of each application originate from a controlled and secure server. These domain names are resolved to the correct server IP through the DNS service, and DNSSEC technology is implemented to prevent domain name hijacking, ensuring compliance and security at the infrastructure level. When the APP is started or updated for the first time, it automatically obtains the latest compliant domain name configuration from the platform side, dynamically replaces the default settings, and prepares a compliant domain name foundation for Webview loading. In this way, even if the compliance requirements change, the APP can adapt in time to ensure compliance of resource access.

[0074] 3.2 Real-time control and compliance loading (S3&S4)

[0075] At the moment of loading the Webview page, the APP takes the initiative to intervene and replace the main domain name of the page request with the compliant domain name obtained from the platform. Whether it is the initial loading of the page or the internal dynamically loaded resources, it strictly follows the unified compliant domain name rules, effectively controlling the flow of data.

[0076] Furthermore, we further deepen the control by implementing monitoring and domain name replacement logic for API interface or resource requests initiated through JavaScript within the page to ensure that these requests also follow the compliance rules of the outer layer, avoiding cross-domain issues while ensuring the compliance of all data exchange processes.

[0077] 3.3 Security policy reinforcement and data encryption (S5&S6)

[0078] By implementing the same-origin policy and CORS policy, illegal cross-domain requests are strictly restricted, further consolidating the network security boundary of the APP and ensuring the security and compliance of data interaction. In addition, the HTTPS protocol is used for data communication throughout the process, combined with certificate verification and SSL Pinning and other technologies to ensure the encryption and integrity of data during transmission, effectively preventing data from being eavesdropped or tampered with, and meeting the compliance requirements of data protection.

[0079] 3.4 Overall Effect

[0080] The technical solution of the present invention forms a closed-loop compliance control system through the linkage of 3.1 to 3.3 above, and realizes full-link compliance assurance from domain name management to data transmission. It not only allows different APP applications to dynamically access specific resources and interfaces according to their own configurations, but also ensures that when a single page is accessed, the behavior of all APPs complies with the prescribed security and privacy standards, effectively responds to data protection laws and regulatory requirements, reduces compliance risks, and improves the security and privacy protection level of user data.

[0081] (IV) Compared with the prior art, the beneficial effects of the present invention are:

[0082] (1) Strengthening data security and privacy protection: The present invention ensures that all data communications are carried out through the HTTPS protocol. Encrypted transmission protects user data from eavesdropping and tampering, and enhances the security of the data transmission process. The security strategy of the present invention greatly reduces the risk of man-in-the-middle attacks and ensures the authenticity of both parties in communication and the integrity of the data.

[0083] (2) Improve compliance and reduce legal risks: This invention ensures that the APP complies with the latest data protection laws and industry standards no matter when and where it is run by dynamically acquiring and applying compliant domain names, effectively reducing compliance risks caused by improper use of domain names. In addition, the same-origin policy and CORS policy strictly restrict illegal cross-domain requests, ensuring that data interaction complies with network security specifications and reducing potential compliance issues.

[0084] (3) Enhanced user experience and reliability: The present invention uses a real-time domain name replacement mechanism in S3 and S4, so that when users use different APPs to access the same content, they will not feel any interruption or difference caused by the domain name change, thereby improving the consistency and fluency of the user experience. In addition, through HTTPS optimization, caching strategy and preloading technology, the page loading time is reduced, the resource loading efficiency is improved, and the high-performance operation of the APP is guaranteed.

[0085] (4) Flexible response to changes and simplified management: S2 and S3 of the present invention enable the APP to quickly respond to domain name updates on the platform side and adjust resource access policies without manual user operation or re-publishing the APP, which greatly simplifies management complexity and improves the ability to adapt to market changes and changes in compliance requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] Figure 1 It is a schematic diagram of the method flow of the present invention. DETAILED DESCRIPTION

[0087] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0088] Example: Figure 1 As shown, this example provides a technical solution for a multi-domain switching method, which includes the following steps S1 to S6.

[0089] In this embodiment, regarding step S1, domain name configuration and resolution management: before the application is released, the administrator allocates and configures a dedicated compliant domain name for each APP on the platform side. Using the DNS service, these domain names are resolved to the corresponding IP addresses. Ensure a fast and stable access path. At the same time, implement DNSSEC security enhancement technology to prevent DNS hijacking.

[0090] Specifically, step S100, domain name planning and allocation: In this stage, firstly, detailed domain name planning is carried out based on the specific business needs of each APP, including but not limited to selecting or creating primary domain names and subdomain names, ensuring that they not only conform to the brand identity, but also clearly reflect the functional areas of different APPs or services.

[0091] For example, for a company with multiple sub-brands, each sub-brand application is assigned a separate sub-domain, such as app1.example.com and app2.example.com. These domains are not only used for direct user access, but also for API requests and static resource loading, such as images, CSS, and JavaScript files. This information is recorded and managed by setting up special configuration items in the platform's management system. The advantage of doing this is that the resource access paths of different apps can be clearly distinguished, which facilitates subsequent management and optimization.

[0092] Specifically, step S101, DNS record creation and configuration: Based on the planned domain name, configure the corresponding records on the DNS server. A records and AAAA records correspond to IPv4 and IPv6 addresses respectively, ensuring that users in different network environments can access smoothly;

[0093] CNAME records are used for alias resolution and are more flexible. Setting a reasonable TTL (time to live) value is key, as it determines how long the DNS resolution result is retained in the local DNS cache. A shorter TTL value means that when the server IP changes, the client can obtain the new resolution result more quickly.

[0094] Specifically, step S102 implements DNSSEC security enhancement: In order to prevent security threats such as DNS hijacking, DNSSEC (Domain Name System Security Extension) is introduced. Through the public and private key pairs generated on the DNS server, all DNS records published to the outside will be digitally signed by the private key to form DS records. These records are then uploaded to the domain name registrar to establish a complete chain of trust. DNSSEC ensures that the DNS records queried by users have not been tampered with, improving the overall security of domain name resolution. Finally, the effectiveness of DNSSEC is verified by special tools to ensure the consistency and reliability of DNS query results worldwide.

[0095] Furthermore, the Java underlying code program of step S1 is as follows:

[0096]

[0097]

[0098]

[0099] public static void main(String[]args){

[0100] DnsManagement manager=new DnsManagement();

[0101] manager.createDnsRecord("sub.example.com","A",

[0102] "93.184.216.34");

[0103] manager.configureDnsSec("sub.example.com",

[0104] "examplePublicKey","exampleDSRecord");

[0105] }

[0106] }

[0107] It should be noted that the above program sends requests to the DNS service provider's REST API through an HTTP client library (such as Apache HttpClient or OkHttp). These requests carry the necessary parameters to create DNS records, update TTL values, and configure DNSSEC. You need to follow the service provider's API documentation to construct appropriate request bodies and header information. In actual operation, you need to replace apiUrl with the real API address and use a valid API key for authentication.

[0108] In this embodiment, regarding step S2, dynamic domain name management on the APP side: In multi-APP application scenarios, especially those APP systems that need to share core business functions but operate independently, each APP may need to point to specific server resources due to different regions, regulations, and partner needs. In order to meet compliance requirements and flexibility, it is key to achieve dynamic configuration of resources and interfaces. When the APP is started for the first time or each time it is updated, the current compliant domain name configuration is obtained from the platform side through an API request to ensure that the APP uses the latest compliant domain name. The APP replaces the default or old domain name configuration in the application with the obtained compliant domain name to prepare for subsequent Webview loading.

[0109] Specifically, step S200, read the API interface:

[0110] 1) Implementation environment: Deploy RESTful API services on the platform side and use the HTTPS protocol to ensure the security of data transmission, prevent man-in-the-middle attacks, and protect sensitive domain name information.

[0111] 2) Data structure design: API response data includes "domain name type" (to distinguish API request domain name from static resource domain name), "domain name string" (actual domain name address) and "validity period" (to ensure that the APP requests renewal again before expiration). This structured design facilitates parsing and management on the APP side.

[0112] 3) Security Verification: Authentication is performed through the API Key mechanism to ensure that only authorized apps can obtain domain name configuration information, thus enhancing the security of the system.

[0113] Specifically, step S201, executes the API call logic:

[0114] S2010 first startup processing: The initialization logic is automatically triggered when the APP is installed and started for the first time, ensuring that the APP can use the latest compliant domain name configuration from the beginning, avoiding problems caused by using outdated or non-compliant domain names.

[0115] S2011 update mechanism: Establish a self-check mechanism for the APP version. Once a new version is detected, in addition to regular functional updates, it will also trigger the re-acquisition of domain name configuration to ensure that each update can synchronize the latest compliance requirements.

[0116] S2012 domain name configuration storage and replacement:

[0117] 1) Storage: The APP stores the obtained compliant domain name information locally (such as SharedPreferences, which is suitable for lightweight data storage; SQLite database, which is suitable for structured data management; or direct file storage). This approach ensures that the previously cached valid domain name can be used even when offline.

[0118] 2) Replacement: By defining a set of flexible domain name replacement rules or policies within the APP, the original hard-coded domain name is replaced with the latest compliant domain name.

[0119] For example, customized configuration of network request libraries (such as OkHttp and Volley) ensures that all network requests point to the correct domain name.

[0120] S2013 dynamic replacement: This step ensures that the APP can use the latest compliant domain name every time it makes a network request or loads a web resource, avoiding service interruptions or compliance risks caused by domain name changes.

[0121] Furthermore, the Java underlying code program of step S2 is as follows:

[0122]

[0123]

[0124]

[0125]

[0126] It is understandable that in the above program, the API request uses the OkHttp library to send an HTTPS request to the platform API to obtain the compliant domain name configuration. Parse the API response in JSON format and extract the domain name information. Use SharedPreferences to store the obtained domain name information for quick access later. At the same time, please replace YOUR_API_KEY with the actual API key. The storeDomains and replaceDefaultDomains methods need to be adjusted appropriately according to the specific network request library or Webview loading logic of the APP.

[0127] In this embodiment, regarding step S3, Webview page loading: before loading the webview webpage, the APP actively replaces the primary domain name of the page request with the domain name obtained from the platform to ensure that even the domain name in the web link meets the compliance requirements. When the Webview loads the page, all external HTTP / HTTPS requests (including page elements, images and / or scripts) will be initiated using the replaced compliant domain name.

[0128] Specifically, step S300, initialize Webview settings: create a custom WebViewClient or WebChromeClient subclass for Webview. These two classes allow developers to customize the behavior of Webview, especially in handling network requests, page loading events, etc. By overriding related methods (such as shouldOverrideUrlLoading, onLoadResource), APP can intervene and control the loading process of Webview.

[0129] Specifically, step S301, request interception and domain name replacement: in the custom WebViewClient, override the shouldOverrideUrlLoading method to check and intercept all URLs to be loaded. If the domain name in the URL does not match the compliant domain name stored in the current APP, a replacement operation is performed.

[0130] Use regular expressions or string operations to replace non-compliant domain names in the original request URL with compliant domain names. Make sure the replacement logic can identify various forms of domain names (including subdomains) while keeping the rest of the URL unchanged, such as the query string and path.

[0131] Specifically, step S302, resource loading and redirection processing: For dynamic requests initiated by JavaScript inside the page, use addJavascriptInterface to inject a custom JavaScript object into Webview, and proxy all network requests through this object to ensure that JavaScript requests also go through the domain name replacement logic. When processing redirection requests, continue to apply the domain name replacement logic to ensure that each step in the redirection chain uses a compliant domain name to avoid compliance interruption during page jumps.

[0132] Specifically, step S304, HTTPS and certificate verification: configure Webview to strictly verify the server's SSL certificate to ensure that the server it communicates with is trustworthy. This includes checking the validity of the certificate, link integrity, and whether the issuing authority is trusted. For internal servers that use custom SSL certificates, these certificates need to be pre-imported and trusted in the APP to ensure that loading does not fail due to certificate issues during the verification process.

[0133] Furthermore, the Java underlying code program of step S3 is as follows:

[0134]

[0135]

[0136]

[0137] }

[0138] @JavascriptInterface

[0139] public void dynamicLoadUrl(String url){

[0140] / / You can apply the domain name replacement logic again here

[0141] String compliantUrl=replaceNonCompliantDomain(url,getCompliantDomain());

[0142] ((WebView)((AppCompatActivity)

[0143] mContext).findViewById(R.id.web_view)).loadUrl(compliantUrl);

[0144] In the above program, the non-compliant domain name in the request is intercepted and replaced by a custom WebViewClient. By overriding the shouldOverrideUrlLoading method, the page loading URL can be controlled and intercepted. The addJavascriptInterface interface is provided to JavaScript calls to handle dynamically loaded requests. The WebViewClient callback ensures the certificate verification of the HTTPS connection. onReceivedSslError is used to handle SSL certificate verification errors, decide whether to ignore the error and continue loading, and customize the processing logic according to the project security policy.

[0145] In this embodiment, regarding step S4, internal resource and interface access control: if a request for an API interface or additional resources is initiated through a JavaScript script within the page, by monitoring and replacing the domain name part in the request, it is ensured that these requests also follow the outer layer's compliant domain name rules, thereby avoiding cross-domain issues while maintaining compliance.

[0146] Specifically, step S400, JavaScript injection and monitoring: During the initialization phase of Webview, a custom Java object is injected into the Webview environment using the addJavascriptInterface method. This object acts as a bridge, enabling Java code to interact with JavaScript scripts in Webview. Specifically, this object contains at least two main methods: one is used to monitor network requests within Webview, and the other is used to dynamically replace non-compliant domain names in requests with compliant domain names.

[0147] On the JavaScript side of the web page, by calling the methods provided by the injected Java object (such as initMonitor), the monitoring logic is initialized and a safeFetch function is defined. This function is an encapsulated network request method that replaces the native fetch or XMLHttpRequest. All network requests are issued through safeFetch, ensuring full control and management of the requests.

[0148] Specifically, step S401, domain name check and replacement before request: Inside the safeFetch function, first perform a domain name compliance check. If it is detected that the domain name in the requested URL does not conform to the known compliant domain name list, the function will use similar logic to step S3, that is, replace the non-compliant domain name with a compliant domain name through string replacement or regular expression matching. In this way, even requests dynamically initiated by JavaScript can ensure that they comply with the compliance rules of the application.

[0149] At the same time, on the server side, the CORS (cross-origin resource sharing) policy must be configured to allow requests initiated from the compliant domain name of the Webview loading page. The specific configuration includes setting the Access-Control-Allow-Origin field in the response header. The field value should match the compliant domain name of the APP, thereby ensuring that the browser or Webview allows the successful execution of cross-domain requests and avoids request failures caused by cross-domain issues.

[0150] In this embodiment, regarding step S5, security policy implementation: implement the same-origin policy and CORS policy in the webview environment to limit illegal cross-domain requests.

[0151] Specifically, step S500, execute CORS policy: on the API server side, configure CORS policy according to the compliant domain name of the page loaded by the front-end Webview. This usually involves adding specific fields in the response header, such as:

[0152] 1) Access-Control-Allow-Origin: Set the allowed request source, which can be a specific compliant domain name.

[0153] 2) Access-Control-Allow-Methods: specifies the allowed HTTP methods, such as GET, POST, PUT, DELETE, etc.

[0154] 3) Access-Control-Allow-Headers: Lists the allowed request header fields to ensure that the API can receive the necessary information from compliant requests.

[0155] In the custom WebViewClient of the APP, by overriding the onLoadResource method, you can further check and process whether the loaded resources follow the CORS rules. Although this step is usually handled automatically by Webview, overriding this method can add additional checks or logging logic.

[0156] Specifically, step S501, execute JavaScript security policy: enhance the security of web page content through Content Security Policy (CSP) policy. <meta> Add CSP instructions to the tag, or set Content-Security-Policy in the HTTP response header through the server. CSP defines a whitelist system that specifies which resources (such as images, scripts, styles, etc.) can be loaded and can specify the source.

[0157] For example, default-src'self' indicates that only resources from the same origin are allowed to be loaded, thereby enhancing the control over cross-domain loading.

[0158] Specifically, step S502, execute the cross-frame scripting policy: by setting the HTTP response header X-Frame-Options (applicable to old browsers) or using the frame-ancestors directive in CSP (recommended by modern browsers), you can limit the page from being embedded in the iframe of other sites. For example, X-Frame-Options:SAMEORIGIN only allows the nesting of pages of the same origin, and Content-Security-Policy:frame-ancestors'none' completely prohibits nesting, effectively preventing clickjacking attacks.

[0159] It is understandable that by implementing the CORS policy, the sources, methods, and headers of cross-domain requests are precisely controlled, illegal cross-domain requests are effectively blocked, the risk of information leakage and data tampering is reduced, and the access compliance of the API interface is ensured. The execution of CSP limits the loading of unsafe resources, such as malicious script injection, improves the anti-attack capability of web pages, protects users from threats such as XSS (cross-site scripting attacks), and enhances user experience and trust. By limiting the nesting rules of pages in iframes, clickjacking attacks are effectively prevented, the safety of users during the interaction process is protected, and users are prevented from triggering malicious operations without knowing it, thus improving the security level of the application.

[0160] Furthermore, the Java underlying code program (based on Spring Boot) of step S5 is as follows:

[0161]

[0162]

[0163] The above program configures a global CORS filter through the Spring framework, allowing requests from https: / / example.com and opening all HTTP methods and headers.

[0164] setAllowCredentials(true) allows the carrying of credential information such as cookies, which can be adjusted according to actual needs.

[0165] And for Android client Webview setup, CORS support is with custom WebViewClient:

[0166]

[0167] By overriding shouldInterceptRequest, developers can intervene in the interception and processing of network requests. CSP policies are usually set on the web page, but can be added to the loaded web page.

[0168] <meta> Tags or dynamically set via JavaScript. On the Android side, JavaScript is injected to directly control the CSP settings of the web page. In addition, by setting X-Frame-Options or Content-Security-Policy in the HTTP response header, the page can be restricted from being embedded in the iframe of other pages, thereby preventing clickjacking attacks.

[0169] In this embodiment, regarding step S6, data communication: data communication is performed via the HTTPS protocol.

[0170] Specifically, step S600, mandatory execution of HTTPS protocol: In the custom WebViewClient of the Android application, by overriding the shouldOverrideUrlLoading or shouldInterceptRequest method, mandatory HTTPS upgrades for all network request protocols can be implemented. This ensures that all external communications initiated through Webview use the secure HTTPS protocol, thereby improving the security of data transmission. For example:

[0171]

[0172]

[0173] In the above program, when Webview tries to load a URL, it checks the protocol of the request through the overridden method. If it is found to be HTTP protocol, the code will automatically convert it to HTTPS protocol to ensure the security of communication. This method effectively prevents the risks brought by plain text transmission, such as data being eavesdropped or tampered with.

[0174] Specifically, step S601, certificate verification and SSL Pinning: In order to ensure the security of the HTTPS connection, Webview also needs to verify the validity of the server certificate, including checking whether the certificate is issued by a trusted certificate authority (CA) and whether the certificate is expired. In addition, the implementation of SSL certificate pinning (SSL Pinning) further improves security.

[0175] The server's certificate fingerprint (usually a SHA-256 hash value) is preset in the APP. Then when establishing an HTTPS connection, the received server certificate is compared with the preset fingerprint. If they match, the connection is considered secure, otherwise it is considered unsafe.

[0176] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0177] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A method for switching multiple domain names, characterized in that: The steps include: S1, domain name configuration and resolution management: allocate and configure a unique compliant domain name for each APP on the platform side; use DNS service to resolve the domain name to the corresponding IP address; S2, dynamic domain name management on the APP side: When the APP is first started or updated each time, the platform side requests the current compliant domain name configuration through the API. The APP replaces the default or old domain name configuration in the application with the obtained compliant domain name; S3, Webview page loading: Before loading the webview webpage, the APP actively replaces the primary domain name of the page request with the domain name obtained from the platform; when the Webview loads the page, all external HTTP / HTTPS requests are initiated using the replaced compliant domain name; S4, internal resource and interface access control: Initiate requests to API interfaces or additional resources through JavaScript scripts on the page, by monitoring and replacing the domain name part in the request; S5, security policy implementation: implement the same-origin policy and CORS policy in the webview environment to limit illegal cross-domain requests; S6, data communication is carried out through the HTTPS protocol.

2. The switching method according to claim 1, characterized in that: In S1, the allocation and parsing methods are: S100, according to the business needs of the APP, determine the domain name type, including the primary domain name, subdomain name and the corresponding purpose, the purpose includes API request and static resource loading; create a dedicated domain name configuration item for each APP in the platform management system, and record the domain name information and the purpose; S101, creating an A record, an AAAA record or a CNAME record on a DNS server for each allocated domain name, pointing to the actual IP address of the application server or the address of the load balancer.

3. The switching method according to claim 2, characterized in that: In the S1, it also includes generating the public key and private key required for DNSSEC on the DNS server for signing the DNS record; using the private key to digitally sign the DNS record to generate a DS record to complete the establishment of the signature verification chain; and confirming through the DNSSEC verification tool that the DNS record has been correctly signed and can be verified by the global DNS system.

4. The switching method according to claim 1, characterized in that: The execution steps of S2 include: S2010, when the APP is installed and started for the first time, an initialization task is triggered, which is responsible for initiating a request to the API interface on the platform side to obtain the compliant domain name configuration; S2011, when it is detected that a new version is available, the above domain name acquisition logic is re-executed after the update; S2012, after the APP successfully obtains the compliant domain name, it stores it locally; S2013, based on the network request library or Webview loading logic, replace the hard-coded default or old domain name in the application with the latest compliant domain name.

5. The switching method according to claim 1, characterized in that: The execution steps in S3 include: S300, by overriding or extending the default behavior when initializing the Webview component in the APP; S301, APP implements interception logic before loading web resources and executes interception request S302, when a dynamic request is initiated through JavaScript in the page, the JavaScript interface of Webview is called and processed, and the domain name replacement is applied to each request in the redirect chain.

6. The switching method according to claim 5, characterized in that: The above interception logic includes checking the domain name part of the requested URL. If it does not match the compliant domain name stored in the current APP, the original domain name in the requested URL is replaced with the compliant domain name using regular expressions or string replacement.

7. The switching method according to claim 1, characterized in that: The execution steps in S4 include: S400, when Webview is initialized, a custom Java object is injected, which includes methods for monitoring and controlling network requests. In the webpage JavaScript, this injected object is used to wrap or proxy all requests for API interfaces and resources; S401, check whether the domain name of the requested URL is compliant; if it is not compliant, replace it with a compliant domain name using the same logic as in S3 described above; Configure the CORS policy on the server to allow requests from compliant domain names of pages loaded by Webview.

8. The switching method according to claim 1, characterized in that: The execution steps in S5 include: S500, on the API server side, configure the CORS policy to allow requests from specific sources S501, specifying the resource types and sources allowed to be loaded based on the whitelist; S502: prohibit API interfaces and sensitive resources from being loaded in non-same-origin iframes.

9. The switching method according to claim 1, characterized in that: In S6, the protocol of the request URL is checked during each communication, and if the result is wrong, it is rejected or redirected to the HTTPS version; When Webview makes an HTTPS connection, it verifies the validity of the server certificate, including checking whether the certificate is issued by a trusted CA and whether the certificate has expired. Implement SSL certificate pinning to hardcode the server's public key fingerprint or certificate into the app and compare it with the received server certificate.

10. A storage medium, characterized in that: The storage medium stores program instructions capable of implementing the switching method as described in any one of claims 1-9.

Images