Rights management method and device for journal management system, and electronic device

Abstract

The present application provides a permission management method and device for a journal management system, and an electronic device, and relates to the field of computer technology. The method receives an HTTP request initiated by a front-end user; obtains user information such as the current user type and the current user role through the token in the request header of the HTTP request; obtains the current journal identifier in the request header of the HTTP request; obtains the current project type in the Web table through the current journal identifier; calls a pre-built journal permission association table for recording journal management permissions of different user types, implements journal permission allocation and super administrator role and permission allocation and operation through the journal permission association table, and allocates and operates permissions for non-super administrator roles of journals through the user role permission table, flexibly adapts to different types of user roles, and ensures the security and refined control of journal system permissions.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a permission management method and device, electronic equipment and storage medium for a journal management system. Background Art

[0002] In the digital age, the types of academic publications and journals have exploded, which not only provides researchers and readers with a wider range of knowledge resources, but also places higher demands on journal management systems. Traditional content management systems (CMS) often fail to foresee such complex management needs when they are designed, and therefore seem unable to cope with modern journal management tasks.

[0003] The challenges facing modern journal management include, but are not limited to: how to effectively manage multiple journal groups and individual journals to ensure that the organization and presentation of content are both orderly and easily accessible; how to configure corresponding access controls based on the roles and permissions of different users to ensure information security while providing personalized services, etc., which have become technical issues that need to be solved urgently. Summary of the invention

[0004] In view of the above problems, the present application is proposed to provide a method and device for managing rights in a journal management system, an electronic device and a storage medium that overcome the above problems or at least partially solve the above problems. The technical solution is as follows:

[0005] In a first aspect, a permission management method for a journal management system is provided, comprising:

[0006] Pre-building a web table for storing basic information of different project types, wherein the basic information of different project types includes different project types and journal identifiers;

[0007] Receive HTTP requests initiated by front-end users;

[0008] Obtain the current user type and the current user role through the token in the request header of the HTTP request;

[0009] Obtaining a current journal identifier from a request header of the HTTP request;

[0010] Get the current item type in the Web table by the current journal identifier;

[0011] Call a pre-built journal permission association table for recording journal management permissions of different user types, determine which project type the super administrator is based on the current user type and the current project type, determine the permission set of the super administrator based on the current journal identifier and the journal permission association table, and return the super administrator role and permission set to the front-end user; or, determine that the user is a non-super administrator based on the current user type and the current project type, determine the permission set of the non-super administrator based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table, and return the non-super administrator role and permission set to the front-end user.

[0012] In a second aspect, a rights management device for a journal management system is provided, comprising:

[0013] A construction unit, used for pre-constructing a Web table for storing basic information of different project types, wherein the basic information of different project types includes different project types and journal identifiers;

[0014] A receiving unit, used to receive HTTP requests initiated by front-end users;

[0015] An acquisition unit, used to obtain the current user type and the current user role through the token in the request header of the HTTP request; obtain the current journal identifier in the request header of the HTTP request; and obtain the current project type in the Web table through the current journal identifier;

[0016] The determination unit calls a pre-built journal permission association table for recording journal management permissions of different user types, determines which type of project the super administrator is based on the current user type and the current project type, determines the permission set of the super administrator based on the current journal identifier and the journal permission association table, and returns the super administrator role and permission set to the front-end user; or, determines that the user is a non-super administrator based on the current user type and the current project type, determines the permission set of the non-super administrator based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table, and returns the non-super administrator role and permission set to the front-end user.

[0017] In a third aspect, an electronic device is provided, comprising a processor and a memory, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute any of the above-described rights management methods for a journal management system.

[0018] In a fourth aspect, a storage medium is provided, wherein the storage medium stores a computer program, wherein the computer program is configured to execute any of the above-mentioned rights management methods for a journal management system when running.

[0019] By means of the above technical scheme, the embodiment of the present application provides a permission management method and device for a journal management system, an electronic device and a storage medium, the method pre-constructs a Web table for storing basic information of different project types, where the basic information of different project types includes different project types and journal identifiers; receives an HTTP request initiated by a front-end user; obtains user information such as the current user type and the current user role through a token in a request header of the HTTP request; obtains the current journal identifier in the request header of the HTTP request; obtains the current project type in the Web table through the current journal identifier; calls a pre-constructed journal permission association table for recording journal management permissions of different user types, determines journal permissions and super administrator roles and permissions according to the current user type, current project type, current journal identifier and journal permission association table, and returns the super administrator roles and permissions to the front-end user; or, determines non-super administrator user roles and user permissions and operations according to the current user type, current project type, current journal identifier, current user role, journal permission association table and user role permission table, and returns the non-super administrator user roles and user permissions to the front-end user.

[0020] It can be seen that this embodiment uses the Web table to distinguish different project types, uses the journal permission association table to implement journal permission allocation and super administrator role and permission allocation and operation, and uses the user role permission table to allocate and operate permissions for non-super administrator roles of journals, flexibly adapting to different types of user roles to ensure the security and refined control of journal system permissions. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in describing the embodiments of the present application are briefly introduced below.

[0022] Figure 1 A flowchart of a method for managing permissions in a journal management system provided by an embodiment of the present application is shown;

[0023] Figure 2 A structural diagram of a rights management device for a journal management system provided in an embodiment of the present application is shown;

[0024] Figure 3 A structural diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0025] The exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that such use is interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the term "including" and its variants are to be interpreted as open-ended terms meaning "including but not limited to".

[0027] In order to solve the above technical problems, the present application embodiment provides a permission management method for a journal management system, such as Figure 1 As shown, the rights management method for a journal management system may include the following steps S101 to S106:

[0028] Step S101 : pre-build a Web table for storing basic information of different project types, where the basic information of different project types includes different project types and journal identifiers.

[0029] In this step, the Web table, that is, the journal table, has a web_id field used to store journal identifiers and a projectType field used to store different project types.

[0030] For example, the field value of projectType is 1, indicating a central control platform; the field value is 2, indicating a journal group, also known as a site group; the field value is 3, indicating a single journal, also known as a site. It should be noted that the examples listed here are only illustrative and do not limit this embodiment.

[0031] Step S102, receiving an HTTP request initiated by a front-end user.

[0032] In this step, the full name of HTTP is Hypertext Transfer Protocol.

[0033] For example, the HTTP request initiated by the front-end user includes the following:

[0034] 1. User requests URL (Uniform Resource Locator) interface The user initiates an HTTP request, the target is the specified URL interface.

[0035] 2. The request header contains information

[0036] Token: user's identity information and permission data;

[0037] projectWebId: The journal identifier retrieved from the access address.

[0038] 3. Token structure

[0039] userId: unique identifier of the user;

[0040] login: user's login account;

[0041] userWebId: the journal identifier to which the user belongs;

[0042] userRoleId: user role;

[0043] userType: User type, divided into three types:

[0044] 1) Central control platform users; 2) Publication group users; 3) Single publication users;

[0045] authsList: Menu permission list, which controls the user's access rights to system function modules.

[0046] 4. Request process

[0047] When a user initiates a request, the token and projectWebId must be placed in the request header for authentication and authorization to ensure that the user can access the target interface.

[0048] This structure is used to ensure the legitimacy and security of requests and to control user access rights to different functional modules.

[0049] Step S103, obtaining the current user type and the current user role through the token in the request header of the HTTP request.

[0050] In this step, taking the above example, the current user type can be obtained from the field userType, and the current user role can be obtained from the field userRoleId.

[0051] Step S104, obtaining the current journal identifier from the request header of the HTTP request.

[0052] In this step, taking the above example, the journal identifier to which the current request belongs can be obtained from the projectWebId field.

[0053] Step S105, obtaining the current project type in the Web table through the current journal identifier.

[0054] In this step, taking the above example, the current project type can be obtained from the projectType field of the Web table.

[0055] Step S106, calling a pre-constructed journal permission association table for recording journal management permissions of different user types, determining which type of project the super administrator is based on the current user type and the current project type, determining the permission set of the super administrator based on the current journal identifier and the journal permission association table, and returning the super administrator role and permission set to the front-end user; or, determining that the current user type and the current project type are non-super administrators, determining the permission set of the non-super administrator based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table, and returning the non-super administrator role and permission set to the front-end user.

[0056] In this step, different user types are recorded in the journal permission association table, for example, 1) central control platform users; 2) journal group users; 3) single journal users.

[0057] The journal authority association table records the management authority of each journal, for example, all management authority of the journal numbered "Journal of Virology" and all management authority of the journal numbered "Journal of Engineering Science".

[0058] The user role permission table is used to record the relationship between users and roles, as well as the correspondence between roles and permissions. For example, in the journal numbered "Journal of Virology", user Zhang San has the "Editor" role, and the "Editor" role can operate the article management module, document management module, navigation bar management module and other permissions.

[0059] The permission set in the journal permission association table restricts the user role permission set in the user role permission table. For example, in the journal permission association table of "Journal of Virology", if only the permissions of the article management module and the document management module are set, then the "Editor" role of user Zhang San in this journal can only be assigned the permissions of the article management module and the document management module, and cannot be assigned the permissions of the navigation bar management module.

[0060] The journal permission association table can also generate different super administrator permissions based on the current journal number, user type, and project type:

[0061] 1) Central Control Platform Super Administrator: has all permissions in the journal permission association table of the Central Control Platform;

[0062] 2) Journal group super administrator: has all permissions of the current journal group in the journal permission association table;

[0063] 3) Single journal super administrator: has all permissions of the current single journal in the journal permission association table.

[0064] The specific rules are as follows:

[0065] When the user type is "Central Control Platform User" and the project type is "Publication Group", the role is "Publication Group Super Administrator".

[0066] When the user type is "Central Control Platform User" or "Publication Group" and the project type is "Single Publication", the role is "Single Publication Super Administrator".

[0067] Furthermore, the user role can be determined according to the current user type and the current project type. Specifically, if a central control platform user enters a single journal, the user role is the single journal super administrator; if a central control platform user enters a journal group, the user role is the journal group super administrator; if a journal group user enters a single journal, the user role is the single journal super administrator; if a single journal user enters a single journal, or a journal group user enters a journal group, or a central control platform user enters the central control platform, the user role can be the currently logged-in user role.

[0068] It should be noted that the examples here are only illustrative and do not limit this embodiment.

[0069] This embodiment uses a Web table to distinguish different project types, uses a journal permission association table to implement journal permission allocation and super administrator role and permission allocation and operation, and uses a user role permission table to allocate and operate permissions for non-super administrator roles of journals, flexibly adapting to different types of user roles to ensure the security and refined control of journal system permissions.

[0070] The embodiment of the present application provides a possible implementation method. The basic information of different project types mentioned in step S101 above may also include URL information. The target of the HTTP request mentioned in step S102 is a specified URL interface. Then the permission management method for the journal management system may also include the following steps A1 to A3:

[0071] Step A1, obtaining current URL information in the Web table through the current journal identifier;

[0072] Step A2, comparing the specified URL interface with the current URL information to obtain a comparison result;

[0073] Step A3: Return the comparison result to the front-end user.

[0074] This embodiment can more accurately control the user's access rights to specific resources by using URL information as part of the basic information of different project types. This method allows dynamic management of access to different URLs based on the user's role and authority. By comparing the current URL information with the specified URL interface, it can be verified whether the user's request is legal, thereby preventing unauthorized access. This comparison mechanism enhances the security of the system and ensures that only users with appropriate permissions can access specific resources. In addition, the comparison results are returned to the front-end user, which can provide instant feedback to let the user know whether their request is allowed. This instant feedback mechanism improves the user experience and enables users to clearly understand whether their operation is successful.

[0075] In the embodiment of the present application, a possible implementation method is provided. The different project types mentioned in step S101 above may include single journals, journal groups and central control platforms. Then, in step S106 above, the user role and user authority are determined according to the current user type, the current project type and the journal authority association table, which may specifically include the following steps B1 to B4:

[0076] Step B1: determine whether the user is a central control platform user entering a single journal based on the current user type and the current project type. If so, determine that the user role is a single journal super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and the journal authority association table.

[0077] Step B2: determine whether the user is a central control platform user entering the journal group according to the current user type and the current project type. If so, determine that the user role is a journal group super administrator, and the user authority is obtained by obtaining the current journal authority set through the current journal identifier and the journal authority association table;

[0078] Step B3, judging whether it is a journal group user entering a single journal according to the current user type and the current project type, if so, determining that the user role is a single journal super administrator, and the user authority is the current journal authority set obtained through the current journal identifier and the journal authority association table;

[0079] Step B4, based on the current user type and the current project type, determine whether it is a single journal user entering a single journal, or a journal group user entering a journal group, or a central control platform user entering the central control platform. If it is one of them, determine that the user role is the current logged-in user role, the user authority is the authority list obtained by the token of the current logged-in user authority, and the authority list is the user authority list obtained by the current journal identifier and the user role authority table.

[0080] In this step, taking the HTTP request initiated by the front-end user in the previous text as an example, the user permissions are the permission list obtained by the current logged-in user through the authsList field of the token.

[0081] This embodiment can define different user roles according to different user types and project types, such as single journal super administrator, journal group super administrator, etc. This flexibility enables the system to adapt to different management needs and organizational structures.

[0082] The present application provides a possible implementation method. After returning the user role and user authority to the front-end user in step S106, the following steps C1 to C4 may also be included:

[0083] Step C1, receiving a backend interface permission verification request;

[0084] Step C2, obtaining the target user type and target project type according to the backend interface permission verification request;

[0085] Step C3, determine which type of project the super administrator is based on the current user type and the current project type, determine the super administrator's permission set based on the current journal identifier and the journal permission association table, and at the same time, determine whether the user is a non-super administrator based on the current user type and project type, and determine the non-super administrator's permission set based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table. Finally, comprehensively determine the back-end interface permission list allowed to the user;

[0086] Step C4, determine whether the access interface in the backend interface permission verification request is in the backend interface permission list allowed by the user. If so, it is determined that the user has permission and the verification passes; if not, it is determined that the user does not have permission and the verification fails.

[0087] This embodiment verifies the user's access rights to the specific back-end interface. The method ensures that only users with corresponding permissions can access the specific back-end interface, thereby improving the security of the system.

[0088] The present application provides a possible implementation method. After returning the user role and user authority to the front-end user in step S106, the following steps D1 to D3 may also be included:

[0089] Step D1, receiving a multi-tenant legality verification request;

[0090] Step D2, according to the multi-tenant legality verification request, obtain the tenant user type, tenant project type and the journal identifier to which the tenant user belongs;

[0091] Step D3, obtaining the multi-tenant legality verification result according to the tenant user type, tenant project type, the journal identifier to which the tenant user belongs, and the journal authority association table.

[0092] This embodiment uses a legality verification process specially designed for a multi-tenant environment. The method can ensure that when users of different tenants access the system, their operations and access rights comply with their respective tenant settings and permission configurations.

[0093] In the embodiment of the present application, a possible implementation method is provided. In the above step D3, a multi-tenant legality verification result is obtained according to the tenant user type, the tenant project type, the journal identifier to which the tenant user belongs, and the journal authority association table. Specifically, the following steps D31 to D33 may be included:

[0094] Step D31, according to the tenant user type, tenant project type, and journal identifier to which the tenant user belongs, if the tenant project type is the central control platform and the tenant user type is the central control platform user, the multi-tenant legality check passes;

[0095] Step D32: when the tenant project type is journal group, and the tenant user type is central control platform user; or when the tenant project type is journal group, the tenant user type is journal group user, and the current user journal identifier is the same as the journal identifier projectWebId extracted from the access address in S102, the multi-tenant legitimacy check passes;

[0096] Step D33, if the tenant project type is a single journal and the tenant user type is a central control platform user or a journal group user; or, if the tenant project type is a single journal and the tenant user type is a single journal user, and the current user journal identifier is the same as the journal identifier projectWebId extracted from the S102 access address, then the multi-tenant legitimacy check passes.

[0097] This embodiment implements hierarchical permission verification based on tenant user types and project types. Users of different levels (such as central control platform users, publication group users, and single publication users) will have different verification standards when accessing projects of different levels (such as central control platform, publication group, and single publication) to adapt to the complex permission requirements in a multi-tenant environment.

[0098] A possible implementation method is provided in an embodiment of the present application, and may further include the following steps E1 to E3:

[0099] Step E1, in response to the first request of the user to access the portal website, the preset gateway intercepts the first request, stores the journal identifier in the URL of the first request into the request header to obtain a second request, and then forwards the second request to the preset interface of the background.

[0100] In this step, the preset gateway can be an Nginx gateway, which is a high-performance HTTP and reverse proxy web server. The preset interface can be an MVC interface, the full name of which is Model View Controller, which is a software architecture pattern, where M represents model, V represents view, and C represents controller. Here, before storing the journal identifier in the URL of the first request into the request header, the journal identifier can also be checked for permissions, and when the verification passes, the journal identifier in the URL of the first request is stored in the request header to obtain the second request.

[0101] Step E2: The preset interface of the background receives the second request and determines whether there is a corresponding static page. If so, the static page is returned and the preset data is updated. If not, the dynamic page template is called, the journal identifier in the request header is used to obtain the corresponding journal information, and the basic server address and resource relative path of the media library resource are spliced ​​through the unified interface to render the dynamic page template of the journal.

[0102] Step E3, if the rendering is successful, the complete page is returned to the front end; if the rendering fails, an error message is returned to the front end for processing.

[0103] This embodiment uses the Nginx gateway to dynamically inject the journal logo in the URL to perform permission verification, ensuring that users only access authorized resources and returning static pages first; if there are no static pages, resources are loaded through dynamic templates to achieve efficient page loading and permission management. In addition, during the page rendering process, if the rendering is successful, the complete page is returned to the front end; if the rendering fails, the error information is returned to the front end for processing, which helps the front end to discover and handle problems in a timely manner and improves the user experience.

[0104] The above introduces Figure 1 There are multiple implementation methods for each link of the illustrated embodiment. The following will further illustrate the permission management method for a journal management system in the embodiment of the present application through specific embodiments.

[0105] As mentioned above, traditional content management systems have obvious limitations when dealing with complex journal management needs. Modern journal management not only needs to handle the management of multiple journal groups and individual journals, but also needs to meet the permission configuration of different users, real-time data updates, and efficient information retrieval needs. In order to meet these challenges, it is necessary to establish a highly integrated and fully functional management platform that can uniformly manage various journals and portals, achieve efficient information processing and seamless system integration.

[0106] Many existing content management systems currently have deficiencies in handling multi-level, multi-tenant journal management. For example, existing systems can only manage single journals, have no journal group function, cannot provide complex permission configuration, or perform poorly in data synchronization and information update. In addition, the integration and optimization of Elasticsearch (ES, a distributed, multi-tenant full-text search engine) are often not given enough attention, which affects the user's search experience and the overall efficiency of the system. Therefore, it is particularly necessary to develop a management platform that can flexibly configure permissions, update information in real time, and optimize data retrieval.

[0107] The V1.0 version of the Tengyun online journal publishing system has multiple defects. First, it can only manage a single journal and cannot handle multiple journal collections or journal groups, which limits its management flexibility and efficiency. Secondly, the permission management function level is single and cannot meet complex permission requirements and role allocation. In addition, the page configuration is fixed and users cannot make customized settings or personalized adjustments, resulting in insufficient adaptability of the interface and functions. Finally, the system does not integrate advanced search engines such as Elasticsearch, resulting in low efficiency in literature retrieval and inability to quickly process large amounts of data and complex queries.

[0108] In the study of existing technical solutions, we first used WordPress (an open source content management system) to build a project for the National Association of Humanities Journals of Higher Education Institutions for in-depth analysis and practical application. Although WordPress provides a site cluster version to support the management of multiple sites, its database structure does not support multi-tenant mode, which limits the management of only one journal group on one platform and cannot support the unified management of multiple journal groups. Although WordPress has a caching function to improve performance, the speed of dynamic query of literature data is still slow when processing large-scale data. In addition, WordPress has not optimized the Elasticsearch search engine, which further limits its ability to efficiently retrieve large amounts of literature data.

[0109] At the same time, we conducted extensive literature reading and field research on the Atypon project. Atypon is a content management system designed for academic publications, providing functions such as journal publishing, membership management, and literature retrieval. However, field research and data research revealed the shortcomings of Atypon in multi-journal group management and permission configuration. Atypon lacks flexibility in multi-journal group management and fails to provide the required multi-level management support. Its permission configuration function is relatively fixed and cannot adapt to complex permission requirements. In addition, Atypon's optimization of Elasticsearch is not sufficient, resulting in low efficiency in literature data retrieval. These problems expose the limitations of current technical solutions in dealing with complex journal management needs.

[0110] How to achieve efficient information flow between multiple journal groups, individual journals and the portal sites they involve has become an important challenge in the industry. Therefore, building a system that can improve the integration and information synchronization mechanism of the central control platform, individual journals, journal groups and portal sites is of great significance to ensure data flow between different systems, improve user experience and overall efficiency.

[0111] This application proposes an innovative method to uniformly manage single journals and journal groups through a central control platform, and journal groups can also manage single journals (also called sub-journals) under them. Each single journal and journal group can be personalized in the portal configuration in the background, and the journal group portal can also include all the resources of the sub-portal to form a complete journal ecosystem. The system also implements refined user management functions. The central control platform can limit the permissions of journal groups and single journals, and in the background of journal groups and single journals, the permissions of role users can be further restricted. Through this progressive management method, the system can flexibly adjust the organizational structure and portal management methods according to the actual needs of the journal industry, so as to meet the personalized needs of different users, improve the adaptability and flexibility of the system, significantly shorten the product release cycle, and improve social productivity.

[0112] 1. Unified middle platform, multiple journal groups, and multiple single journal management system structure:

[0113] A multi-tenant model is adopted and the database and table are divided. A universal Web table is designed to store the basic information of single journals, journal groups and the central control platform, and the records of different project types are distinguished by the field projectType.

[0114] For example, the field value of projectType is 1, indicating a central control platform; the field value is 2, indicating a journal group, also known as a site group; the field value is 3, indicating a single journal, also known as a site, as shown in Table 1 below. It should be noted that the examples listed here are only illustrative and do not limit this embodiment.

[0115] Table 1 Web table

[0116]

[0117]

[0118] The management of journal groups involves the "association table between journal groups and single journals", which is used to bind sub-journals and achieve unified management of multiple sites, as shown in Table 2 below.

[0119] Here, a publication group can contain multiple sub-publications. For example, a group publication group can contain 30 sub-publications. This is the concept of publication groups and sub-publications. When adding sub-publications to a publication group, you actually select them from the complete collection of single publications. By associating the single publication with the publication group, the single publication becomes a sub-publication of the publication group.

[0120] Table 2 Association table between journal groups and single journals

[0121] Field Name type describe web_id varchar(50) Journal Identifier subweb_id varchar(50) Sub-publication logo ... ... ...

[0122] 2. Refined multi-level permission management structure:

[0123] The central control platform manages individual journals and journal groups in a unified manner. Users only need to use one account to seamlessly access the backends of all individual journals and journal groups under different domain names. At the same time, each journal group and individual journal also supports logging into the backend for management through their own platform interface.

[0124] Through the "journal permission association table" (web_permission) and "user role permission table" (user-role-permission) models, the system can finely manage the permission sets of the central control platform, journal groups, single journals and sub-journals. Different user roles operate on resources at different levels based on their permission range.

[0125] 1. Permission configuration structure

[0126] Journal permission configuration: The web_permission table is used to store the permission sets of different journals such as the central control platform, journal group, single journal, and sub-journal, as shown in Table 3 below. This ensures that the permission sets at each level do not conflict with each other and maintains hierarchical management of permissions.

[0127] User permission configuration: The user-role-permission model is used to manage the relationship between users, roles, and permissions, as shown in Tables 4 to 8 below. Users can be divided into three types:

[0128] 1) Central control platform users: responsible for the management of the central control platform, publication groups, and individual publications.

[0129] 2) Publication group users: manage specific publication groups and their sub-publications.

[0130] 3) Single publication user: manage only specific single publications.

[0131] Table 3 Journal authority association table

[0132] Field Name type describe web_id varchar(50) Journal Identifier permission_id varchar(50) Permission ID (unique ID for each permission set)

[0133] Table 4 User role permission table - user table

[0134]

[0135] Table 5 User role permission table - role table

[0136]

[0137] Table 6 User role permission table - permission table

[0138]

[0139]

[0140] Table 7 User role permission table - user role association table

[0141] Field Name type describe web_id varchar(50) Journal Logo role_id varchar(50) Role Identification user_id varchar(50) User ID

[0142] Table 8 User role permission table - role permission association table

[0143] Field Name type describe web_id varchar(50) Journal Logo role_id varchar(50) Role Identification permission_id varchar(50) Permission flag ... ... ...

[0144] 2. Structural characteristics

[0145] Permission association table: Configure the permission set of each journal through the "Journal Permission Association Table", and assign the full set of journal permissions in the journal permission variable table to different super administrators based on user type and project type, thereby achieving integrated management.

[0146] User role permission table: By assigning roles to users and binding permissions to roles, we manage resources and permission sets at different levels to ensure refined permission control for ordinary users and avoid unauthorized operations.

[0147] Flexibility: The structure supports multi-level permission allocation, making permission management more flexible and adaptable to different roles and scopes of operation. System administrators can quickly modify permissions based on business needs without affecting existing permission configurations.

[0148] 3. Permission allocation process

[0149] 1) Central control platform administrator:

[0150] The "Journal Permission Association Table" can be used to assign the maximum permission set to the central control platform, journal groups, and single journals in the system. This is the highest level of permission allocation.

[0151] Assign permissions to the user with userType=middle station through user-role-permission.

[0152] 2) Publication Group Administrator:

[0153] The maximum permission set can be set for each journal in the system through the "Journal Permission Association Table".

[0154] Assign permissions to users of the journal group through user-role-permission.

[0155] 3) Single publication administrator:

[0156] The operation can only be performed within the scope of permissions assigned by the central control platform or journal group. Permissions are assigned to the single journal user through user-role-permission.

[0157] The permission structure designed in this way can ensure the flexible management of the system under multi-level permissions, while ensuring system security and control granularity.

[0158] 4. Authorization access flow chart

[0159] 1) The user obtains front-end permissions, which may include the following steps 1.1 to 1.8:

[0160] Step 1.1, receive the HTTP request initiated by the front-end user, and obtain the current user type through the token in the request header of the HTTP request.

[0161] As mentioned above, the token structure can be used to obtain the current user type from the userType field. For example, a userType value of 1 indicates a central control platform user; a value of 2 indicates a publication group user, also known as a site group user; and a value of 3 indicates a single publication user, also known as a site user.

[0162] Step 1.2, obtain the current journal identifier in the request header of the HTTP request.

[0163] In this step, the current journal identifier can be obtained from the projectWebId field.

[0164] Step 1.3, obtain the current item type in the Web table through the current journal identifier.

[0165] In this step, the current project type can be obtained from the projectType field of the Web table.

[0166] In the Web table, the projectType field is used to store different project types. For example, the field value of projectType is 1, which indicates the central control platform; the field value is 2, which indicates a publication group, also known as a site group; the field value is 3, which indicates a single publication, also known as a site.

[0167] Step 1.4, call the pre-built journal permission association table for recording journal management permissions of different user types, determine which type of project the super administrator is based on the current user type and the current project type, determine the permission set of the super administrator based on the current journal identifier and the journal permission association table, and at the same time, determine whether it is a non-super administrator based on the current user type and project type, and determine the non-super administrator permission set based on the current journal identifier, current user role, journal permission association table, and user role permission table. Finally, comprehensively determine the user role and user permissions and return them to the front-end user; if not, continue with the following step 1.5.

[0168] Step 1.5, determine whether the central control platform user enters the journal group. If so, determine that the user role is the journal group super administrator, the user authority is the current journal authority set, and return the user role and user authority to the front-end user; if not, proceed to the following step 1.6.

[0169] Step 1.6, determine whether the central control platform user enters the single journal. If so, determine that the user role is a single journal super administrator, the user authority is the current journal authority set, and return the user role and user authority to the front-end user; if not, proceed to the following step 1.7.

[0170] Step 1.7, determine whether it is a journal group user entering a single journal. If so, determine that the user role is a single journal super administrator, the user authority is the current journal authority set, and return the user role and user authority to the front-end user; if not, proceed to the following step 1.8.

[0171] Step 1.8, determine whether it is a single journal user entering a single journal, a journal group user entering a journal group, or a central control platform user entering the central control platform. If it is one of them, determine that the user role is the current login user role, and the user authority is the authority list obtained by the token of the current login user authority, and return the user role and user authority to the front-end user.

[0172] The central control platform users here are also called central control administrators, and publication group users are also called publication group administrators.

[0173] 2) Calling backend permission verification may include the following steps 2.1 to 2.5:

[0174] Step 2.1, receive the backend interface permission verification request, and obtain the target user type according to the token in the request header of the backend interface permission verification request.

[0175] As described in the token structure above, the target user type can be obtained from the userType field. For example, the field value of userType is 1, which indicates a central control platform user; the field value is 2, which indicates a publication group user, also known as a site group user; the field value is 3, which indicates a single publication user, also known as a site user.

[0176] Step 2.2, obtain the target journal identifier in the request header of the backend interface permission verification request.

[0177] In this step, the target journal identifier can be obtained from the projectWebId field.

[0178] Step 2.3, obtain the target project type in the Web table through the target journal identifier.

[0179] In this step, the target project type can be obtained from the projectType field of the Web table.

[0180] In the Web table, the projectType field is used to store different project types. For example, the field value of projectType is 1, which indicates the central control platform; the field value is 2, which indicates a publication group, also known as a site group; the field value is 3, which indicates a single publication, also known as a site.

[0181] Step 2.4, based on the target user type and target project type, determine the list of backend interface permissions allowed to the user.

[0182] In this step, the target project type can be determined first. If the target project type is a journal group, it is further determined whether the target user type is a central control platform user. If so, it is determined that the user's allowed back-end interface permission list is all interface permissions of the current journal; if not, it is determined that the user's allowed back-end interface permission list is the interface permission list in the token.

[0183] If the target project type is a single journal, it is further determined whether the target user type is a central control platform user. If the target user type is a central control platform user, it is determined that the list of back-end interface permissions allowed for the user is all interface permissions for the current journal; if the target user type is not a central control platform user, it is further determined whether the target user type is a journal group user. If the target user type is a journal group user, it is determined that the list of back-end interface permissions allowed for the user is all interface permissions for the current journal; if the target user type is not a journal group user, it is determined that the list of back-end interface permissions allowed for the user is the interface permission list in the token.

[0184] Step 2.5, determine whether the access interface in the backend interface permission verification request is in the backend interface permission list allowed by the user. If so, it is determined that the user has permission and the verification passes; if not, it is determined that the user does not have permission and the verification fails.

[0185] The central control platform users here are also called central control administrators, and publication group users are also called publication group administrators.

[0186] 3) Multi-tenant legitimacy verification may include the following steps 3.1 to 3.7:

[0187] Step 3.1, receive a multi-tenant legitimacy verification request, and obtain the tenant user type according to the token in the request header of the multi-tenant legitimacy verification request.

[0188] As described in the token structure above, the tenant user type can be obtained from the userType field. For example, the field value of the userType field is 1, which indicates a central control platform user; the field value is 2, which indicates a publication group user, also known as a site group user; the field value is 3, which indicates a single publication user, also known as a site user.

[0189] Step 3.2, obtain the journal identifier of the tenant in the request header of the multi-tenant legality verification request.

[0190] In this step, the journal identifier to which the tenant belongs can be obtained from the projectWebId field.

[0191] Step 3.3, obtain the tenant item type in the Web table through the journal identifier to which the tenant belongs.

[0192] In this step, the tenant project type can be obtained from the projectType field of the Web table.

[0193] In the Web table, the projectType field is used to store different project types. For example, the field value of projectType is 1, which indicates the central control platform; the field value is 2, which indicates a publication group, also known as a site group; the field value is 3, which indicates a single publication, also known as a site.

[0194] Step 3.4, obtain the journal identifier of the tenant user according to the token in the request header of the multi-tenant legitimacy verification request.

[0195] Step 3.5: Based on the tenant user type, tenant project type, and journal identifier to which the tenant user belongs, if the tenant project type is the central control platform and the tenant user type is the central control platform user, the multi-tenant legitimacy check passes.

[0196] In step 3.6, if the tenant project type is a publication group and the tenant user type is a central control platform user or a publication group user, the multi-tenant legitimacy check passes.

[0197] In step 3.7, if the tenant project type is a single journal and the tenant user type is a central control platform user, journal group user or single journal user, the multi-tenant legitimacy check passes.

[0198] The central control platform users here are also called central control administrators, and publication group users are also called publication group administrators.

[0199] 3. Dynamic permission verification and intelligent resource loading method of portal system:

[0200] User access and Nginx interception: When a user accesses the portal website, the Nginx gateway intercepts the request, stores the webId in the URL in the header, and then forwards the request to the MVC interface in the background.

[0201] Static page check: The background interface receives the request and determines whether there is a corresponding static page. If so, it returns the static page and updates local data, such as page views.

[0202] Dynamic template processing: If there is no static page, call the dynamic page template, use the webId in the header to obtain the corresponding journal information, and use the unified interface to splice the baseurl (i.e. the basic server address) and the relative path of the resource in the media library to render the template of the journal.

[0203] Rendering and return: After successful rendering, the complete page is returned to the front end; if it fails, the error information is returned to the front end for processing.

[0204] 4. Real-time document data synchronization and query optimization:

[0205] The data synchronization module uses binlog (binary log) synchronization technology to synchronize the literature data of different magazines to Elasticsearch (ES) in real time. This method ensures the consistency and real-time nature of the data, making query operations more efficient and accurate.

[0206] Implementation process:

[0207] Data capture: By configuring MySQL binlog, changes to document data in the database are recorded.

[0208] Data analysis: Use analysis tools to analyze data changes in binlog in real time and extract document data that needs to be synchronized.

[0209] Data conversion: Convert the parsed data into a format supported by Elasticsearch for subsequent storage operations.

[0210] Data writing: Write the converted data in batches to the ES cluster through Elasticsearch's batch API (Application Programming Interface).

[0211] Data query optimization: With the help of ES's inverted index mechanism, the query performance of literature data is optimized to support complex query requirements such as full-text retrieval and multi-field query.

[0212] Through this solution, the system can ensure that when the document data of different magazines changes in their respective databases, they are synchronized to ES in a timely manner to provide unified and efficient query services. ES inverted index technology is more suitable for portal document search, but for complex system business, it is recommended to use a distributed database that supports SQL to support more complex business.

[0213] 5. Relationship between members and journals:

[0214] The relationship between members and journals is stored in the member-journal association table (member_web_id), which records the corresponding relationship between members and multiple journals they follow. The relationship can be imported through members following journals or through the journal backend.

[0215] This embodiment can achieve the following technical effects:

[0216] Support for multiple journal groups: This application provides a unified platform to manage multiple journal groups and single journals, overcoming the limitations of multiple journal group management in existing systems such as WordPress, and achieving more flexible management and configuration.

[0217] Flexible permission configuration: This application has multi-level and complex permission configuration functions. Compared with WordPress and Atypon, it can allocate permissions and roles more finely to meet the needs of different users.

[0218] Optimized search engine integration: This application has deeply optimized search engines such as Elasticsearch, improving the speed and accuracy of literature retrieval. Compared with the old version of the online journal and Atypon, it can handle large-scale data and complex queries more effectively.

[0219] Customized page configuration: This application supports flexible page configuration and customization options, providing greater adaptability and user-friendliness compared to the fixed pages of the old online magazine.

[0220] Unified multi-level management: This application implements a unified multi-level management structure, supports complex journal group and single journal management, and provides more powerful management support and efficiency improvement compared to the limitations of Atypon.

[0221] It should be noted that the size of the sequence number of each step in the above embodiment does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. In practical applications, all the above possible implementation methods can be combined in any way to form possible embodiments of the present application, which will not be described one by one here.

[0222] Based on the rights management methods for journal management systems provided in the above embodiments, and based on the same inventive concept, an embodiment of the present application also provides a rights management device for a journal management system.

[0223] Figure 2 is a structural diagram of a rights management device for a journal management system provided in an embodiment of the present application. Figure 2 As shown, the rights management device for a journal management system may specifically include a construction unit 210 , a receiving unit 220 , an acquisition unit 230 and a determination unit 240 .

[0224] A construction unit 210, configured to pre-construct a Web table for storing basic information of different project types, wherein the basic information of different project types includes different project types and journal identifiers;

[0225] The receiving unit 220 is used to receive an HTTP request initiated by a front-end user;

[0226] The acquisition unit 230 is used to obtain the current user type and the current user role through the token in the request header of the HTTP request; obtain the current journal identifier in the request header of the HTTP request; and obtain the current project type in the Web table through the current journal identifier;

[0227] The determination unit 240 is used to call a pre-constructed journal permission association table for recording journal management permissions of different user types, determine which type of project the super administrator is based on the current user type and the current project type, determine the permission set of the super administrator based on the current journal identifier and the journal permission association table, and return the super administrator role and permission set to the front-end user; or, determine that the user is a non-super administrator based on the current user type and the current project type, determine the permission set of the non-super administrator based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table, and return the non-super administrator role and permission set to the front-end user.

[0228] The present application provides a possible implementation method, wherein the basic information of different project types also includes URL information; the target of the HTTP request is a specified URL interface; Figure 2 The device shown may also include a comparison unit (attached Figure 2 ), for:

[0229] Obtain the current URL information in the Web table through the current journal identifier;

[0230] Compare the specified URL interface with the current URL information to obtain the comparison result;

[0231] The comparison results are returned to the front-end user.

[0232] A possible implementation method is provided in an embodiment of the present application, wherein the different project types include a single journal, a journal group, and a central control platform; the determining unit 240 is further configured to:

[0233] According to the current user type and current project type, determine whether the central control platform user enters the single journal. If so, determine that the user role is a single journal super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and journal authority association table;

[0234] According to the current user type and current project type, determine whether the central control platform user enters the journal group. If so, determine that the user role is a journal group super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and journal authority association table;

[0235] According to the current user type and current project type, determine whether it is a journal group user entering a single journal. If so, determine that the user role is a single journal super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and journal authority association table;

[0236] According to the current user type and the current project type, determine whether it is a single journal user entering a single journal, a journal group user entering a journal group, or a central control platform user entering the central control platform. If it is one of them, determine that the user role is the current login user role, the user authority is the authority list obtained by the current login user authority through the token, and the authority list is the user authority list obtained through the current journal identifier and the user role authority table.

[0237] A possible implementation method is provided in the embodiment of the present application. Figure 2 The device shown may also include a back-end interface authority verification unit (attached Figure 2 ), for:

[0238] Receive backend interface permission verification request;

[0239] According to the backend interface permission verification request, obtain the target user type and target project type;

[0240] Determine which type of project the super administrator is based on the target user type and target project type, and determine the super administrator's permission set based on the current journal identifier and journal permission association table; or determine that the user is a non-super administrator based on the current user type and project type, and determine the non-super administrator's permission set based on the current journal identifier, current user role, journal permission association table, and user role permission table; finally, comprehensively determine the backend interface permission list allowed to the user;

[0241] Determine whether the access interface in the backend interface permission verification request is in the backend interface permission list allowed by the user. If so, it is determined that the user has the permission and the verification passes; if not, it is determined that the user does not have the permission and the verification fails.

[0242] A possible implementation method is provided in the embodiment of the present application. Figure 2 The device shown may also include a multi-tenant legality verification unit (attached Figure 2 ), for:

[0243] After returning the user role and user permissions to the front-end user, receive multi-tenant legitimacy verification requests;

[0244] According to the multi-tenant legality verification request, obtain the tenant user type, tenant project type and the journal identifier to which the tenant user belongs;

[0245] The multi-tenant legality verification result is obtained based on the tenant user type, tenant project type, and the journal identifier to which the tenant user belongs.

[0246] A possible implementation method is provided in an embodiment of the present application, wherein the multi-tenant legality verification unit is further used to:

[0247] According to the tenant user type, tenant project type, and journal identifier to which the tenant user belongs, if the tenant project type is the central control platform and the tenant user type is the central control platform user, the multi-tenant legality check passes;

[0248] When the tenant project type is a journal group, and the tenant user type is a central control platform user; or when the tenant project type is a journal group, the tenant user type is a journal group user, and the current journal identifier is the same as the journal identifier taken from the access address in the request header, the multi-tenant legitimacy check passes;

[0249] If the tenant project type is a single journal and the tenant user type is a central control platform user or a journal group user; or if the tenant project type is a single journal and the tenant user type is a single journal user, and the current user journal identifier is the same as the journal identifier taken from the access address in the request header, the multi-tenant legitimacy check passes.

[0250] A possible implementation method is provided in the embodiment of the present application. Figure 2 The device shown may also include a resource loading unit (attached Figure 2 ), for:

[0251] In response to a first request from a user to access the portal website, a preset gateway intercepts the first request, stores the journal identifier in the URL of the first request into a request header to obtain a second request, and then forwards the second request to a preset interface of the backend;

[0252] The preset interface of the background receives the second request, determines whether there is a corresponding static page, and if so, returns the static page and updates the preset data; if not, calls the dynamic page template, uses the journal identifier in the request header to obtain the corresponding journal information, and splices the basic server address and resource relative path of the media library resource through the unified interface to render the dynamic page template of the journal;

[0253] If the rendering is successful, the complete page is returned to the front end; if the rendering fails, the error message is returned to the front end for processing.

[0254] Based on the same inventive concept, an embodiment of the present application also provides an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the permission management method for a journal management system of any one of the above embodiments.

[0255] In an exemplary embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The electronic device 300 shown includes: a processor 301 and a memory 303. The processor 301 and the memory 303 are connected, such as through a bus 302. Optionally, the electronic device 300 may also include a transceiver 304. It should be noted that in actual applications, the transceiver 304 is not limited to one, and the structure of the electronic device 300 does not constitute a limitation on the embodiments of the present application.

[0256] Processor 301 may be a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 301 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0257] The bus 302 may include a path to transmit information between the above components. The bus 302 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 302 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0258] The memory 303 can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0259] The memory 303 is used to store the computer program code for executing the solution of the present application, and the execution is controlled by the processor 301. The processor 301 is used to execute the computer program code stored in the memory 303 to implement the contents shown in the above method embodiment.

[0260] Among them, electronic devices include but are not limited to: mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 3 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0261] Based on the same inventive concept, an embodiment of the present application further provides a storage medium, in which a computer program is stored, wherein the computer program is configured to execute the permission management method for a journal management system of any one of the above embodiments when running.

[0262] Those skilled in the art can clearly understand that the specific working processes of the systems, devices, and modules described above can refer to the corresponding processes in the aforementioned method embodiments, and for the sake of brevity, they are not further described here.

[0263] Those skilled in the art can understand that the technical solution of the present application can be essentially or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, which includes a number of program instructions, so that an electronic device (such as a personal computer, a server, or a network device, etc.) executes all or part of the steps of the method described in each embodiment of the present application when running the program instructions. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0264] Alternatively, all or part of the steps of implementing the aforementioned method embodiments may be accomplished by hardware associated with program instructions (such as electronic devices such as personal computers, servers, or network devices), and the program instructions may be stored in a computer-readable storage medium. When the program instructions are executed by a processor of an electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of the present application.

[0265] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that within the spirit and principles of the present application, they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not deviate from the protection scope of the present application.

Claims

1. A rights management method for a journal management system, characterized in that: include: Pre-building a web table for storing basic information of different project types, wherein the basic information of different project types includes different project types and journal identifiers; Receive HTTP requests initiated by front-end users; Obtain the current user type and the current user role through the token in the request header of the HTTP request; Obtaining a current journal identifier from a request header of the HTTP request; Get the current item type in the Web table by the current journal identifier; Call a pre-built journal permission association table for recording journal management permissions of different user types, determine which project type the super administrator is based on the current user type and the current project type, determine the permission set of the super administrator based on the current journal identifier and the journal permission association table, and return the super administrator role and permission set to the front-end user; or, determine that the user is a non-super administrator based on the current user type and the current project type, determine the permission set of the non-super administrator based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table, and return the non-super administrator role and permission set to the front-end user.

2. The method according to claim 1, characterized in that The basic information of different project types also includes URL information; the target of the HTTP request is a specified URL interface; the method also includes: Obtaining current URL information in the Web table through the current journal identifier; Compare the specified URL interface with the current URL information to obtain the comparison result; The comparison results are returned to the front-end user.

3. The method according to claim 1, characterized in that The different project types include single journal, journal group and central control platform; Determine the project type of super administrator based on the current user type and current project type, including: According to the current user type and current project type, determine whether the central control platform user enters the single journal. If so, determine that the user role is a single journal super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and journal authority association table; According to the current user type and current project type, determine whether the central control platform user enters the journal group. If so, determine that the user role is a journal group super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and journal authority association table; According to the current user type and current project type, determine whether it is a journal group user entering a single journal. If so, determine that the user role is a single journal super administrator. The user authority is obtained by obtaining the current journal authority set through the current journal identifier and journal authority association table; According to the current user type and the current project type, determine whether it is a single journal user entering a single journal, a journal group user entering a journal group, or a central control platform user entering the central control platform. If it is one of them, determine that the user role is the current login user role, the user authority is the authority list obtained by the current login user authority through the token, and the authority list is the user authority list obtained through the current journal identifier and the user role authority table.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: Receive backend interface permission verification request; According to the backend interface permission verification request, obtain the target user type and target project type; Determine the list of backend interface permissions allowed to the super administrator based on the target user type, target project type, current journal identifier and journal permission association table; or determine the list of backend interface permissions allowed to the non-super administrator based on the current journal identifier, current user role, journal permission association table and user role permission table; Determine whether the access interface in the backend interface permission verification request is in the backend interface permission list allowed by the user. If so, it is determined that the user has the permission and the verification passes; if not, it is determined that the user does not have the permission and the verification fails.

5. The method according to any one of claims 1 to 3, characterized in that After returning the user role and user authority to the front-end user, the method further includes: Receive multi-tenant legality verification requests; According to the multi-tenant legality verification request, obtain the tenant user type, tenant project type and the journal identifier to which the tenant user belongs; The multi-tenant legality verification result is obtained according to the tenant user type, tenant project type, the journal identifier to which the tenant user belongs, and the journal authority association table.

6. The method according to claim 5, characterized in that According to the tenant user type, tenant project type, tenant user journal identifier and journal permission association table, the multi-tenant legality verification results are obtained, including: According to the tenant user type, tenant project type, and journal identifier to which the tenant user belongs, if the tenant project type is the central control platform and the tenant user type is the central control platform user, the multi-tenant legality check passes; When the tenant project type is a journal group, and the tenant user type is a central control platform user; or when the tenant project type is a journal group, the tenant user type is a journal group user, and the current journal identifier is the same as the journal identifier taken from the access address in the request header, the multi-tenant legitimacy check passes; If the tenant project type is a single journal and the tenant user type is a central control platform user or a journal group user; or if the tenant project type is a single journal and the tenant user type is a single journal user, and the current user journal identifier is the same as the journal identifier taken from the access address in the request header, the multi-tenant legitimacy check passes.

7. The method according to any one of claims 1 to 3, characterized in that The method further comprises: In response to a first request from a user to access the portal website, a preset gateway intercepts the first request, stores the journal identifier in the URL of the first request into a request header to obtain a second request, and then forwards the second request to a preset interface of the backend; The preset interface of the background receives the second request, determines whether there is a corresponding static page, and if so, returns the static page and updates the preset data; if not, calls the dynamic page template, uses the journal identifier in the request header to obtain the corresponding journal information, and splices the basic server address and resource relative path of the media library resource through the unified interface to render the dynamic page template of the journal; If the rendering is successful, the complete page is returned to the front end; if the rendering fails, the error message is returned to the front end for processing.

8. A rights management device for a journal management system, characterized in that: include: A construction unit, used for pre-constructing a Web table for storing basic information of different project types, wherein the basic information of different project types includes different project types and journal identifiers; A receiving unit, used to receive HTTP requests initiated by front-end users; An acquisition unit, used to obtain the current user type and the current user role through the token in the request header of the HTTP request; Obtaining a current journal identifier from a request header of the HTTP request; Get the current item type in the Web table by the current journal identifier; A determination unit is used to call a pre-built journal permission association table for recording journal management permissions of different user types, determine which type of project the super administrator is based on the current user type and the current project type, determine the permission set of the super administrator based on the current journal identifier and the journal permission association table, and return the super administrator role and permission set to the front-end user; or, determine that the user is a non-super administrator based on the current user type and the current project type, determine the permission set of the non-super administrator based on the current journal identifier, the current user role, the journal permission association table, and the user role permission table, and return the non-super administrator role and permission set to the front-end user.

9. An electronic device, characterized in that: The system comprises a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the rights management method for a journal management system according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the rights management method for a journal management system according to any one of claims 1 to 7 when running.

Images