Method, system, device and medium for cross-domain video streaming playback

Abstract

The present invention discloses a method, system, device and medium for cross-domain playback of video streams, and relates to the field of streaming media technology. Video stream request information and an initial local cache library are used to perform cache identification to determine the cache type corresponding to the video stream request information. If the cache type is the first cache type, the video stream corresponding to the video stream request information is obtained and a cross-domain playback token is added to the returned message header to generate cross-domain pass data. Based on the cross-domain pass data, the initial local cache library is updated to construct the first cross-domain playback data corresponding to the video stream request information. If the cache type is the second cache type, the honeypot logic is used to set the interception information to generate cross-domain rejection data. Based on the cross-domain rejection data, the initial local cache library is updated to construct the second cross-domain playback data corresponding to the video stream request information. While ensuring access to a trusted web page, the initial local cache library is allowed to be quickly updated, and cross-domain requests from untrusted sources are rejected.

Description

Technical Field

[0001] The present invention relates to the field of streaming media technology, and in particular to a method, system, device and medium for cross-domain playback of video streams. Background Art

[0002] When using a web player to play HLS (HTTP Live Streaming, streaming protocol) video streams, if the playback address is different from the domain name of the streaming server, it will be blocked by the browser due to cross-domain issues.

[0003] The current cross-origin response header for video streams typically allows cross-origin requests from any source by default, which poses an information security risk. If a whitelist is configured on the streaming server, each change to the whitelist requires restarting the streaming service. Summary of the Invention

[0004] The present invention provides a method, system, device and medium for cross-domain playback of video streams, which solves the technical problem that the existing cross-domain playback method of video streams requires restarting the streaming media service every time the whitelist information is changed, and allows any request source to cross the domain by default, resulting in low security.

[0005] The present invention provides a method for cross-domain playback of video streams, comprising:

[0006] When receiving video stream request information from a web page, performing cache identification using the video stream request information and the initial local cache library to determine the cache type corresponding to the video stream request information;

[0007] If the cache type is the first cache type, obtaining the video stream corresponding to the video stream request information and adding a cross-domain playback token to the returned message header to generate cross-domain pass data;

[0008] The initial local cache library is updated based on the cross-domain pass data, and first cross-domain playback data corresponding to the video stream request information is constructed;

[0009] If the cache type is the second cache type, the honeypot logic is used to set the interception information and generate cross-domain rejection data;

[0010] The initial local cache library is updated based on the cross-domain rejection data, and second cross-domain playback data corresponding to the video stream request information is constructed.

[0011] Optionally, the first cache type includes cache non-existence and a whitelist address; and the step of using the video stream request information and the local cache library to perform cache identification to determine the cache type corresponding to the video stream request information includes:

[0012] Determine whether the request address in the video stream request information does not exist in the local cache library;

[0013] If so, the cache type corresponding to the video stream request information is that the cache does not exist;

[0014] If not, determine whether the requested address is a whitelist address;

[0015] If so, the cache type corresponding to the video stream request information is the whitelist address;

[0016] If not, the cache type corresponding to the video stream request information is the second cache type.

[0017] Optionally, the local cache library includes an online cache pool; the step of updating the initial local cache library based on the cross-domain pass data and constructing the first cross-domain playback data corresponding to the video stream request information includes:

[0018] Determine whether a pass address corresponding to the cross-domain pass data exists in the online cache pool;

[0019] If yes, then update the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library;

[0020] If not, using the initial local cache library as the first target local cache library;

[0021] The first target local cache library and the cross-domain pass data are used to construct first cross-domain playback data corresponding to the video stream request information.

[0022] Optionally, the step of updating the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library includes:

[0023] Determine whether the line program number corresponding to the cross-domain passing data is a preset sequence number;

[0024] If so, set the thread lock and request the whitelist configuration service through the timer to generate the whitelist configuration data;

[0025] Request the whitelist service according to the whitelist configuration data through the https interface to obtain the whitelist information saved in json format;

[0026] Using the whitelist information to update the initial local cache library to generate a first target local cache library;

[0027] If not, the initial local cache library is used as the first target local cache library.

[0028] Optionally, the second cache type includes a non-whitelist address and a blacklist address; and updating the initial local cache library based on the cross-domain rejection data to construct the second cross-domain playback data corresponding to the video stream request information includes:

[0029] If the cache type corresponding to the cross-domain rejection data is a non-whitelist address, updating the initial local cache library based on a preset update cache logic to obtain a second target local cache library;

[0030] If the domain name corresponding to the cross-domain rejection data does not exist in the second target local cache library, constructing cache period data corresponding to the domain name according to a preset period;

[0031] Constructing second cross-domain playback data corresponding to the video stream request information by using the cross-domain rejection data, the cache period data, and the second target local cache library;

[0032] If the cache type corresponding to the cross-domain rejection data is a blacklist address, constructing warning data;

[0033] The initial local cache library is used as the second target local cache library, and combined with the alarm data, second cross-domain playback data corresponding to the video stream request information is constructed.

[0034] The present invention also provides a video stream cross-domain playback system, comprising:

[0035] A cache type determination module is configured to, upon receiving video stream request information from a web page, perform cache identification using the video stream request information and an initial local cache library to determine a cache type corresponding to the video stream request information;

[0036] A cross-domain pass data generation module is configured to obtain the video stream corresponding to the video stream request information and add a cross-domain playback token to the returned message header to generate cross-domain pass data if the cache type is the first cache type;

[0037] A first cross-domain playback data construction module is configured to update the initial local cache library based on the cross-domain pass data and construct first cross-domain playback data corresponding to the video stream request information;

[0038] a cross-domain rejection data generation module, configured to, if the cache type is the second cache type, use honeypot logic to set interception information and generate cross-domain rejection data;

[0039] The second cross-domain playback data construction module is configured to update the initial local cache library based on the cross-domain rejection data and construct second cross-domain playback data corresponding to the video stream request information.

[0040] Optionally, the first cache type includes cache non-existence and whitelist address; the cache type determination module is specifically configured to:

[0041] Determine whether the request address in the video stream request information does not exist in the local cache library;

[0042] If so, the cache type corresponding to the video stream request information is that the cache does not exist;

[0043] If not, determine whether the requested address is a whitelist address;

[0044] If so, the cache type corresponding to the video stream request information is the whitelist address;

[0045] If not, the cache type corresponding to the video stream request information is the second cache type.

[0046] Optionally, the local cache library includes an online cache pool; and the first cross-domain playback data construction module includes:

[0047] A cross-domain passing data judgment module is used to judge whether a passing address corresponding to the cross-domain passing data exists in the online cache pool;

[0048] The first target local cache library generates a first submodule for, if yes, updating the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library;

[0049] The first target local cache library generates a second submodule for, if no, using the initial local cache library as the first target local cache library;

[0050] The first cross-domain playback data construction submodule is configured to construct first cross-domain playback data corresponding to the video stream request information using the first target local cache library and the cross-domain pass data.

[0051] The present invention also provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of implementing any of the above-mentioned video stream cross-domain playback methods.

[0052] The present invention also provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed, it implements any of the above-mentioned methods for cross-domain playback of video streams.

[0053] It can be seen from the above technical solutions that the present invention has the following advantages:

[0054] The present invention, upon receiving a video stream request from a webpage, uses the video stream request information and an initial local cache to perform cache identification and determine the cache type corresponding to the video stream request information. If the cache type is the first cache type, the video stream corresponding to the video stream request information is obtained and a cross-domain playback token is added to the returned message header to generate cross-domain approval data. The initial local cache is updated based on the cross-domain approval data to construct first cross-domain playback data corresponding to the video stream request information. If the cache type is the second cache type, honeypot logic is used to set interception information to generate cross-domain rejection data. The initial local cache is updated based on the cross-domain rejection data to construct second cross-domain playback data corresponding to the video stream request information. This solves the technical problem of existing cross-domain playback methods for video streams, which require restarting the streaming media service every time whitelist information is changed and default to allowing cross-domain requests from any source, resulting in low security. By combining multiple methods, the frequency of querying the whitelist service is reduced. A forged error method is used to deceive attackers into continuing attacks using honeypot tools. The initial local cache is updated based on the cross-domain approval data and cross-domain rejection data, ensuring trusted webpage access while allowing rapid updates to the initial local cache and rejecting cross-domain requests from untrusted sources. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0056] Figure 1 A flowchart of a method for cross-domain playback of video streams provided in accordance with the first embodiment of the present invention;

[0057] Figure 2 This is a diagram of the architecture of a cross-domain live streaming system provided by Example 1 of the present invention;

[0058] Figure 3 Honeypot processing logic flow chart provided in the second embodiment of the present invention;

[0059] Figure 4 A flowchart of a method for cross-domain playback of video streams provided in the second embodiment of the present invention;

[0060] Figure 5 A schematic diagram of a streaming media gateway cache provided in the second embodiment of the present invention;

[0061] Figure 6 This is a cache query flow chart provided in Example 2 of the present invention;

[0062] Figure 7This is a structural diagram of the existing cross-domain video streaming playback solution provided in the second embodiment of the present invention;

[0063] Figure 8 This is a structural diagram of the video stream cross-domain playback solution provided in Example 2 of the present invention;

[0064] Figure 9 This is a cross-domain scheduling flow chart provided in the second embodiment of the present invention;

[0065] Figure 10 This is a structural block diagram of a video stream cross-domain playback system provided in Example 3 of the present invention. DETAILED DESCRIPTION

[0066] Embodiments of the present invention provide a method, system, device, and medium for cross-domain playback of video streams, which are used to solve the technical problem that existing cross-domain playback methods of video streams require restarting the streaming media service every time whitelist information is changed, and any request source is allowed to cross domains by default, resulting in low security.

[0067] In order to make the purpose, features, and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0068] See also Figure 1 , Figure 1 This is a flowchart of the steps of a method for cross-domain playback of video streams provided in Example 1 of the present invention.

[0069] like Figure 2 As shown, the video stream cross-domain playback method provided by the present invention is implemented based on a streaming media cross-domain live broadcast system, which includes a streaming media cluster, a whitelist configuration service, a streaming media gateway and a honeypot. The streaming media cluster is a group of servers that provide video streaming services, and the device end connects to the server to report the video stream. The whitelist configuration service is used to configure the black / white list, which can be called by the web page through an interface application or manually configured by the administrator. The streaming media gateway is used to implement cache and http request functions on conventional gateway services. The honeypot is used to return false business success data instead of a business error when the request source verification fails, to induce further attacks and record and report attack behaviors.

[0070] The specific execution process of the system is as follows: Step 1, the web page requests the whitelist service to register the whitelist information; Step 2, the web page requests the streaming gateway to obtain the video stream; Step 3, the streaming gateway verifies the cache. The verification cache scheme is shown in the specific execution process of the video stream cross-domain playback method below; Step 4, for requests that are not within the cache range, the whitelist interface is queried to update the cache; Step 5, the streaming gateway obtains the video push stream from the streaming service; Step 6, the surveillance camera pushes the video stream to the streaming service; Step 7, the streaming gateway adds a cross-domain playback token to the returned video stream, that is, adds a cross-domain playback token to the returned message header, allowing specific websites to play cross-domain, and realize the live broadcast of cross-domain video streams on the web page.

[0071] A method for cross-domain playback of a video stream provided in Example 1 of the present invention includes:

[0072] Step 101: When video stream request information is received from a web page, cache identification is performed using the video stream request information and an initial local cache library to determine a cache type corresponding to the video stream request information.

[0073] In an embodiment of the present invention, the initial local cache library includes two cache pools, namely, a valid cache and an expired cache. The valid cache stores the whitelist information within the cache period, and the expired cache is moved to the expired cache pool after the valid cache times out. It is judged whether the request address in the video stream request information does not exist in the local cache library, that is, it is judged whether the request address in the video stream request information does not exist in the valid cache pool and the expired cache pool. If not, the cache type corresponding to the video stream request information is cache non-existence. If the request address in the video stream request information exists in the valid cache pool or the expired cache pool, it is judged whether the request address is a whitelist address. If so, the cache type corresponding to the video stream request information is a whitelist address. If not, the cache type corresponding to the video stream request information is the second cache type.

[0074] Step 102: If the cache type is the first cache type, obtain the video stream corresponding to the video stream request information and add a cross-domain playback token to the returned message header to generate cross-domain pass data.

[0075] Token is a temporary token in computer identity authentication, generally used for invitation and login system.

[0076] In this embodiment of the present invention, a streaming media service is requested using a domain name. When the cache type corresponding to the video stream request information indicates that the cache does not exist or the address is a whitelist address, the video stream corresponding to the video stream request information is obtained and a whitelist cross-domain playback token is added to the returned message header. Cross-domain pass data is generated and sent to the web page. When the web page requests access to the device's online video stream, each browser interprets the cross-domain permission message header and allows the web service to obtain data normally, thereby playing the video stream normally.

[0077] Step 103: Update the initial local cache library based on the cross-domain data, and construct first cross-domain playback data corresponding to the video stream request information.

[0078] In this embodiment of the present invention, a determination is made as to whether the pass address corresponding to the cross-domain pass data exists in the online cache pool. If so, the initial local cache is updated according to the thread corresponding to the cross-domain pass data to generate a first target local cache. If not, the initial local cache is used as the first target local cache. Using the first target local cache and the cross-domain pass data, first cross-domain playback data corresponding to the video stream request information is constructed.

[0079] Step 104: If the cache type is the second cache type, the honeypot logic is used to set the interception information and generate cross-domain rejection data.

[0080] In the embodiment of the present invention, Figure 3 As shown, when the cache type is a whitelist address or the cache does not exist, the video stream request information is a normal request, the gateway passes the security check, and sends the m3u8 / ts request to the streaming service. The streaming service returns the corresponding data, generates cross-domain rejection data and sends it to the web page.

[0081] When the cache type is a blacklist address or a non-whitelist address, the gateway security check fails. When the gateway sends an m3u8 request, a normal business return is forged through the honeypot logic, and the attacker information is recorded to generate cross-domain rejection data. When the gateway sends a ts request, a random business error is forged through the honeypot to generate cross-domain rejection data. Forged random business errors include random forged request timeouts, device stop pushing streams, and false data with incorrect video stream formats to induce the attacker to continue the attack and record the attack behavior. The attacker information (IP, time, operation, additional attack behavior, and scope of impact) is reported to the blacklist and whitelist service for manual processing. Among them, random forged request timeout means that the data is discarded after the request and no return is made. Device stop pushing streams means that the m3u8 file without pushing streams is returned after the request. Video stream format error means that the ts file generated by the honeypot is returned, but the ts file cannot be parsed.

[0082] Step 105: Update the initial local cache library based on the cross-domain rejection data, and construct second cross-domain playback data corresponding to the video stream request information.

[0083] In an embodiment of the present invention, if the cache type corresponding to the cross-domain rejection data is a non-whitelist address, the initial local cache library is updated based on the preset update cache logic to obtain a second target local cache library. If the domain name corresponding to the cross-domain rejection data does not exist in the second target local cache library, cache period data corresponding to the domain name is constructed according to a preset period. The cross-domain rejection data, the cache period data, and the second target local cache library are used to construct the second cross-domain playback data corresponding to the video stream request information.

[0084] If the cache type corresponding to the cross-domain rejection data is a blacklist address, alarm data is generated, the initial local cache library is used as the second target local cache library, and combined with the alarm data, second cross-domain playback data corresponding to the video stream request information is generated.

[0085] In an embodiment of the present invention, upon receiving a video stream request from a webpage, cache identification is performed using the video stream request information and an initial local cache to determine the cache type corresponding to the video stream request information. If the cache type is the first cache type, the video stream corresponding to the video stream request information is obtained and a cross-domain playback token is added to the returned message header to generate cross-domain approval data. The initial local cache is updated based on the cross-domain approval data to construct first cross-domain playback data corresponding to the video stream request information. If the cache type is the second cache type, honeypot logic is used to set interception information to generate cross-domain rejection data. The initial local cache is updated based on the cross-domain rejection data to construct second cross-domain playback data corresponding to the video stream request information. This solves the technical problem of existing cross-domain playback methods for video streams, which require restarting the streaming media service every time whitelist information is changed and, by default, allow cross-domain requests from any source, resulting in low security. By combining multiple methods, the frequency of querying the whitelist service is reduced. A forged error method is used to deceive attackers into continuing attacks using honeypot tools. The initial local cache is updated based on the cross-domain approval data and cross-domain rejection data, allowing timely updates of whitelist information and the configuration of temporary ranking lists.

[0086] See also Figure 4 , Figure 4 This is a flowchart of the steps of a method for cross-domain playback of video streams provided in Example 2 of the present invention.

[0087] Another method for cross-domain playback of video streams provided by Example 2 of the present invention includes:

[0088] Step 401: When video stream request information is received from a web page, cache identification is performed using the video stream request information and the initial local cache library to determine the cache type corresponding to the video stream request information.

[0089] Furthermore, the first cache type includes cache non-existence and whitelist address. Step 401 may include the following sub-steps S11-S15:

[0090] S11. Determine whether the request address in the video stream request information does not exist in the local cache library. If so, execute step S12; if not, execute step S13.

[0091] S12: The cache type corresponding to the video stream request information is cache does not exist.

[0092] S13. Determine whether the request address is a whitelist address. If so, execute step S14; if not, execute step S15.

[0093] S14. The cache type corresponding to the video stream request information is a whitelist address.

[0094] S15. The cache type corresponding to the video stream request information is the second cache type.

[0095] In this embodiment of the present invention, the request address in the video stream request information refers to the domain name corresponding to the video stream request information. The webpage uses the website information as a parameter to request the whitelist configuration service to obtain cross-domain permission, i.e., register the whitelist. Upon receiving the video stream request information from the webpage, the gateway layer implements a local caching mechanism. For any request, it sequentially reads the online cache and the timeout cache. The gateway layer then verifies the source of the request and, if the source is trustworthy, issues a cross-domain token specific to the source website.

[0096] When the request address in the video stream request information does not exist in either the online cache pool or the timeout cache pool, the cache type corresponding to the video stream request information is cache not present. When the request address in the video stream request information exists in either the online cache pool or the timeout cache pool, it is considered that the request address in the video stream request information exists in the local cache library, and then a further determination is made as to whether the request address is a whitelist address. If so, the cache type corresponding to the video stream request information is a whitelist address. Otherwise, the cache type corresponding to the video stream request information is a second cache type, which includes blacklist addresses and non-whitelist addresses.

[0097] Step 402: If the cache type is the first cache type, obtain the video stream corresponding to the video stream request information and add a cross-domain playback token to the returned message header to generate cross-domain pass data.

[0098] In the embodiment of the present invention, the specific implementation process of step 402 is similar to that of step 102 and will not be repeated here.

[0099] Step 403 : Determine whether the pass address corresponding to the cross-domain pass data exists in the online cache pool. If so, execute step 404 ; if not, execute step 405 .

[0100] In the embodiment of the present invention, after querying the whitelist, the domain name is cached in the online cache as the key value, and the online cache enters the offline cache when the cache period exceeds. Figure 5 As shown, query domain A: return cross-domain permission. Query domain B: return cross-domain rejection. Query domain C: return cross-domain permission, and update the whitelist of this domain (single entry) through a timer. Query domain D: return cross-domain permission, and update the entire whitelist through a timer.

[0101] After determining that the video stream request information is a cache type of the first cache type, it is necessary to further determine whether the cache corresponding to the video stream request information is available. By judging whether the pass address corresponding to the cross-domain pass data exists in the online cache pool, it is determined whether the cache is available. When the query in the online cache is not empty, it is available. Different from the condition for judging whether the cache exists, if the online cache is empty, but the timeout cache is not empty, it will be regarded as the cache exists (execute the business logic, i.e., execute step S13), but the cache is unavailable (trigger the update of the cache, i.e., execute step 404).

[0102] Step 404: Update the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library.

[0103] Furthermore, step 404 may include the following sub-steps S21-S25:

[0104] S21. Determine whether the line program number corresponding to the cross-domain passing data is a preset serial number. If so, execute step S22; if not, execute step S25.

[0105] S22: Set a thread lock and request a whitelist configuration service through a timer to generate whitelist configuration data.

[0106] S23. Request the whitelist service according to the whitelist configuration data through the https interface, and obtain the whitelist information saved in json format.

[0107] S24: Use the whitelist information to update the initial local cache library to generate a first target local cache library.

[0108] S25: Use the initial local cache library as the first target local cache library.

[0109] HLS (HTTP Live Streaming) is Apple's dynamic bitrate adaptive technology. It is primarily used for audio and video services on PCs and Apple devices. It includes an m3u(8) index file, TS media segment files, and a key encryption string file. The m3u(8) index file is the return file corresponding to the m3u8 request. The TS media segment files are the return files corresponding to the ts request.

[0110] Lua is a compact scripting language. Lua scripts can be easily called by C / C++ code, and can also call C / C++ functions in turn, which makes Lua widely used in applications.

[0111] The Hypertext Transfer Protocol (HTTP) is a simple request-response protocol that typically runs on top of TCP. https (Hypertext Transfer Protocol Secure) is a secure HTTP channel that uses encryption and authentication to ensure secure transmission.

[0112] In the embodiment of the present invention, Figure 6 and Figure 9 As shown, the external request service source queries the local cache and determines whether to query the whitelist interface and add a whitelist token, i.e., a cross-domain playback token, based on the cache result. If the interface needs to be queried, first verify the current nginx thread. If the thread program number is 0, submit the query. The remaining threads do not query. Set a thread lock so that the same thread only requests the interface once at the same time to avoid repeated queries. Then set the nginx timer and return the service data without affecting the current request return time. The service data here refers to cross-domain data, including the video stream file address and video stream returned by the HLS video protocol. Then, request the whitelist service through the https interface to obtain the whitelist information saved in JSON format. Setting the service cache based on the whitelist information means using the whitelist information to update the initial local cache library and generate the first target local cache library. For repeated requests that are not on the whitelist, the gateway layer reports the request source information to the whitelist service layer as the basis for adding to the blacklist.

[0113] Step 405: Use the initial local cache library as the first target local cache library.

[0114] In an embodiment of the present invention, when the pass address corresponding to the cross-domain pass data does not exist in the online cache pool, it means that the cache corresponding to the video stream request information is unavailable, and there is no need to update the initial local cache library, so the initial local cache library is used as the first target local cache library.

[0115] Step 406: Use the first target local cache library and the cross-domain pass data to construct first cross-domain playback data corresponding to the video stream request information.

[0116] In an embodiment of the present invention, the message sent by the web page, i.e., the video stream request information, is authenticated by the streaming gateway, and the request is forwarded to a specific streaming server based on the dynamic password information in the message. When the streaming server returns a message based on the HLS protocol, the gateway converts the response message, adds the dynamic password information, and obtains cross-domain pass data for the client to access the streaming gateway service next time. By determining whether the cache is available, the data of each node is updated to obtain the first target local cache library. The first target local cache library and the cross-domain pass data are used as the first cross-domain playback data corresponding to the video stream request information this time.

[0117] Step 407: If the cache type is the second cache type, the honeypot logic is used to set the interception information and generate cross-domain rejection data.

[0118] In the embodiment of the present invention, the specific implementation process of step 407 is similar to that of step 104 and will not be repeated here.

[0119] Step 408: Update the initial local cache library based on the cross-domain rejection data, and construct second cross-domain playback data corresponding to the video stream request information.

[0120] Furthermore, the second cache type includes non-whitelist addresses and blacklist addresses, and step 408 may include the following sub-steps S31-S35:

[0121] S31: If the cache type corresponding to the cross-domain rejection data is a non-whitelist address, the initial local cache library is updated based on a preset cache update logic to obtain a second target local cache library.

[0122] S32: If the domain name corresponding to the cross-domain rejection data does not exist in the second target local cache library, construct cache period data corresponding to the domain name according to a preset period.

[0123] S33: Use the cross-domain rejection data, the cache period data, and the second target local cache library to construct second cross-domain playback data corresponding to the video stream request information.

[0124] S34. If the cache type corresponding to the cross-domain rejection data is a blacklist address, alarm data is constructed.

[0125] S35: Use the initial local cache library as the second target local cache library, and combine the alarm data to construct second cross-domain playback data corresponding to the video stream request information.

[0126] The preset update cache logic means first verifying the current nginx thread. If the thread program number is 0, the query is submitted, and the remaining threads are not queried. Set a thread lock so that the same thread only requests the interface once at the same time to avoid repeated queries. Set a timer and return business data without affecting the return time of the current request. Request the whitelist service through the https interface to obtain the whitelist information saved in JSON format. Update the initial local cache library based on the whitelist information. For repeated requests that are not on the whitelist, the gateway layer reports the request source information to the whitelist service layer as the basis for adding to the blacklist.

[0127] In an embodiment of the present invention, if the cache type corresponding to the cross-domain rejection data is a non-whitelisted address, a honeypot error is set to return, triggering the cache update logic. If the domain name is still not in the whitelist or blacklist list after the cache update, a shorter cache period, namely the cache period data, is set, typically 30 minutes. During the cache period, no further cache updates are triggered for this domain name. The cross-domain rejection data, the cache period data, and the second target local cache library are then used to construct the second cross-domain playback data corresponding to the video stream request information.

[0128] If the cache type corresponding to the cross-domain rejection data is a blacklist address, the honeypot logic will be directly entered after querying the cache, and the interception information will be set and returned. The cache time is usually more than 24 hours. Requests from blacklist sources will trigger an alarm after being collected by the honeypot program, prompting security maintenance personnel to follow up. For repeated requests not on the whitelist, the request is reported to the whitelist service administrator for analysis and addition to the blacklist / whitelist, generating alarm data. Finally, the data generated during this execution process is used as the second cross-domain playback data corresponding to the video stream request information.

[0129] The present invention can be combined with business expansion requirements to implement a blacklist control function. That is, a blacklist address is added to the whitelist service. For example, if an illegal source requests a streaming gateway, the gateway will parse the request to the corresponding source. Because it does not meet the cross-domain restriction, the video stream cannot be played and further forwarding of the data will be prohibited, thus limiting hotlink playback.

[0130] Specifically, the gateway can use the programmable gateway service, add a custom Lua programming module on it, and execute the following logic: read the source request header, obtain the Origin (source information of the request header) field; call the cache query logic; execute the release and interception logic according to the black and white lists respectively.

[0131] Release status:

[0132] Add a request header interception module in the gateway to execute the cross-domain release logic:

[0133] Add the following request headers:

[0134] ["Access-Control-Allow-Origin"]=origin

[0135] ["Access-Control-Allow-Methods"]="POST,GET,OPTIONS"

[0136] ["Access-Control-Allow-Credentials"]="true"

[0137] The origin in the first line of the request header refers to the domain name of the request source.

[0138] Then return to the business layer for subsequent processing.

[0139] Interception situation:

[0140] Add message body processing and interception logic in the gateway to handle blacklist requests:

[0141] Delete the above-mentioned related request headers in the returned http message;

[0142] Stop requesting the streaming service and return an error message.

[0143] like Figure 7 and Figure 8 As shown, Figure 7 This is a cross-domain playback solution in the prior art. In this playback solution, the client directly accesses the streaming server through the public network. The streaming server cannot verify the identity of the request source and directly returns a cross-domain permission flag to each web page.

[0144] Figure 8 This is the cross-domain playback solution of the present invention. In this invention, the streaming gateway can reverse proxy the streaming service cluster. Through registration or manual configuration, a specific address can be specified to allow cross-domain access. The dynamic password allows the video streaming request based on the HLS protocol to carry the client identity information and the streaming service address information. The streaming gateway converts the HLS protocol response message and adds the dynamic cross-domain token information, without the need for the streaming service to add it separately.

[0145] In the embodiment of the present invention, Figure 9As shown, when a video stream request is received from a webpage, the initial local cache is checked to see if a corresponding cache exists. If not, it is considered an initial request and is accepted by default. If so, it is further determined whether the cache is whitelisted. If the cache is whitelisted or not, the video stream corresponding to the video stream request is obtained and a cross-domain play token is added to the returned message header. Furthermore, it is determined whether the cache corresponding to the video stream request is in the online cache pool to determine whether the cache is available. If the cache is available, there is no need to update the initial local cache; the initial local cache is directly used as the first target local cache and a cross-domain pass is returned, i.e., cross-domain pass data. If the cache is not available, it is determined whether the Nginx kernel is 0, i.e., whether the thread program number corresponding to the cross-domain pass data is a preset number. If not, a cross-domain pass is returned. If so, a cross-domain pass is also returned, but a thread lock is set, a new thread is enabled, and cross-domain information is obtained. A timer is used to request the whitelist configuration service to generate whitelist configuration data. The whitelist service is requested via the HTTPS interface according to the whitelist configuration data, and the whitelist information is stored in JSON format. The whitelist information is used to update the initial local cache library to generate a first target local cache library. The first target local cache library and the cross-domain pass data are used to construct first cross-domain playback data corresponding to the video stream request information.

[0146] When the cache is not a whitelist, interception information is set and a cross-domain rejection is returned, that is, cross-domain rejection data is returned. The streaming media gateway + dynamic whitelist adopted by the present invention generates a cross-domain token dedicated to a specific request source, solving the security problem of cross-domain playback of video streaming media. The whitelist service is configured to query cross-domain whitelist information, and the request information is collected and reported to the whitelist service through the gateway, forming a data push-feedback situational awareness closed loop, which can be connected to analysis tools for analyzing the source of information security attacks.

[0147] Furthermore, common solutions to cross-domain issues default to allowing any cross-domain access request. This invention, while ensuring trusted web access, allows for rapid updates to the trust list, rejecting cross-domain requests from untrusted sources. Frequent requests to service interfaces can degrade gateway performance to service performance (about 500 qps). This invention ensures gateway access performance (about 17,000 qps) through the aforementioned optimization solution.

[0148] When playing a video stream on a webpage, the video stream must originate from the same domain as the webpage. However, if cross-domain video streaming is required, the webpage will intercept the playback request. This invention can be used by clients running any browser kernel to access trusted cross-domain live video streaming addresses. This implements a business architecture for webpages with arbitrary domain names to access intranet streaming services. This enhances the security of live streaming from surveillance cameras, preventing malicious cross-domain requests from abusing live video streaming. A blacklist can be configured to detect and intercept malicious request sources, preventing hotlinking.

[0149] See also Figure 10 , Figure 10 This is a structural block diagram of a video stream cross-domain playback system provided in Example 3 of the present invention.

[0150] A video stream cross-domain playback system provided in Example 3 of the present invention includes:

[0151] The cache type determination module 1001 is used to, when receiving video stream request information from a web page, perform cache identification using the video stream request information and the initial local cache library to determine the cache type corresponding to the video stream request information.

[0152] The cross-domain pass data generating module 1002 is configured to obtain the video stream corresponding to the video stream request information and add a cross-domain playback token to the returned message header to generate cross-domain pass data if the cache type is the first cache type.

[0153] The first cross-domain playback data construction module 1003 is configured to update the initial local cache library based on the cross-domain data and construct the first cross-domain playback data corresponding to the video stream request information.

[0154] The cross-domain rejection data generating module 1004 is configured to, if the cache type is the second cache type, use honeypot logic to set interception information and generate cross-domain rejection data.

[0155] The second cross-domain playback data construction module 1005 is configured to update the initial local cache library based on the cross-domain rejection data and construct the second cross-domain playback data corresponding to the video stream request information.

[0156] Optionally, the first cache type includes cache non-existence and whitelist address; the cache type determination module 1001 is specifically configured to:

[0157] Determine whether the request address in the video stream request information does not exist in the local cache library;

[0158] If so, the cache type corresponding to the video stream request information is cache does not exist;

[0159] If not, determine whether the request address is a whitelist address;

[0160] If so, the cache type corresponding to the video stream request information is a whitelist address;

[0161] If not, the cache type corresponding to the video stream request information is the second cache type.

[0162] Optionally, the local cache library includes an online cache pool; the first cross-domain playback data construction module 1003 includes:

[0163] A cross-domain pass data judgment module is used to judge whether the pass address corresponding to the cross-domain pass data exists in the online cache pool;

[0164] The first target local cache library generates a first submodule for, if yes, updating the initial local cache library according to the thread corresponding to the cross-domain data to generate the first target local cache library;

[0165] The first target local cache library generates a second submodule for, if not, using the initial local cache library as the first target local cache library;

[0166] The first cross-domain playback data construction submodule is configured to construct first cross-domain playback data corresponding to the video stream request information using the first target local cache library and the cross-domain pass data.

[0167] Optionally, the first target local cache library generates a first submodule, specifically for:

[0168] Determine whether the line program number corresponding to the cross-domain passing data is a preset sequence number;

[0169] If so, set the thread lock and request the whitelist configuration service through the timer to generate the whitelist configuration data;

[0170] Request the whitelist service through the https interface according to the whitelist configuration data, and obtain the whitelist information saved in JSON format;

[0171] Using the whitelist information to update the initial local cache library to generate a first target local cache library;

[0172] If not, the initial local cache library is used as the first target local cache library.

[0173] Optionally, the second cache type includes non-whitelist addresses and blacklist addresses. The cross-domain rejection data generation module 1004 is specifically configured to:

[0174] If the cache type corresponding to the cross-domain rejection data is a non-whitelist address, the initial local cache library is updated based on the preset cache update logic to obtain a second target local cache library;

[0175] If the domain name corresponding to the cross-domain rejection data does not exist in the second target local cache library, construct cache period data corresponding to the domain name according to the preset period;

[0176] Constructing second cross-domain playback data corresponding to the video stream request information using the cross-domain rejection data, the cache period data, and the second target local cache library;

[0177] If the cache type corresponding to the cross-domain rejection data is a blacklist address, alarm data is generated;

[0178] The initial local cache library is used as the second target local cache library, and combined with the alarm data, the second cross-domain playback data corresponding to the video stream request information is constructed.

[0179] An embodiment of the present invention further provides an electronic device, comprising: a memory and a processor, wherein a computer program is stored in the memory; when the computer program is executed by the processor, the processor executes the video stream cross-domain playback method as described in any of the above embodiments.

[0180] The memory can be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read-Only Memory), an EPROM, a hard disk or a ROM. The memory has a storage space for the program code of any method step for executing the above method. For example, the storage space for the program code can include each program code for realizing the various steps in the above method respectively. These program codes can be read from or written to one or more computer program products. These computer program products include program code carriers such as a hard disk, a compact disc (CD), a memory card or a floppy disk. The program code can be compressed, for example, in an appropriate form. When these codes are run by a computing and processing device, the computing and processing device is caused to execute each step in the video stream cross-domain playback method described above.

[0181] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for cross-domain playback of video streams as described in any of the above embodiments is implemented.

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

[0183] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0184] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0185] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0186] If the integrated unit is implemented in the form of 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 the present invention, 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. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0187] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A method for cross-domain playback of video streams, characterized in that: include: When receiving video stream request information from a web page, performing cache identification using the video stream request information and the initial local cache library to determine the cache type corresponding to the video stream request information; If the cache type is the first cache type, obtaining the video stream corresponding to the video stream request information and adding a cross-domain playback token to the returned message header to generate cross-domain pass data; The initial local cache library is updated based on the cross-domain pass data, and first cross-domain playback data corresponding to the video stream request information is constructed; If the cache type is the second cache type, intercepting information is set using honeypot logic to generate cross-domain rejection data; The initial local cache library is updated based on the cross-domain rejection data, and second cross-domain playback data corresponding to the video stream request information is constructed.

2. The video stream cross-domain playback method according to claim 1, characterized in that: The first cache type includes cache non-existence and whitelist address; and the step of using the video stream request information and the local cache library to perform cache identification and determine the cache type corresponding to the video stream request information includes: Determine whether the request address in the video stream request information does not exist in the local cache library; If so, the cache type corresponding to the video stream request information is that the cache does not exist; If not, determine whether the requested address is a whitelist address; If so, the cache type corresponding to the video stream request information is the whitelist address; If not, the cache type corresponding to the video stream request information is the second cache type.

3. The video stream cross-domain playback method according to claim 1, characterized in that: The local cache library includes an online cache pool; the step of updating the initial local cache library based on the cross-domain data and constructing the first cross-domain playback data corresponding to the video stream request information includes: Determine whether a pass address corresponding to the cross-domain pass data exists in the online cache pool; If yes, then update the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library; If not, using the initial local cache library as the first target local cache library; The first target local cache library and the cross-domain pass data are used to construct first cross-domain playback data corresponding to the video stream request information.

4. The video stream cross-domain playback method according to claim 3, characterized in that: The step of updating the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library includes: Determine whether the line program number corresponding to the cross-domain passing data is a preset sequence number; If so, set the thread lock and request the whitelist configuration service through the timer to generate the whitelist configuration data; Request the whitelist service according to the whitelist configuration data through the https interface to obtain the whitelist information saved in json format; Using the whitelist information to update the initial local cache library to generate a first target local cache library; If not, the initial local cache library is used as the first target local cache library.

5. The video stream cross-domain playback method according to claim 1, characterized in that: The second cache type includes a non-whitelist address and a blacklist address; and updating the initial local cache library based on the cross-domain rejection data to construct the second cross-domain playback data corresponding to the video stream request information includes: If the cache type corresponding to the cross-domain rejection data is a non-whitelist address, updating the initial local cache library based on a preset update cache logic to obtain a second target local cache library; If the domain name corresponding to the cross-domain rejection data does not exist in the second target local cache library, constructing cache period data corresponding to the domain name according to a preset period; Constructing second cross-domain playback data corresponding to the video stream request information by using the cross-domain rejection data, the cache period data, and the second target local cache library; If the cache type corresponding to the cross-domain rejection data is a blacklist address, constructing warning data; The initial local cache library is used as the second target local cache library, and combined with the alarm data, second cross-domain playback data corresponding to the video stream request information is constructed.

6. A video stream cross-domain playback system, characterized in that: include: A cache type determination module is configured to, upon receiving video stream request information from a web page, perform cache identification using the video stream request information and an initial local cache library to determine a cache type corresponding to the video stream request information; A cross-domain pass data generation module is configured to obtain the video stream corresponding to the video stream request information and add a cross-domain playback token to the returned message header to generate cross-domain pass data if the cache type is the first cache type; A first cross-domain playback data construction module is configured to update the initial local cache library based on the cross-domain pass data and construct first cross-domain playback data corresponding to the video stream request information; a cross-domain rejection data generation module, configured to, if the cache type is the second cache type, use honeypot logic to set interception information and generate cross-domain rejection data; The second cross-domain playback data construction module is configured to update the initial local cache library based on the cross-domain rejection data and construct second cross-domain playback data corresponding to the video stream request information.

7. The video stream cross-domain playback system according to claim 6, characterized in that: The first cache type includes cache non-existence and whitelist address; the cache type determination module is specifically configured to: Determine whether the request address in the video stream request information does not exist in the local cache library; If so, the cache type corresponding to the video stream request information is that the cache does not exist; If not, determine whether the requested address is a whitelist address; If so, the cache type corresponding to the video stream request information is the whitelist address; If not, the cache type corresponding to the video stream request information is the second cache type.

8. The video stream cross-domain playback system according to claim 6, characterized in that: The local cache library includes an online cache pool; the first cross-domain playback data construction module includes: A cross-domain passing data judgment module is used to judge whether a passing address corresponding to the cross-domain passing data exists in the online cache pool; The first target local cache library generates a first submodule for, if yes, updating the initial local cache library according to the thread corresponding to the cross-domain data to generate a first target local cache library; The first target local cache library generates a second submodule for, if no, using the initial local cache library as the first target local cache library; The first cross-domain playback data construction submodule is configured to construct first cross-domain playback data corresponding to the video stream request information using the first target local cache library and the cross-domain pass data.

9. An electronic device, characterized in that: It includes a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the video stream cross-domain playback method as described in any one of claims 1 to 5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed, the video stream cross-domain playback method according to any one of claims 1 to 5 is implemented.

Images