Method and equipment for preventing user from override access to menu and applied to SSM architecture, and medium
Through full path interception, whitelisting, permission preloading and session-level caching mechanisms, the problem of users accessing menus above the level in the SSM architecture is solved, and the system efficiency and security are improved.
Patent Information
- Application Number
- CN202510603442.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-12
- Publication Date
- 2025-08-15
AI Technical Summary
The problems of users accessing menus at higher levels in existing SSM architectures include high costs of relying on security frameworks, incomplete permission verification, performance bottlenecks caused by frequent database queries, and dynamic permission update lag.
The full path interception and whitelisting mechanism are adopted, combined with permission preloading and session-level cache, and all request paths are intercepted through the custom filter GrantFilter, and the whitelist path is defined. The permission data is loaded at one time when the user logs in and caches it to the session, achieving double-layer verification to prevent over-level access.
Effectively prevent users from bypassing permission control through URLs, reduce the overhead of non-sensitive path verification, dynamic permission updates do not require restarting the system, and improve system response speed and security.
Smart Images
Figure CN120498745A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of Java enterprise-level application development, and in particular to a method, device and medium applied to an SSM architecture to prevent users from accessing menus beyond their level. Background Art
[0002] The existing SSM framework's permission management solutions mainly include the following two categories:
[0003] ① Security framework-based permission control: Such as Spring Security or Shiro, which restricts interface access rights through annotations or configuration files, but requires the introduction of complex security framework dependencies and has high configuration costs.
[0004] ② Path interception and database matching: The request path is intercepted by a global interceptor, and the relationship between user roles and menu permissions is verified by database query. However, the existing solution has the following shortcomings: the permission verification logic does not cover static resource paths (such as / static), which poses a risk of bypassing permission control by directly entering the URL; permission data is not dynamically cached in the session, and each request requires repeated database query, affecting system performance.
[0005] In summary, the existing SSM architecture rights management technology has the following pain points:
[0006] ① The high cost of relying on security frameworks: Existing technologies generally rely on security frameworks such as Spring Security or Shiro, which require the introduction of additional dependencies and the writing of complex configurations, creating a development burden for small and medium-sized systems.
[0007] ② Risk of incomplete permission verification coverage: Traditional interceptor solutions do not cover static resource paths (such as / static and / web), allowing users to bypass menu permission control by directly entering the URL.
[0008] ③Performance bottleneck of frequent database queries: The existing solution requires querying the database for verification permissions for each request, resulting in system response delays in high-concurrency scenarios.
[0009] ④ Lag in dynamic permission updates: After a user role is changed, the system needs to be restarted or the configuration needs to be reloaded, and the permission control policy cannot be implemented in real time.
[0010] Therefore, how to avoid users from accessing menus across levels using the SMM architecture and improve menu access efficiency is a technical problem that needs to be solved urgently. Summary of the Invention
[0011] The technical task of the present invention is to provide a method, device and medium for preventing users from accessing menus across levels in an SSM architecture, so as to solve the problem of how to prevent users from accessing menus across levels in an SMM architecture and improve the efficiency of menu access.
[0012] The technical task of the present invention is achieved in the following manner: a method for preventing users from accessing menus beyond their level in an SSM architecture. The method adopts a full-path interception and whitelist mechanism as well as a dynamic permission loading and caching mechanism to prevent users from accessing menus beyond their level; the details are as follows:
[0013] Full path interception: Configure the custom filter GrantFilter in web.xml, through <url-pattern> / *< / url-pattern> Cover all request paths, eliminating the risk of directly accessing high-authority menus through URLs;
[0014] Define a whitelist: Define a whitelist path. The filter will first check whether the request path is in the whitelist. If so, it will be released directly, reducing the verification overhead of non-sensitive paths.
[0015] Permission preloading: When a user logs in, the permission data associated with the corresponding user is loaded from the database at one time. The permission data associated with the corresponding user includes menusAll and menus. Among them, menusAll represents the set of all menu paths accessible to the current role (including public interfaces); menus represents the menu permission list actually owned by the current role.
[0016] Session-level cache: caches menuAll and menu data in the user session to avoid repeated database queries for each request, thus improving system response speed;
[0017] The filter implements dynamic permission matching through double-layer verification.
[0018] Preferably, the request path includes static resources and dynamic interfaces;
[0019] The whitelist path is / static or / login.
[0020] As a preferred option, the filter implements dynamic permission matching through double-layer verification as follows:
[0021] First level validation: The filter extracts the request path and checks whether it belongs to the menuAll list:
[0022] If it does not belong to the menusAll list, it is considered a public path and is directly released;
[0023] If it is a permission-sensitive path, it will enter the second level of verification;
[0024] Second level validation: Compare the request path with the menu list:
[0025] If the user does not have access rights, the system will be forced to jump to the login page or error page, and an unauthorized access log will be generated.
[0026] Preferably, the permission data in this method adopts lazy loading mode, specifically: when the user logs in, it is loaded from the database and cached in the session, and after the role is changed, the user logs in again to refresh the cache to ensure that the permission change takes effect in real time.
[0027] Preferably, the method also adopts a fault-tolerant mechanism, specifically: recording an error log when the filter captures an exception to avoid system crashes; and generating an audit log for malicious unauthorized behavior to facilitate tracing; wherein, the error log includes database connection failures and cache invalidations.
[0028] More optimally, the full-path interception and whitelist mechanism is as follows:
[0029] Define a filter: define the filter grantFilter and specify the filter implementation class com.inspur.utils.GrantFilter class, which is used to implement the javax.servlet.Filter interface;
[0030] Map a filter to a specific URL pattern: Specify the filter name to map <filter-name>And with <filter>The name of the tag is consistent with that in the filter and specifies the URL pattern that the filter intercepts.
[0031] A system for preventing a user from accessing a menu beyond the specified level in an SSM architecture, the system comprising:
[0032] Full path interception module, used to configure custom filter GrantFilter in web.xml, through <url-pattern> / *< / url-pattern> Cover all request paths, eliminating the risk of directly accessing high-authority menus through URLs;
[0033] The whitelist definition module is used to define whitelist paths. The filter first verifies whether the request path is in the whitelist. If so, it is directly released, reducing the verification overhead of non-sensitive paths.
[0034] The permission preloading module is used to load the permission data associated with the corresponding user from the database at one time when the user logs in. The permission data associated with the corresponding user includes menusAll and menus. Among them, menusAll represents the set of all menu paths accessible to the current role (including public interfaces); menus represents the menu permission list actually owned by the current role.
[0035] The session-level cache module is used to cache menuAll and menu data in the user session to avoid repeated database queries for each request and improve system response speed;
[0036] Double-layer verification module, used for double-layer verification to achieve dynamic permission matching.
[0037] As a preferred embodiment, the working process of the double-layer verification module is as follows:
[0038] First level validation: The filter extracts the request path and checks whether it belongs to the menuAll list:
[0039] If it does not belong to the menusAll list, it is considered a public path and is directly released;
[0040] If it is a permission-sensitive path, it will enter the second level of verification;
[0041] Second level validation: Compare the request path with the menu list:
[0042] If the user does not have access rights, the system will be forced to jump to the login page or error page, and an unauthorized access log will be generated.
[0043] An electronic device comprising: a memory and at least one processor;
[0044] Wherein, the memory stores a computer program;
[0045] The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the above-mentioned method for preventing users from skipping levels to access menus in the SSM architecture.
[0046] A computer-readable storage medium stores a computer program, which can be executed by a processor to implement the above-mentioned method for preventing users from accessing menus across levels in an SSM architecture.
[0047] The method, device, and medium of the present invention for preventing users from skipping levels to access menus in an SSM architecture have the following advantages:
[0048] (1) The present invention adopts a full-path interception and whitelist mechanism as well as a dynamic permission loading and caching mechanism, which perfectly solves the problem of users accessing menus beyond their level and greatly improves the efficiency of handling such problems;
[0049] (2) Full coverage interception: The present invention uses / * path interception to effectively prevent users from bypassing permission control by directly entering URLs;
[0050] (3) Dynamic permission update: The permission data of the present invention is cached in the session. When the background role is changed, it only needs to be re-logged in for it to take effect, without the need to query the database in real time;
[0051] (IV) Performance Optimization: The whitelist mechanism of the present invention reduces the verification overhead of non-sensitive paths, and the dual-level verification reduces the probability of false interception;
[0052] (V) The present invention implements a method of dynamic permission verification by using a custom interceptor to prevent low-privilege users from accessing high-privilege menus. BRIEF DESCRIPTION OF THE DRAWINGS
[0053] The present invention will be further described below with reference to the accompanying drawings.
[0054] Attachment Figure 1 The present invention is a flowchart of a method for preventing users from accessing menus beyond their own level in an SSM architecture. DETAILED DESCRIPTION
[0055] The method, device and medium for preventing users from skipping levels to access menus in an SSM architecture according to the present invention are described in detail below with reference to the accompanying drawings and specific embodiments.
[0056] Example 1:
[0057] As attached Figure 1 As shown, this embodiment provides a method for preventing users from accessing menus across levels in an SSM architecture. The method adopts a full-path interception and whitelist mechanism as well as a dynamic permission loading and caching mechanism to prevent users from accessing menus across levels. The details are as follows:
[0058] S1. Full path interception: Configure the custom filter GrantFilter in web.xml, through <url-pattern> / *< / url-pattern> Covers all request paths, eliminating the risk of directly accessing high-authority menus through URLs; request paths include static resources and dynamic interfaces;
[0059] S2. Define a whitelist: Define a whitelist path. The filter will first check whether the request path is in the whitelist. If so, it will be directly released, reducing the verification overhead of non-sensitive paths. The whitelist path uses / static or / login.
[0060] S3. Permission preloading: When a user logs in, the permission data associated with the corresponding user is loaded from the database at one time. The permission data associated with the corresponding user includes menusAll and menus. Among them, menusAll represents the set of all menu paths accessible to the current role (including public interfaces); menus represents the menu permission list actually owned by the current role.
[0061] S4, Session-level cache: caches menuAll and menu data in the user session to avoid repeated database queries for each request, improving system response speed;
[0062] S5. The filter implements dynamic permission matching through double-layer verification; the details are as follows:
[0063] First level validation: The filter extracts the request path and checks whether it belongs to the menuAll list:
[0064] If it does not belong to the menusAll list, it is considered a public path and is directly released;
[0065] If it is a permission-sensitive path, it will enter the second level of verification;
[0066] Second level validation: Compare the request path with the menu list:
[0067] If the user does not have access rights, the system will be forced to jump to the login page or error page, and an unauthorized access log will be generated.
[0068] The permission data in this embodiment adopts lazy loading mode, specifically: when the user logs in, it is loaded from the database and cached in the session. After the role is changed, the user logs in again to refresh the cache to ensure that the permission change takes effect in real time.
[0069] This embodiment also adopts a fault-tolerant mechanism, specifically: recording an error log when the filter captures an exception to avoid system crashes; and generating an audit log for malicious unauthorized behavior to facilitate tracing; among which, the error log includes database connection failures and cache invalidations.
[0070] The key codes are as follows:
[0071] publis void doEiltex(...){.
[0072] / / The whitelist path is directly released.
[0073] (inContainuRl
[0074] (reg" / static, / main, / login, / web, / ss")){ifchain,doFilter(request,response)}else{
[0075] / / Session verification and permission dynamic matching
[0076] if (user!= null) {
[0077] ISONArray arrayAll = user.get("menusAll"); / / All permission paths.ISONArray array = user.get("menus"); if (path is in gkyAll) {
[0078] / / Current role permission path
[0079] if (path is in array) release: else redirect:
[0080] }else{
[0081] Release; / / Non-authority sensitive path
[0082] }
[0083] }.
[0084] The full-path interception and whitelist mechanism in this embodiment is specifically as follows:
[0085] Define a filter: define the filter grantFilter and specify the filter implementation class com.inspur.utils.GrantFilter class, which is used to implement the javax.servlet.Filter interface;
[0086] Map a filter to a specific URL pattern: Specify the filter name to map <filter-name>And with <filter>The name of the tag is consistent with that in the filter and specifies the URL pattern that the filter intercepts.
[0087] The key codes are as follows:
[0088] <filter>
[0089] <filter-name> grantEiltex< / filter-name> .
[0090] <filter-class>com,inspur utils,GrantFilter < / filter-class〉
[0091] <filter mapping>
[0092] <filter-name> grantFilter< / filter-name> <url-pattern> / *< / url pattern> ..
[0093] Example 2:
[0094] This embodiment provides a system for preventing users from skipping levels to access menus in an SSM architecture. The system includes:
[0095] Full path interception module, used to configure custom filter GrantFilter in web.xml, through <url-pattern> / *< / url-pattern> Cover all request paths, eliminating the risk of directly accessing high-authority menus through URLs;
[0096] The whitelist definition module is used to define whitelist paths. The filter first verifies whether the request path is in the whitelist. If so, it is directly released, reducing the verification overhead of non-sensitive paths.
[0097] The permission preloading module is used to load the permission data associated with the corresponding user from the database at one time when the user logs in. The permission data associated with the corresponding user includes menusAll and menus. Among them, menusAll represents the set of all menu paths accessible to the current role (including public interfaces); menus represents the menu permission list actually owned by the current role.
[0098] The session-level cache module is used to cache menuAll and menu data in the user session to avoid repeated database queries for each request and improve system response speed;
[0099] Double-layer verification module, used for double-layer verification to achieve dynamic permission matching;
[0100] Permissions take effect in real time: After modifying the user role in the background, the user needs to log in again to refresh the permission cache in the session to ensure that the permission change takes effect in real time;
[0101] Fault-tolerance mechanism: When the interceptor captures an exception, it records an error log (such as database connection failure, cache invalidation) to avoid system crashes; it generates an audit log for malicious unauthorized behavior to facilitate tracing.
[0102] The working process of the double-layer verification module in this embodiment is as follows:
[0103] First level validation: The filter extracts the request path and checks whether it belongs to the menuAll list:
[0104] If it does not belong to the menusAll list, it is considered a public path and is directly released;
[0105] If it is a permission-sensitive path, it will enter the second level of verification;
[0106] Second level validation: Compare the request path with the menu list:
[0107] If the user does not have access rights, the system will be forced to jump to the login page or error page, and an unauthorized access log will be generated.
[0108] Example 3:
[0109] An embodiment of the present invention further provides an electronic device, comprising: a memory and at least one processor;
[0110] wherein the memory stores computer-executable instructions;
[0111] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method for preventing users from skipping levels of menus in an SSM architecture according to any embodiment of the present invention.
[0112] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or any conventional processor, etc.
[0113] The memory can be used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, the memory can also include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state memory devices.
[0114] Example 4:
[0115] This embodiment further provides a computer-readable storage medium storing a plurality of instructions, which are loaded by a processor and cause the processor to execute the method for preventing users from skipping menu levels in an SSM architecture as described in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, wherein the storage medium stores software program code that implements the functions of any of the above-described embodiments, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.
[0116] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute part of the present invention.
[0117] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RYMs, DVD-RWs, DVD+RWs), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer via a communications network.
[0118] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.
[0119] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU installed on the expansion board or expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.
[0120] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention. < / filter> < / filter> < / filter>
Claims
1. A method for preventing users from accessing menus beyond their level in an SSM architecture, characterized in that: This method uses full-path interception and whitelist mechanisms as well as dynamic permission loading and caching mechanisms to prevent users from accessing menus beyond their level. The details are as follows: Full path interception: Configure the custom filter GrantFilter in web.xml, through <url-pattern> / *< / url-pattern> Cover all request paths, eliminating the risk of directly accessing high-authority menus through URLs; Define a whitelist: Define a whitelist path. The filter will first check whether the request path is in the whitelist. If so, it will be released directly, reducing the verification overhead of non-sensitive paths. Permission preloading: When a user logs in, the permission data associated with the corresponding user is loaded from the database at one time. The permission data associated with the corresponding user includes menusAll and menus. Among them, menusAll represents the set of all menu paths accessible to the current role; menus represents the menu permission list actually owned by the current role. Session-level cache: caches menusAll and menus data in the user session; The filter implements dynamic permission matching through double-layer verification.
2. The method for preventing users from accessing menus beyond their level in an SSM architecture according to claim 1, wherein: The request path includes static resources and dynamic interfaces; The whitelist path is / static or / login.
3. The method for preventing users from accessing menus beyond their level in an SSM architecture according to claim 1, wherein: The filter implements dynamic permission matching through double-layer verification as follows: First level validation: The filter extracts the request path and checks whether it belongs to the menuAll list: If it does not belong to the menusAll list, it is considered a public path and is directly released; If it is a permission-sensitive path, it will enter the second level of verification; Second level validation: Compare the request path with the menu list: If the user does not have access rights, the system will be forced to jump to the login page or error page, and an unauthorized access log will be generated.
4. The method for preventing users from accessing menus beyond their level in an SSM architecture according to claim 1, wherein: In this method, permission data is loaded lazily. Specifically, when a user logs in, the data is loaded from the database and cached in the session. After a role change, the user logs in again to refresh the cache, ensuring that permission changes take effect in real time.
5. The method for preventing users from accessing menus beyond their own level in an SSM architecture according to claim 1, wherein: This method also adopts a fault-tolerant mechanism, specifically: recording error logs when the filter captures an exception to avoid system crashes; and generating audit logs for malicious unauthorized behavior to facilitate tracing; among them, error logs include database connection failures and cache invalidations.
6. The method for preventing users from accessing menus across levels in an SSM architecture according to any one of claims 1 to 5, characterized in that: The full-path interception and whitelist mechanism is as follows: Define a filter: define the filter grantFilter and specify the filter implementation class com.inspur.utils.GrantFilter class, which is used to implement the javax.servlet.Filter interface; Map a filter to a specific URL pattern: Specify the filter name to map <filter-name>And with <filter> The name of the tag is consistent with that in the filter and specifies the URL pattern that the filter intercepts.< / filter> 7. A system for preventing users from skipping levels to access menus in an SSM architecture, characterized in that: The system includes: Full path interception module, used to configure custom filter GrantFilter in web.xml, through <url-pattern> / *< / url-pattern> Cover all request paths, eliminating the risk of directly accessing high-authority menus through URLs; The whitelist definition module is used to define whitelist paths. The filter first verifies whether the request path is in the whitelist. If so, it is directly released, reducing the verification overhead of non-sensitive paths. The permission preloading module is used to load the permission data associated with the corresponding user from the database at one time when the user logs in. The permission data associated with the corresponding user includes menusAll and menus. Among them, menusAll represents the set of all menu paths accessible to the current role (including public interfaces); menus represents the menu permission list actually owned by the current role. Session-level cache module, used to cache menusAll and menus data in the user session; Double-layer verification module, used for double-layer verification to achieve dynamic permission matching.
8. The system for preventing users from skipping levels of menu access in an SSM architecture according to claim 7, characterized in that: The working process of the double-layer verification module is as follows: First level validation: The filter extracts the request path and checks whether it belongs to the menuAll list: If it does not belong to the menusAll list, it is considered a public path and is directly released; If it is a permission-sensitive path, it will enter the second level of verification; Second level validation: Compare the request path with the menu list: If the user does not have access rights, the system will be forced to jump to the login page or error page, and an unauthorized access log will be generated.
9. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the method for preventing a user from accessing a menu beyond a certain level in an SSM architecture as claimed in any one of claims 1 to 6.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the method for preventing a user from accessing a menu beyond a certain level in an SSM architecture as claimed in any one of claims 1 to 6.