Code protection method, apparatus, device, and storage medium

Abstract

The present specification relates to the technical field of front-end engineering, and provides a code protection method, device, equipment and storage medium, the method comprising: locating a JavaScript file according to a static resource attribute of a front-end engineering build product; obtaining corresponding front-end source code from a source code function of the JavaScript file; calling a specified bytecode compiler to compile the front-end source code into binary code; and writing the binary code into a sibling directory of the JavaScript file. The embodiments of the present specification can improve the security of the source code of the front-end engineering JavaScript file.

Description

Code protection methods, apparatus, devices and storage media Technical Field

[0001] This specification relates to the field of front-end engineering technology, and in particular to a code protection method, apparatus, device, and storage medium. Background Technology

[0002] Preventing code leaks is a core interest of technology companies, and it's a crucial task for them. For scenarios where front-end project source code is implemented in JavaScript files, common code protection methods include compressing and obfuscating the JavaScript files to reduce readability; however, this approach still carries a certain risk of code leakage. Therefore, improving the security of front-end project JavaScript source code has become a pressing technical problem to be solved. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to provide a code protection method, apparatus, device, and storage medium to improve the security of the source code of JavaScript files in front-end projects.

[0004] To achieve the above objectives, in one aspect, embodiments of this specification provide a code protection method, including:

[0005] Locate the JavaScript file based on the static resource attributes of the front-end project build artifacts;

[0006] Obtain the corresponding front-end source code from the source code functions of the JavaScript file;

[0007] The specified bytecode compiler is invoked to compile the front-end source code into binary code.

[0008] Write the binary code to the same directory as the JavaScript file.

[0009] In the code protection method of this specification, locating the JavaScript file based on the static resource attributes of the front-end project build artifact includes:

[0010] Iterate through the assets array of the front-end project build artifacts and obtain the filename of each static file in the assets array;

[0011] Identify whether the filename extension of each static file is .js;

[0012] If a static file's filename has the .js extension, then the static file is a JavaScript file.

[0013] In the code protection method of this specification, the step of calling a specified bytecode compiler to compile the front-end source code into binary code includes:

[0014] The bytecode compiler of the Node.js runtime environment is invoked to compile the front-end source code into binary code.

[0015] In the code protection method of this specification embodiment, before calling the specified bytecode compiler to compile the front-end source code into binary code, the method further includes:

[0016] Determine whether the front-end source code is allowed to be dynamically imported;

[0017] When determining whether the front-end source code is allowed to be dynamically imported, the wrapping method of the Node.js runtime environment is called to wrap the front-end source code.

[0018] In the code protection method of this specification embodiment, determining whether the front-end source code is allowed to be dynamically imported includes:

[0019] The front-end source code is determined based on the value of the pre-configured compileAsModule parameter to determine whether it is allowed to be dynamically imported.

[0020] In the code protection method of this specification, writing the binary code to the same directory as the JavaScript file includes:

[0021] The file system module of the Node.js runtime environment is invoked to write the binary code to the same directory as the JavaScript file.

[0022] In the code protection method of this specification embodiment, after writing the binary code to the same directory as the JavaScript file, it further includes:

[0023] Determine whether the deletion of the JavaScript file is permitted;

[0024] Delete the JavaScript file when deletion of the JavaScript file is permitted.

[0025] In the code protection method of this specification embodiment, the step of determining whether to allow the deletion of the JavaScript file includes:

[0026] The decision on whether to allow the deletion of the JavaScript file is based on the pre-configured keepSourceCode parameter value.

[0027] In the code protection method of this specification embodiment, deleting the JavaScript file includes:

[0028] The JavaScript file was deleted using the rimraf command of the package manager.

[0029] In the code protection method of this specification embodiment, the front-end engineering build product is pre-built using a build tool.

[0030] In the code protection method of this specification embodiment, the build tool includes the Webpack module.

[0031] On the other hand, embodiments of this specification also provide a code protection device, including:

[0032] The location module is used to locate JavaScript files based on the static resource attributes of the front-end project build artifacts;

[0033] The acquisition module is used to obtain the corresponding front-end source code from the source code functions of the JavaScript file;

[0034] The module is invoked to call a specified bytecode compiler to compile the front-end source code into binary code.

[0035] The write module is used to write the binary code to the same directory as the JavaScript file.

[0036] On the other hand, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the computer program, when run by the processor, executes instructions for the above-described method.

[0037] On the other hand, embodiments of this specification also provide a computer storage medium storing a computer program thereon, which, when run by the processor of a computer device, executes instructions for the above-described method.

[0038] On the other hand, embodiments of this specification also provide a computer program product, which includes a computer program that, when run by the processor of a computer device, executes instructions for the above-described method.

[0039] As can be seen from the technical solutions provided in the embodiments of this specification above, the embodiments of this specification can compile all JavaScript files output in the front-end project into binary code and write it to the same directory as the corresponding JavaScript files. Since the binary code is completely unreadable, while still being executable, and cannot be restored (or decompiled) into JavaScript code, the risk of leakage of the source code corresponding to the JavaScript files output in the front-end project is reduced, thereby improving the security of the source code corresponding to the JavaScript files output in the front-end project. Attached Figure Description

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

[0041] Figure 1 illustrates the relationship between the front-end development environment and the code protection device in some embodiments of this specification;

[0042] Figure 2 shows a flowchart of code protection methods in some embodiments of this specification;

[0043] Figure 3 shows a flowchart of code protection methods in some other embodiments of this specification;

[0044] Figure 4 shows a flowchart of code protection methods in some other embodiments of this specification;

[0045] Figure 5 shows a structural block diagram of the code protection device in some embodiments of this specification;

[0046] Figure 6 shows a structural block diagram of the code protection device in some other embodiments of this specification;

[0047] Figure 7 shows a structural block diagram of the code protection device in some other embodiments of this specification;

[0048] Figure 8 shows a structural block diagram of a computer device in some embodiments of this specification.

[0049] [Explanation of Labels in the Attached Image]

[0050] 10. JavaScript runtime environment;

[0051] 20. Code protection device;

[0052] 51. Positioning module;

[0053] 52. Acquisition Module;

[0054] 53. Call the module;

[0055] 54. Write module;

[0056] 55. File control module;

[0057] 56. Introduce a control module;

[0058] 802. Computer equipment;

[0059] 804, Processor;

[0060] 806. Memory;

[0061] 808. Drive mechanism;

[0062] 810. Input / output interfaces;

[0063] 812. Input devices;

[0064] 814. Output devices;

[0065] 816. Presentation equipment;

[0066] 818. Graphical User Interface;

[0067] 820. Network interface;

[0068] 822. Communication link;

[0069] 824. Communication bus. Detailed Implementation

[0070] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0071] Website or system code is divided into front-end source code and back-end source code. Front-end source code is mainly responsible for page display and interactive operations; back-end code mainly implements the website or system's functions, such as adding, deleting, modifying, and querying data. This specification's embodiments primarily concern the protection of JavaScript files within the front-end code project (i.e., the front-end project).

[0072] To achieve relative security for JavaScript files output from front-end projects, traditional code protection typically involves obfuscating and / or compressing these files to reduce readability. However, this approach still carries a certain risk of code leakage. For example, on the homepage of website xxxx (https: / / www.xxxx.com / ), right-clicking on the page and selecting "Inspect" or pressing F12 to open the developer tools will display all static resources of the page in the source code tab. These resources include images (various JPG, PNG, etc.), CSS style files, JavaScript interaction files, HTML page content files, font files, etc. If the JavaScript is displayed on a single line, it indicates that the page's code has been compressed and obfuscated. However, tools like Beautifier can beautify the compressed and obfuscated code back into more readable code, leaving even the compressed and obfuscated code still at significant risk of leakage.

[0073] In view of this, the embodiments in this specification provide a new protection technology for JavaScript files output by front-end projects, which can be applied to JavaScript runtime environments. Since JavaScript is a scripting language, JavaScript files require a parser to run, and different parser implementations can be used in different scenarios; for example, for JavaScript files written to HTML, a browser can act as the parser. For JavaScript files that need to run independently, Node.js can act as the parser (Node.js is a JavaScript runtime environment based on the Chrome V8 engine). The JavaScript runtime environment not only allows JavaScript files to define various data structures and perform various calculations, but also allows JavaScript files to use built-in objects and methods provided within the JavaScript runtime environment. For example, if a JavaScript file running in a browser is used to manipulate the Document Object Model (DOM), the browser provides built-in objects such as `document`. If a JavaScript file running in Node.js is used to manipulate disk files or build an HTTP server, Node.js provides built-in objects such as `fs` and `http` accordingly.

[0074] Front-end projects can be built using appropriate build tools (such as Webpack, Rollup, Vite, etc.), which can be used to package and compile the project code. Build tools can compress or merge image resource files (such as png, jpg, svg, etc.) in the front-end project code; compile and compress style files (such as less, scss, css, etc.); and perform JavaScript code conversion operations (ES6 to ES5). After compilation and conversion, the build tool outputs code that can be run directly in a browser or Node.js.

[0075] As shown in Figure 1, in some embodiments of this specification, a code protection device 20 can be developed for use in the JavaScript runtime environment 10. This code protection device 20 can be executed at an appropriate time during the process of building a website or system based on a build tool, to compile all JavaScript files output in the front-end project into binary code and write it to the same directory as the corresponding JavaScript file. Since the binary code is completely unreadable, it remains executable, and it cannot be decompiled into JavaScript code, thus protecting the content of the JavaScript files (i.e., the source code corresponding to the JavaScript files) from being leaked. The code protection device 20 can be a plugin, pre-installed in the JavaScript runtime environment 10 for easy expansion and maintenance. For example, in a Node.js runtime environment, the code protection device can be installed as a plugin for a JS package management tool (such as npm or yarn).

[0076] For example, in some embodiments, given that Webpack is currently the most widely used tool for bundling and compiling front-end projects, in scenarios where Webpack is used to build websites or systems, the aforementioned code protection mechanism can be executed during the emit phase of the build process. The emit phase refers to the intermediate stage between the generation of the build assets and the output directory.

[0077] This specification provides a code protection method that can be applied to the code protection device described above. Referring to FIG2, in some embodiments, the code protection method may include the following steps:

[0078] Step 201: Locate the JavaScript file based on the static resource attributes of the front-end project build artifacts.

[0079] Front-end project build artifacts can be websites or systems, and the static resources of these artifacts are called static resource files. Static resource files can include HTML files (files that browsers can open), CSS style files (styles for website pages), JavaScript files (files responsible for website interactions), image resources, font resources, and other files.

[0080] In some embodiments, locating the JavaScript file based on the static resource attributes of the front-end project build artifact may include:

[0081] (1) Traverse the assets array of the front-end project build artifacts and obtain the file name of each static file in the assets array.

[0082] For example, taking the Webpack emit phase as an example, the callback function of the emit lifecycle function is the compilation function, which contains the property information of this build artifact. The assets array of the compilation function (each element of the array is a built static file) contains all the static resources of this build artifact. Therefore, it is necessary to iterate through the assets array to obtain the filename of each static file in the assets array.

[0083] (2) Identify whether the file name extension of each static file is .js.

[0084] Since each static file in the assets array has a filename extension, different filename extensions can represent different file types; for example, JavaScript files have the extension .js, and image resource files have the extensions .png, .jpg, or .svg. Therefore, by identifying the filename extension of each static file, it is possible to determine whether the corresponding static file is a JavaScript file.

[0085] (3) If the filename of a static file has the .js extension, then the static file is determined to be a JavaScript file; otherwise, the static file is determined to be a non-JavaScript file (non-JavaScript files do not need to be converted to binary code). In this way, all JavaScript files output by the entire front-end project can be automatically located without manual processing.

[0086] Step 202: Obtain the corresponding front-end source code from the source code functions of the JavaScript file.

[0087] For each JavaScript file in the identified front-end project build artifacts, its source function is the `source` function. The `source` function contains the source code of the JavaScript file; that is, the corresponding front-end source code can be obtained from the `source` function of the JavaScript file. In this way, the front-end source code of each JavaScript file in the front-end project build artifacts can be obtained.

[0088] Step 203: Call the specified bytecode compiler to compile the front-end source code into binary code.

[0089] For example, in some embodiments, the bytecode compiler of the Node.js runtime environment (i.e., the `compileCode` method of the bytenode library in Node.js) can be invoked to compile the front-end source code into binary code. Of course, in other embodiments, any other bytecode compiler that can automatically compile the source code of a JavaScript file into binary code can also be used.

[0090] Step 204: Write the binary code into the same directory as the JavaScript file.

[0091] For example, in some embodiments, the file system module (fs module) of the Node.js runtime environment can be invoked to write the binary code to the same directory as the JavaScript file. The file extension for the binary code can be .jsc. Writing the binary code to the same directory as the corresponding JavaScript file helps ensure the code runs correctly.

[0092] The code protection method based on the embodiments of this specification can compile all JavaScript files output from the front-end project into binary code (i.e., binary files) and write them to the same directory as the corresponding JavaScript files. Since the binary code is completely unreadable while still being executable, and it cannot be decompiled (or restored) into JavaScript code, the risk of leakage of the source code corresponding to the JavaScript files output from the front-end project is reduced, thereby improving the security of the source code corresponding to the JavaScript files output from the front-end project.

[0093] This specification provides another code protection method, which can be applied to the code protection device described above. Referring to FIG3, in some other embodiments, the code protection method may include the following steps:

[0094] Step 301: Locate the JavaScript file based on the static resource attributes of the front-end project build artifacts.

[0095] Step 302: Obtain the corresponding front-end source code from the source code functions of the JavaScript file.

[0096] Step 303: Call the specified bytecode compiler to compile the front-end source code into binary code.

[0097] Step 304: Write the binary code into the same directory as the JavaScript file.

[0098] Step 305: Determine whether the deletion of the JavaScript file is allowed; if the deletion of the JavaScript file is allowed, proceed to step 306; otherwise, end (i.e., end the processing of this JavaScript file).

[0099] For example, in some embodiments, the decision to allow the deletion of the JavaScript file can be determined based on the pre-configured value of the keepSourceCode parameter. The keepSourceCode parameter is of boolean type, meaning its value can be either true or false; the specific value can be configured as needed.

[0100] When the `keepSourceCode` parameter is set to `true`, the JavaScript file is preserved. Preserving the JavaScript file can be understood as being in development mode. Binary files (i.e., the binary file corresponding to the compiled source code of the JavaScript file) cannot pinpoint the line and column number where the error occurs, making error location difficult. If the file containing the binary code has an error (i.e., the front-end project has a bug), because the JavaScript file is preserved, front-end project developers can easily and quickly locate the error from the preserved JavaScript file. Therefore, it is suitable for the development and testing phases of front-end projects.

[0101] When the `keepSourceCode` parameter is set to `false`, it means that JavaScript files can be deleted. Deleting JavaScript files can be understood as production mode. Since program bugs have been mostly fixed in the development stage, there is no need to retain JavaScript files for program testing or debugging in the production stage; that is, in the final files deployed to the server, JavaScript files need to be deleted to prevent them from being accessed in the production environment, thereby further reducing the risk of source code leakage.

[0102] Step 306: Delete the JavaScript file.

[0103] For example, in some embodiments, when the deletion of the JavaScript file is permitted, the rimraf command of a package management tool (such as npm or yarn) can be invoked to delete the JavaScript file, thereby reducing the risk of source code leakage of the JavaScript file.

[0104] Therefore, based on the code protection method embodiment shown in Figure 3, not only is the risk of leakage of the source code corresponding to the JavaScript file output in the front-end project reduced, but the configurability and flexibility of the front-end project are also improved.

[0105] This specification provides another code protection method, which can be applied to the code protection device described above. Referring to FIG4, in some other embodiments, the code protection method may include the following steps:

[0106] Step 401: Locate the JavaScript file based on the static resource attributes of the front-end project build artifacts.

[0107] Step 402: Obtain the corresponding front-end source code from the source code functions of the JavaScript file.

[0108] Step 403: Determine whether the front-end source code is allowed to be dynamically imported; if the front-end source code is allowed to be dynamically imported, proceed to step 404; otherwise, proceed to step 405.

[0109] For example, in some embodiments, the front-end source code can be dynamically imported based on a pre-configured `compileAsModule` parameter. Determining whether the front-end source code can be dynamically imported means determining whether the corresponding binary file supports being dynamically imported by other projects or files, thus serving as a module or part of those projects or files. The `compileAsModule` parameter is a boolean value, meaning its value can be either true or false; it can be configured as needed. When the `compileAsModule` parameter is true, it indicates that the corresponding binary file supports being dynamically imported by other projects or files; when the `compileAsModule` parameter is false, it indicates that the corresponding binary file does not support being dynamically imported by other projects or files.

[0110] Step 404: Call the wrapping method of the Node.js runtime environment to wrap the front-end source code.

[0111] For example, in some embodiments, when the front-end source code is allowed to be dynamically imported, the `wrap` method of the node module in the Node.js runtime environment can be called to wrap the front-end source code. When the front-end source code is allowed to be dynamically imported, before calling the specified bytecode compiler to compile the front-end source code into binary code, the `wrap` method of the Node.js runtime environment needs to be called to wrap the front-end source code; otherwise, the subsequently compiled binary code will not be able to be dynamically imported. Thus, by adding steps 403 and 404, the scalability and applicability of the front-end project can be improved.

[0112] Step 405: Call the specified bytecode compiler to compile the front-end source code into binary code.

[0113] Step 406: Write the binary code into the same directory as the JavaScript file.

[0114] Step 407: Determine whether the deletion of the JavaScript file is allowed; if the deletion of the JavaScript file is allowed, proceed to step 408; otherwise, end (i.e., end the processing of this JavaScript file).

[0115] Step 408: Delete the JavaScript file.

[0116] Therefore, based on the code protection method embodiment shown in Figure 4, not only is the risk of leakage of the source code corresponding to the JavaScript file output in the front-end project reduced, and the configurability and flexibility of the front-end project improved, but the scalability and applicability of the front-end project are also improved.

[0117] Although the process described above includes multiple operations that occur in a specific order, it should be clearly understood that these processes may include more or fewer operations, which may be executed sequentially or in parallel (e.g., using parallel processors or a multithreaded environment).

[0118] Corresponding to the code protection method shown in Figure 2 above, this specification also provides a code protection device. Referring to Figure 5, the code protection device may include:

[0119] The positioning module 51 can be used to locate JavaScript files based on the static resource attributes of the front-end project build artifacts;

[0120] The acquisition module 52 can be used to obtain the corresponding front-end source code from the source code functions of the JavaScript file;

[0121] Module 53 can be used to invoke a specified bytecode compiler to compile the front-end source code into binary code;

[0122] The writing module 54 can be used to write the binary code to the same directory as the JavaScript file.

[0123] The code protection device shown in Figure 5 can be executed at an appropriate time during the build process of a website or system built using a build tool. It compiles the JavaScript files of the front-end project into binary code and writes it to the same directory as the corresponding JavaScript file. Since the binary code is completely unreadable while remaining executable, and it cannot be decompiled (or restored) into JavaScript code, the content of the JavaScript file is protected from leakage, thus reducing the risk of source code leakage for the JavaScript files output from the front-end project.

[0124] Corresponding to the code protection method shown in Figure 3 above, this specification also provides another code protection device. Referring to Figure 6, the code protection device may include:

[0125] The positioning module 51 can be used to locate JavaScript files based on the static resource attributes of the front-end project build artifacts;

[0126] The acquisition module 52 can be used to obtain the corresponding front-end source code from the source code functions of the JavaScript file;

[0127] Module 53 can be used to invoke a specified bytecode compiler to compile the front-end source code into binary code;

[0128] The writing module 54 can be used to write the binary code to the same directory as the JavaScript file.

[0129] The file control module 55 can be used to determine whether the deletion of the JavaScript file is allowed; when the deletion of the JavaScript file is allowed, the JavaScript file is deleted.

[0130] In the code protection device embodiment shown in Figure 6, determining whether to allow the deletion of the JavaScript file may include:

[0131] The decision on whether to allow the deletion of the JavaScript file is based on the pre-configured keepSourceCode parameter value.

[0132] In the code protection device embodiment shown in Figure 6, deleting the JavaScript file may include:

[0133] The JavaScript file was deleted using the rimraf command of the package manager.

[0134] Therefore, based on the code protection device embodiment shown in Figure 6, not only is the risk of leakage of the source code corresponding to the JavaScript file output in the front-end project reduced, but the configurability and flexibility of the front-end project are also improved.

[0135] Corresponding to the code protection method shown in Figure 4 above, this specification also provides another code protection device. Referring to Figure 7, the code protection device may include:

[0136] The positioning module 51 can be used to locate JavaScript files based on the static resource attributes of the front-end project build artifacts;

[0137] The acquisition module 52 can be used to obtain the corresponding front-end source code from the source code functions of the JavaScript file;

[0138] Module 53 can be used to invoke a specified bytecode compiler to compile the front-end source code into binary code;

[0139] The writing module 54 can be used to write the binary code to the same directory as the JavaScript file.

[0140] The file control module 55 can be used to determine whether the deletion of the JavaScript file is allowed; when the deletion of the JavaScript file is allowed, the JavaScript file is deleted.

[0141] The control module 56 is introduced to determine whether the front-end source code is allowed to be dynamically imported before the calling module 53 calls the specified bytecode compiler to compile the front-end source code into binary code; when the front-end source code is allowed to be dynamically imported, the wrapping method of the Node.js runtime environment is called to wrap the front-end source code.

[0142] In the code protection device embodiment shown in Figure 7, determining whether the front-end source code is allowed to be dynamically imported may include:

[0143] The front-end source code is determined based on the value of the pre-configured compileAsModule parameter to determine whether it is allowed to be dynamically imported.

[0144] Based on the code protection device embodiment shown in Figure 7, not only is the risk of leakage of the source code corresponding to the JavaScript file output in the front-end project reduced, and the configurability and flexibility of the front-end project improved, but the scalability and applicability of the front-end project are also improved.

[0145] In the code protection device embodiments shown in Figures 5 to 7 above, locating the JavaScript file based on the static resource attributes of the front-end project build artifact may include:

[0146] Iterate through the assets array of the front-end project build artifacts and obtain the filename of each static file in the assets array;

[0147] Identify whether the filename extension of each static file is .js;

[0148] If a static file's filename has the .js extension, then the static file is a JavaScript file.

[0149] In the code protection device embodiments shown in Figures 5 to 7 above, the step of calling a designated bytecode compiler to compile the front-end source code into binary code includes:

[0150] The bytecode compiler of the Node.js runtime environment is invoked to compile the front-end source code into binary code.

[0151] In the code protection device embodiments shown in Figures 5 to 7 above, writing the binary code to the same directory as the JavaScript file includes:

[0152] The file system module of the Node.js runtime environment is invoked to write the binary code to the same directory as the JavaScript file.

[0153] In the code protection device embodiments shown in Figures 5 to 7 above, the front-end engineering build product is pre-built using a build tool.

[0154] In the code protection device embodiments shown in Figures 5 to 7 above, the build tool includes the Webpack module.

[0155] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0156] Embodiments of this specification also provide a computer device. As shown in FIG8, in some embodiments of this specification, the computer device 802 may include one or more processors 804, such as one or more central processing units (CPUs) or graphics processing units (GPUs), each processing unit implementing one or more hardware threads. The computer device 802 may also include any memory 806 for storing information of any kind, such as code, settings, data, etc. In one specific embodiment, a computer program is stored on the memory 806 and can run on the processor 804. When the computer program is run by the processor 804, it can execute instructions of the code protection method described in any of the above embodiments. Without limitation, for example, the memory 806 may include any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory can represent a fixed or removable component of the computer device 802. In one scenario, when processor 804 executes associated instructions stored in any memory or combination of memories, computer device 802 can perform any operation of the associated instructions. Computer device 802 also includes one or more drive mechanisms 808 for interacting with any memory, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.

[0157] Computer device 802 may also include an input / output interface 810 (I / O) for receiving various inputs (via input device 812) and providing various outputs (via output device 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface 818 (GUI). In other embodiments, the input / output interface 810 (I / O), input device 812, and output device 814 may be omitted, and the device may function solely as a computer device within a network. Computer device 802 may also include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.

[0158] Communication link 822 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0159] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), computer-readable storage media, and computer program products according to some embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processor to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processor, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0160] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processor to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0161] These computer program instructions may also be loaded onto a computer or other programmable data processor to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable device, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0162] In a typical configuration, a computer device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0163] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0164] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by computer equipment. As defined in this specification, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0165] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0166] The embodiments described in this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processors connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0167] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0168] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0169] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0170] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A code protection method, characterized in that, The process involves using a front-end project build tool plugin and executing it during the emit phase of the front-end project build process. This includes: locating JavaScript files based on the static resource attributes of the front-end project build artifacts during the emit phase; specifically, iterating through the assets attribute array of the front-end project build artifacts to obtain the filename of each static file in the assets attribute array; identifying whether the filename extension of each static file is .js; if the filename extension of a static file is .js, then determining that the static file is a JavaScript file; the emit phase refers to the intermediate stage between generating the build artifacts and before the output directory; obtaining the corresponding front-end source code from the source code functions of the JavaScript file; and determining the appropriate front-end source code based on the pre-configured compileAsModule parameter. The process involves several steps: First, determining whether the front-end source code is allowed to be dynamically imported. If so, the process calls the wrapping method of the Node.js runtime environment to wrap the front-end source code. Second, calling the bytecode compiler of the Node.js runtime environment to compile the processed front-end source code into binary code. Third, calling the file system module of the Node.js runtime environment to write the binary code to the same directory as the JavaScript file, generating a binary code file. Fourth, determining whether the deletion of the original JavaScript file is allowed based on the pre-configured keepSourceCode parameter. If deletion is not allowed, the JavaScript file is deleted. The generated binary code file can be directly loaded and executed by a browser or the Node.js runtime environment.

2. The code protection method as described in claim 1, characterized in that, Deleting the JavaScript file includes: calling the rimraf command of a package management tool to delete the JavaScript file.

3. The code protection method as described in claim 1, characterized in that, The front-end engineering build products are pre-built using the build tools.

4. The code protection method as described in claim 3, characterized in that, The build tools include the Webpack module.

5. A code protection device, applied to a front-end engineering build tool plugin, and executed during the emit phase of the front-end engineering build process, characterized in that, include: The locating module is used during the emit phase to locate JavaScript files based on the static resource attributes of the front-end project build artifacts. Specifically, this includes: traversing the assets attribute array of the front-end project build artifacts and obtaining the filename of each static file in the assets attribute array; identifying whether the filename extension of each static file is .js; if the filename extension of a static file is .js, then the static file is determined to be a JavaScript file. The emit phase refers to the intermediate stage between generating the build artifacts and the output directory. The obtaining module is used to obtain the corresponding front-end source code from the source code functions of the JavaScript file. The calling module is used to determine whether the front-end source code is allowed to be dynamically accessed based on the pre-configured compileAsModule parameter. The process involves several steps: First, when the front-end source code is allowed to be dynamically imported, the `wrap` method of the Node.js runtime environment is called to wrap the front-end source code. Then, the bytecode compiler of the Node.js runtime environment is called to compile the processed front-end source code into binary code. Next, a `write` module is used to call the file system module of the Node.js runtime environment to write the binary code to the same directory as the JavaScript file, generating a binary code file. Finally, a file control module is used to determine whether the deletion of the original JavaScript file is allowed based on the pre-configured `keepSourceCode` parameter. If retention is not allowed, the JavaScript file is deleted. The generated binary code file can be directly loaded and executed by a browser or the Node.js runtime environment.

6. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the computer program is run by the processor, it executes the instructions of the method according to any one of claims 1-4.

7. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor of the computer device, it executes the instructions of the method according to any one of claims 1-4.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, performs instructions according to any one of claims 1-4.

Images