Tourism data access control method and system, terminal and medium
By building a multi-level permission system and corresponding permission tables, the field-level fine-grained access control of the Cultural Tourism Big Data Platform is realized, which solves the problem of insufficient data access control in the existing technology, and improves data security and user work efficiency .
Patent Information
- Application Number
- CN202411451564.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-17
- Publication Date
- 2025-02-14
AI Technical Summary
The data access control of the existing cultural and tourism big data platform is not refined enough to meet the precise needs of different users in different work scenarios, especially the lack of effective control in the field dimension, which increases the risk of sensitive information leakage.
Adopt a multi-level permission system, including workspace, theme library, data table and fields, and build the first to fourth permission tables respectively, which are used to store various access rights, and obtain their access rights through user identity information to achieve field-level Fine-grained access control.
It realizes refined management and control of cultural and tourism big data, ensuring that users can only obtain the data they need for their work, protect sensitive information to the greatest extent, and improve work efficiency.
Smart Images

Figure CN119442306A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of cultural and tourism data processing, and in particular to a cultural and tourism data access control method, system, terminal and medium. Background Art
[0002] With the rapid development of the cultural tourism industry, the cultural tourism big data platform has accumulated a huge amount of data. These data cover many aspects such as tourist behavior, scenic spot operation, and tourism economy, and are of extremely high value. However, the diversity and complexity of data bring challenges to data security and privacy protection. In the existing big data platform, data access control is often not sophisticated enough to meet the precise data needs of different users in different work scenarios. Although the industry data in the public theme library has a certain degree of openness, the work theme library of specific business lines in different workspaces still requires more stringent and flexible access control, especially the large and wide tables that have been precipitated, which need to be controlled in the field dimension to prevent improper leakage of sensitive information and ensure the reasonable use of data.
[0003] In traditional role-based access control (RBAC), users are assigned to different roles, each with specific permissions. For example, the administrator role has the highest permissions, while the ordinary user role has more basic permissions. Attribute-based access control (ABAC) determines the permissions of users based on their various attributes (such as position, department, project participation, etc.). For example, employees in a department may be granted access to specific data because of their department attributes. In addition, some existing data access control solutions only focus on table-level or library-level control of data, and manage it by setting user access permissions to the entire data table or database.
[0004] The permission allocation of traditional access control is not flexible and detailed enough. RBAC is not flexible enough when dealing with complex cultural and tourism data scenarios, and it is difficult to make detailed permission allocations based on specific data content and user attributes. In large-scale cultural and tourism data environments, the definition and management of ABAC attributes may become complex and difficult to maintain. At the same time, there is a lack of field-level control. Some existing solutions only focus on table-level or library-level control, and cannot provide targeted protection for sensitive fields, increasing the risk of data leakage. Summary of the invention
[0005] To solve the above problems, the present invention provides a cultural and tourism data access control method, system, terminal and medium, which integrate various permission control models, give full play to the advantages of various permission control models, facilitate administrators to allocate and adjust permissions, realize fine-grained access control at the field level, protect sensitive information to the greatest extent, enable users to quickly obtain required data, and improve work efficiency.
[0006] In a first aspect, the technical solution of the present invention provides a method for controlling access to cultural and tourism data, comprising the following steps: Build a multi-level permission system including workspaces, theme libraries, data tables and fields; Construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, the subject library, the data table, and the field, respectively, to store the workspace access rights of each department, the subject library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity; Receive data access requests from users, obtain access permissions based on user identity information, extract target data based on access permissions and display it to users.
[0007] In an optional implementation, receiving a data access request from a user, obtaining the user's access rights according to the user's identity information, and extracting target data according to the user's access rights to display to the user specifically includes: Step 1, receiving a workspace access request from a user; Step 2, obtaining the department to which the user belongs, and checking whether the user has access rights to the requested workspace according to the first permission table, if not, proceed to step 3, otherwise, allow the user to enter the accessed workspace, and proceed to step 4; Step 3: Detect whether the workspace access permission application procedure is triggered. If so, send the workspace access permission application request to the workspace manager. If not, feedback the access failure to the user. Step 4, receiving a subject library access request from a user; Step 5, obtaining the user group to which the user belongs, and checking whether the user has access rights to the requested theme library according to the second permission table, if not, proceed to step 6, otherwise, allow the user to access the requested theme library, and proceed to step 7; Step 6: Check whether the subject library access permission application procedure is triggered. If so, send the subject library access permission application request to the subject library administrator. If not, feedback the access failure to the user. Step 7, receiving a data table access request from a user; Step 8, obtaining the user identity, and checking whether the user has access rights to the requested data table according to the third permission table. If not, execute step 9; otherwise, allow the user to access the requested data table, and execute step 10; Step 9, detecting whether the data table access permission application procedure is triggered, if so, sending the data table access permission application request to the data table manager, if not, feeding back access failure to the user; Step 10, receiving a field access request from a user; Step 11, obtaining the user identity, and checking whether the user has access rights to the requested field according to the fourth permission table, if not, executing step 12, otherwise displaying the access fields of the requested access data table to the user; Step 12, detect whether the field access permission application procedure is triggered, if so, send the field access permission application request to the field manager, if not, feedback the access failure to the user.
[0008] In an optional implementation, constructing the fourth permission table specifically includes: Step 1, obtain the number and order of fields in the data table; Step 2: construct the field access permission number according to the number and order of fields. The field access permission number contains the number of fields, and the order of the elements is the same as the order of the fields. Step 3, using binary bits to configure a corresponding field access permission number structure according to the user's access permission to the field, including configuring the element bit of the accessible field to 1 and the element bit of the inaccessible field to 0; Step 4: Save the configured field access permission number to the fourth permission table.
[0009] In an optional implementation, the field access permissions are constructed according to the number and order of fields, specifically including: Build the number of field query permissions and field editing permissions based on the number and order of fields.
[0010] In an optional implementation, detecting whether the user has access rights to the requested field according to the fourth permission table specifically includes: Step 1: construct the field request number, which contains the number of field elements, and the order of the elements is the same as the order of the fields; Step 2, using binary bits to configure the field request number according to the field access request, including configuring the element bit of the requested field to 0 and the element bit of the unrequested field to 1; Step 3, obtain the user operation type. If the operation type is query, perform bitwise OR on the field request number and the field query permission number to obtain the permission verification number. If the operation type is edit, perform bitwise OR on the field request number and the field edit permission number to obtain the permission verification number. Step 4: Check whether all elements of the permission check digit are 1; Step 5: If yes, the user has access rights to the requested fields; Step 6: If not, determine whether the field whose element bit is 0 has no access permission.
[0011] In an optional implementation, displaying the access fields of the requested access data table to the user specifically includes: Step 1: Check whether the access field to be displayed is a sensitive field; Step 2: If yes, decrypt the access field and display it; Step 3: If not, the access field is displayed directly.
[0012] In an optional implementation, before receiving a data access request from a user, the following steps are further included: Verify user identity information; If the verification is successful, the user is allowed to make a data access request; If the verification fails, the user is prohibited from making data access requests.
[0013] In a second aspect, the technical solution of the present invention provides a cultural and tourism data access control system, which is implemented based on any of the above methods, and the system includes: Permission system construction module: build a multi-level permission system including workspace, theme library, data table and field; Permission table construction module: construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, subject library, data table, and field, respectively, to store the workspace access rights of each department, the subject library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity; Access request processing module: receives data access requests from users, obtains access rights based on user identity information, extracts target data based on access rights and displays it to users.
[0014] In a third aspect, the technical solution of the present invention provides a terminal, including: A memory, used for storing a cultural and tourism data access control program; A processor is used to implement the steps of the cultural and tourism data access control method as described in any one of the above items when executing the cultural and tourism data access control program.
[0015] In a fourth aspect, the technical solution of the present invention provides a computer-readable storage medium, on which a cultural and tourism data access control program is stored. When the cultural and tourism data access control program is executed by a processor, the steps of the cultural and tourism data access control method as described in any one of the above items are implemented.
[0016] A cultural and tourism data access control method, system, terminal and medium provided by the present invention have the following beneficial effects compared with the prior art: first, a multi-level permission architecture is constructed through multi-level division of workspaces, theme libraries, data tables and fields to achieve refined management and control of cultural and tourism big data and provide an infrastructure for achieving fine-grained access; secondly, permission tables at each level are constructed, various permission control models are integrated, the advantages of various permission control models are fully utilized, the complex and diverse characteristics and access requirements of cultural and tourism data are adapted, and administrators are convenient for permission allocation and adjustment; finally, the field is used as the last level to achieve fine-grained access control at the field level, ensuring that users can only obtain the data required for their work and protecting sensitive information to the greatest extent, so that users can quickly obtain the required data and improve work efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions of the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0018] Figure 1 It is a flow chart of a cultural and tourism data access control method provided by an embodiment of the present invention.
[0019] Figure 2 It is a schematic block diagram of the structure of a cultural and tourism data access control system provided by an embodiment of the present invention.
[0020] Figure 3 It is a schematic diagram of the structure of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0021] In order to enable those skilled in the art to better understand the scheme of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.
[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.
[0023] Figure 1This is a flow chart of a method for controlling access to cultural and tourism data provided by an embodiment of the present invention. Figure 1 The execution subject may be a cultural tourism data access control system. The cultural tourism data access control method provided in the embodiment of the present invention is executed by a computer device, and accordingly, the cultural tourism data access control system runs in the computer device. According to different requirements, the order of the steps in the flowchart can be changed, and some can be omitted.
[0024] like Figure 1 As shown, the method includes the following steps.
[0025] S1, build a multi-level permission system including workspaces, subject libraries, data tables and fields.
[0026] In this embodiment, an innovative multi-level permission architecture is constructed to achieve refined management and control of cultural and tourism big data through multi-level division of workspace, theme library, table and field. This is the basic architecture for achieving fine-grained access. The workspace is the top-level architecture, which is divided according to different business fields or user groups; the theme library is the second-level architecture, corresponding to specific business themes, such as scenic spot visitor analysis, tourism consumption trends, etc.; the data table is the third-level architecture, which is subdivided according to the type and source of data; the field level is the fourth-level architecture, which realizes the most refined permission control and sets specific access rules for each field.
[0027] S2, construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, the theme library, the data table, and the field respectively.
[0028] In this embodiment, permission tables are constructed for each level. The first permission table is used to store the workspace access rights of each department, the second permission table is used to store the subject library access rights of each user group in each department, the third permission table is used to store the data table access rights of each user identity, and the fourth permission table is used to store the access rights of each field in the data table of each user identity.
[0029] The permission configuration of this embodiment combines the RBAC and ABAC models, and introduces policy-based access control (PBAC). PBAC is applied to access control of fields, which will be described in detail in subsequent embodiments. Based on RBAC, role definition and permission allocation are optimized according to the characteristics of cultural and tourism data; in ABAC, user attributes are accurately defined and closely associated with permissions; PBAC is used to formulate complex access policies to adapt to data access requirements in different scenarios.
[0030] S3 receives the data access request from the user, obtains the access permission based on the user's identity information, extracts the target data based on the access permission and displays it to the user.
[0031] In this embodiment, the user sends a data access request, which includes the user identity information and the target data to be accessed. The background matches each permission table according to the user identity information to detect whether the user has access rights. If the user has the permission, the target data is extracted and displayed to the user. The user identity information includes the identity identifier (such as the user name), the department to which they belong, the user group to which they belong, etc.
[0032] This embodiment first constructs a multi-level permission architecture through multi-level division of workspaces, theme libraries, data tables and fields to achieve refined management and control of cultural and tourism big data, and provide an infrastructure for achieving fine-grained access. Secondly, permission tables at each level are constructed, various permission control models are integrated, and the advantages of various permission control models are fully utilized to adapt to the complex and diverse characteristics and access requirements of cultural and tourism data, and to facilitate administrators to allocate and adjust permissions. Finally, fields are used as the last level to implement fine-grained access control at the field level, ensuring that users can only obtain the data they need for their work, protecting sensitive information to the greatest extent, and then users can quickly obtain the required data and improve work efficiency.
[0033] In this embodiment, the background receives data access requests issued by users, obtains access rights based on user identity information, and then extracts target data based on access rights and displays it to users. In this process, users issue access requests layer by layer according to access requirements, and it is determined layer by layer whether users have access rights. The process specifically includes the following steps.
[0034] S4.1, receiving a workspace access request from a user.
[0035] Workspace access request is the first level of access request. It should be noted that when a user logs in to access the platform, the user's legitimacy is checked at login, and the user is allowed to make access requests after passing the check. An optional implementation method is to verify the user's identity information; if the verification passes, the user is allowed to make data access requests; if the verification fails, the user is prohibited from making data access requests.
[0036] Exemplarily, the user identity information includes user name, password, digital certificate, etc. to confirm the legitimacy of the user.
[0037] S4.2, obtain the department to which the user belongs, and detect whether the user has access rights to the requested workspace according to the first permission table. If not, execute S4.3; otherwise, allow the user to enter the accessed workspace and execute S4.4.
[0038] In this embodiment, the workspace to which the user belongs is determined according to the department to which the user belongs. Different workspaces correspond to different business categories and data sets.
[0039] An optional implementation method, the workspace includes a public space and a business space. Under the public space, there will be theme libraries for specific industry directions (such as sports theme libraries, tourism theme libraries, cultural theme libraries, etc.), which are benchmarked against various business units or subsidiaries (such as sports subsidiaries, tourism industry departments, cultural industry departments, etc.). Employees under this organizational structure, if they are development positions, will have query and modification permissions by default. Non-development positions have query permissions by default. Under the business space, there will be theme libraries for specific business directions (such as cableway theme libraries, event theme libraries, museum theme libraries, etc.). All data tables under the theme libraries (such as cableway online order tables, cableway offline order tables) are created by specific employees. After creating the table, the creator can set it on the table management page as the default department has permissions (you can distinguish whether it is defaulted to query or modify), then the creator's department will have the corresponding permissions for the table by default.
[0040] S4.3, detecting whether the workspace access permission application procedure is triggered, if so, sending the workspace access permission application request to the workspace manager, if not, feeding back access failure to the user.
[0041] S4.4, receiving a subject library access request from a user.
[0042] S4.5, obtain the user group to which the user belongs, and detect whether the user has access rights to the requested theme library according to the second permission table. If not, execute S4.6; otherwise, allow the user to enter the requested theme library and execute S4.7.
[0043] S4.6, detect whether the subject library access permission application procedure is triggered, if so, send the subject library access permission application request to the subject library administrator, if not, feedback the access failure to the user.
[0044] S4.7, receiving a data table access request from a user.
[0045] S4.8, obtain the user identity, and detect whether the user has access rights to the requested data table according to the third permission table. If not, execute S4.9; otherwise, allow the user to access the requested data table and execute S4.10.
[0046] S4.9, detect whether the data table access permission application procedure is triggered, if so, send the data table access permission application request to the data table manager, if not, feedback the access failure to the user.
[0047] S4.10, receiving a field access request from a user.
[0048] S4.11, obtain the user identity, and detect whether the user has access rights to the requested field according to the fourth permission table. If not, execute S4.12, otherwise display the access fields of the requested access data table to the user.
[0049] S4.12, detect whether the field access permission application procedure is triggered, if so, send the field access permission application request to the field manager, if not, feedback the access failure to the user.
[0050] In this embodiment, when it is detected that the user does not have access rights, the user is fed back that he does not have access rights and is asked whether to apply for access rights. If access rights need to be applied for, the corresponding access rights application procedure will be triggered, and the application request will be sent to the corresponding management personnel for approval. In an optional implementation method, three types of interfaces are set: permission verification, permission application, and permission approval. Permission verification is a back-end service call, which mainly determines which permissions are required based on SQL and checks whether the current SQL executor has permissions. If there is no permission, the application is automatically triggered. Permission application and permission approval encapsulate the interface provided to the front-end. Permission application mainly records the content of the applicant's application, and pushes it to the reviewer for review to check whether it is automatically reviewed. The review interface mainly grants permissions to applicants and generates corresponding permission records.
[0051] The application information is passed to the corresponding permission management module in turn, triggering a hierarchical review process. Based on the review results of each level, decisions on permission granting are made separately. If the workspace application is approved, the user successfully joins the corresponding workspace. After the subject library application is approved, the user is granted specified permissions in the subject library dimension, such as a specific combination of read, write, modify and other permissions. For permission applications in the table field dimension, if approved, the system accurately grants specific access rights to the user in the corresponding table fields based on established permission policies and rules. After each level of permission granting is completed, the system updates the relevant information in the permission database in real time. At the same time, notifications are sent to users to clearly inform them of the results of each level of permission application, including whether they have successfully joined the workspace, the scope of subject library permissions obtained, and the specific permissions and validity period of the table fields.
[0052] In this embodiment, the management authority of the subject library and downstream data tables and fields under the public space belongs to the department administrator (corresponding to the leader of the organization department by default, and can be transferred to other members within the department). When non-development positions within the department apply for permissions, they must be manually approved by the administrator. When non-department personnel apply for permissions, they must be manually approved by the administrator. Under the business space, the management authority of libraries and tables belongs to the creators of the libraries and tables by default, and the field permissions are inherited from the table creator (that is, employee A with modification permissions modifies the table created by employee B with management permissions, and adds the field item. The management authority of the item field belongs to employee B, not employee A). When an employee applies for permissions, he needs to specify which table and field to apply for permissions (batch application is supported). When multiple tables are involved and belong to different persons in charge, they need to be signed and approved, but the library administrator can also receive the permission approval and can approve the permission application for all tables under the library dimension at one time.
[0053] When the employee applying for permission is the superior of the library / table manager, the approval is automatically passed. When the employee applying for field permission has library dimension permission, the approval is automatically passed (for example, if the employee has library dimension query and applies for table dimension query, the approval is directly passed, but if the employee applies for table dimension modification, the approval is still required). When the employee applying for field permission has permission for all other fields, the approval is automatically passed (the applied field is a newly added field, that is, the table fields are a, b, c, d, and a newly added field e, the employee's original permission value 1111 changes to 11111, but 11110 cannot be automatically applied for approval to 11111).
[0054] In this embodiment, since the authority is controlled to the table field dimension, mapping is configured for the table field, and each field stores the authority of each employee. There will be a large amount of data, and the authority verification is difficult. Therefore, this embodiment uses binary for bit operations during storage and use.
[0055] When constructing the fourth permission table, this embodiment specifically includes the following steps.
[0056] Step 1: Get the number and order of fields in the data table.
[0057] Step 2: Construct a field access permission number based on the number and order of fields. The field access permission number contains the number of field elements, and the order of the elements is the same as the order of the fields.
[0058] Step 3, using binary bits to configure the corresponding field access permission number structure according to the user's access permission to the field, including configuring the element bit of the accessible field to 1 and the element bit of the inaccessible field to 0.
[0059] Step 4: Save the configured field access permission number to the fourth permission table.
[0060] For example, if the data table has abcd fields, and the employee's permission is 1101, it means that the employee has permission to abd fields, but not to c field. The 1101 configured for the employee is the field access permission number, and the number of element bits is the same as the number of data table fields, both of which are 4, and the order of each element bit is the same as the order of the fields. For example, the first bit 1 in 1101 represents the permission to a field, the second bit 1 represents the permission to b field, the third bit 0 represents the permission to c field, and the fourth bit 1 represents the permission to d field.
[0061] In this embodiment, the field access permission number includes the field query permission number and the field editing permission number. Constructing the field access permission number according to the number and order of fields specifically includes constructing the field query permission number and the field editing permission number according to the number and order of fields.
[0062] For example, user A has query permission 11111 and modification permission 11101 for table A. This means that user A has query permission for all fields of table A, modification permission for 4 fields, and no modification permission for 1 field.
[0063] An optional implementation method is to build a Relation table to record the correctness of field permission updates. For example, after adding the e field to the abcd field, it becomes abecd. The original permission 0111 should actually be changed to 01011, not 01110.
[0064] In this embodiment, based on the field access permission number, step S4.11, the fourth permission table detects whether the user has the access permission to the requested field, which specifically includes the following steps.
[0065] S4.11.1, construct a field request number, the field request number contains field number element bits, and the order of the element bits is the same as the field order.
[0066] S4.11.2, using binary bits to configure the number of field requests according to the field access request, including configuring the element bits of the requested field to 0 and the element bits of the unrequested field to 1.
[0067] S4.11.3, obtain the user operation type. If the operation type is query, perform bitwise OR on the number of field requests and the number of field query permissions to obtain the permission verification number. If the operation type is edit, perform bitwise OR on the number of field requests and the number of field edit permissions to obtain the permission verification number.
[0068] S4.11.4, check whether all elements of the permission check digit are 1.
[0069] S4.11.5, If yes, the user has access rights to the requested fields.
[0070] S4.11.6, if not, determine that the field whose element bit is 0 has no access rights.
[0071] For example, if the table has abcd fields, and the employee's permission is 1101, it means that the employee has permission to abd fields, but not c field. When the employee performs SQL operations, if the operation is on a and b fields, the field request number 0011 (a and b field operations, no cd, cd has permission by default) is constructed and bitwise ORed with 1101 (the employee's permission), and 1111 is obtained, and the permission check passes. It is understandable that the corresponding field access permission number is selected according to the user's specific operation type (query or edit).
[0072] In this embodiment, when displaying the access field of the requested access data table to the user, it is also detected whether the access field to be displayed is a sensitive field. If so, the access field is decrypted before display; if not, the access field is directly displayed.
[0073] For non-sensitive fields, this embodiment directly extracts data from the database and returns it to the user. For sensitive fields, decryption is performed first (if the data is stored in encrypted form), and then desensitization is performed according to user permissions. Only the part that the user has the right to view is displayed, and then the processed data is returned to the user. Exemplarily, for data in sensitive fields, advanced encryption algorithms (such as the national encryption algorithm SM4) are used for encrypted storage. When a user accesses the data, real-time decryption or desensitization is performed according to their permissions. Desensitization methods include but are not limited to data hiding, data deformation, data replacement, etc., to ensure the safe display of sensitive data.
[0074] In an optional implementation, regardless of whether the access is successful or not, the system will generate detailed access records, including access time, user information, accessed workspace, subject library, table, field, and operation results (success or failure), etc. During the entire access process, the system also monitors whether there is a need to dynamically adjust user permissions, such as changes in data sensitivity, changes in user responsibilities, etc. If so, the permission adjustment process is triggered and the user's permission information is updated in real time.
[0075] An embodiment of a method for controlling access to cultural and tourism data is described in detail above. Based on the method for controlling access to cultural and tourism data described in the above embodiment, an embodiment of the present invention further provides a method for controlling access to cultural and tourism data corresponding to the method.
[0076] Figure 2 The structure schematic diagram of a cultural and tourism data access control system provided by an embodiment of the present invention is shown in FIG. The cultural and tourism data access control system 200 can be divided into multiple functional modules according to the functions it performs. The module referred to in the present invention refers to a series of computer program segments that can be executed by at least one processor and can complete fixed functions, which are stored in a memory.
[0077] Permission system construction module 210: constructs a multi-level permission system including workspace, theme library, data table and field.
[0078] Permission table construction module 220: constructs the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, the theme library, the data table, and the field, respectively, which are used to store the workspace access rights of each department, the theme library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity.
[0079] Access request processing module 230: receives a data access request from a user, obtains the access permission according to the user's identity information, extracts the target data according to the access permission and displays it to the user.
[0080] The cultural and tourism data access control system of this embodiment is used to implement the aforementioned cultural and tourism data access control method. Therefore, the specific implementation method of the system can be seen in the implementation example part of the cultural and tourism data access control method in the previous text. Therefore, its specific implementation method can refer to the description of the corresponding embodiments of each part, which will not be introduced in detail here.
[0081] In addition, since the cultural and tourism data access control system of this embodiment is used to implement the aforementioned cultural and tourism data access control method, its function corresponds to that of the aforementioned method and will not be repeated here.
[0082] Figure 3 A schematic diagram of the structure of a terminal 300 provided in an embodiment of the present invention includes: a processor 310, a memory 320 and a communication unit 330. The processor 310 is used to implement the following steps when implementing the cultural and tourism data access control program stored in the memory 320: Build a multi-level permission system including workspaces, theme libraries, data tables and fields; Construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, the subject library, the data table, and the field, respectively, to store the workspace access rights of each department, the subject library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity; Receive data access requests from users, obtain access permissions based on user identity information, extract target data based on access permissions and display it to users.
[0083] The present invention also provides a computer storage medium, wherein the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).
[0084] The computer storage medium stores a cultural and tourism data access control program, and when the cultural and tourism data access control program is executed by the processor, the following steps are implemented: Build a multi-level permission system including workspaces, theme libraries, data tables and fields; Construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, the subject library, the data table, and the field, respectively, to store the workspace access rights of each department, the subject library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity; Receive data access requests from users, obtain access permissions based on user identity information, extract target data based on access permissions and display it to users.
[0085] The above disclosure is only a preferred embodiment of the present invention, but the present invention is not limited thereto. Any non-creative changes that can be thought of by a person skilled in the art, as well as several improvements and modifications made without departing from the principle of the present invention, should fall within the protection scope of the present invention.
Claims
1. A method for controlling access to cultural and tourism data, characterized in that: The following steps are involved: Build a multi-level permission system including workspaces, theme libraries, data tables and fields; Construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, the subject library, the data table, and the field, respectively, to store the workspace access rights of each department, the subject library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity; Receive data access requests from users, obtain access permissions based on user identity information, extract target data based on access permissions and display it to users.
2. The cultural and tourism data access control method according to claim 1, characterized in that: Receive data access requests from users, obtain access rights based on user identity information, extract target data based on access rights and display it to users, including: Step 1, receiving a workspace access request from a user; Step 2, obtaining the department to which the user belongs, and checking whether the user has access rights to the requested workspace according to the first permission table, if not, proceed to step 3, otherwise, allow the user to enter the accessed workspace, and proceed to step 4; Step 3: Detect whether the workspace access permission application procedure is triggered. If so, send the workspace access permission application request to the workspace manager. If not, feedback the access failure to the user. Step 4, receiving a subject library access request from a user; Step 5, obtaining the user group to which the user belongs, and checking whether the user has access rights to the requested theme library according to the second permission table, if not, proceed to step 6, otherwise, allow the user to access the requested theme library, and proceed to step 7; Step 6: Check whether the subject library access permission application procedure is triggered. If so, send the subject library access permission application request to the subject library administrator. If not, feedback the access failure to the user. Step 7, receiving a data table access request from a user; Step 8, obtaining the user identity, and checking whether the user has access rights to the requested data table according to the third permission table. If not, execute step 9; otherwise, allow the user to access the requested data table, and execute step 10; Step 9, detecting whether the data table access permission application procedure is triggered, if so, sending the data table access permission application request to the data table manager, if not, feeding back access failure to the user; Step 10, receiving a field access request from a user; Step 11, obtaining the user identity, and checking whether the user has access rights to the requested field according to the fourth permission table, if not, executing step 12, otherwise displaying the access fields of the requested access data table to the user; Step 12, detect whether the field access permission application procedure is triggered, if so, send the field access permission application request to the field manager, if not, feedback the access failure to the user.
3. The cultural and tourism data access control method according to claim 2 is characterized in that: Construct the fourth permission table, including: Step 1, obtain the number and order of fields in the data table; Step 2: construct the field access permission number according to the number and order of fields. The field access permission number contains the number of fields, and the order of the elements is the same as the order of the fields. Step 3, using binary bits to configure a corresponding field access permission number structure according to the user's access permission to the field, including configuring the element bit of the accessible field to 1 and the element bit of the inaccessible field to 0; Step 4: Save the configured field access permission number to the fourth permission table.
4. The cultural and tourism data access control method according to claim 3 is characterized in that: Build field access permissions based on the number and order of fields, including: Build the number of field query permissions and field editing permissions based on the number and order of fields.
5. The cultural and tourism data access control method according to claim 4 is characterized in that: Checking whether the user has access rights to the requested field according to the fourth permission table specifically includes: Step 1: construct the field request number, which contains the number of field elements, and the order of the elements is the same as the order of the fields; Step 2, using binary bits to configure the field request number according to the field access request, including configuring the element bit of the requested field to 0 and the element bit of the unrequested field to 1; Step 3, obtain the user operation type. If the operation type is query, perform bitwise OR on the field request number and the field query permission number to obtain the permission verification number. If the operation type is edit, perform bitwise OR on the field request number and the field edit permission number to obtain the permission verification number. Step 4: Check whether all elements of the permission check digit are 1; Step 5: If yes, the user has access rights to the requested fields; Step 6: If not, determine whether the field whose element bit is 0 has no access permission.
6. The cultural and tourism data access control method according to claim 5 is characterized in that: Display the access fields of the requested data table to the user, including: Step 1: Check whether the access field to be displayed is a sensitive field; Step 2: If yes, decrypt the access field and display it; Step 3: If not, the access field is displayed directly.
7. The method for controlling access to cultural and tourism data according to any one of claims 1 to 6, characterized in that: Before receiving a data access request from a user, the following steps are also included: Verify user identity information; If the verification is successful, the user is allowed to make a data access request; If the verification fails, the user is prohibited from making data access requests.
8. A cultural and tourism data access control system, characterized in that: The method according to any one of claims 1 to 7 is implemented, the system comprising: Permission system construction module: build a multi-level permission system including workspace, theme library, data table and field; Permission table construction module: construct the first permission table, the second permission table, the third permission table, and the fourth permission table for the workspace, subject library, data table, and field, respectively, to store the workspace access rights of each department, the subject library access rights of each user group of each department, the data table access rights of each user identity, and the access rights of each field in the data table of each user identity; Access request processing module: receives data access requests from users, obtains access rights based on user identity information, extracts target data based on access rights and displays it to users.
9. A terminal, characterized in that: include: A memory, used for storing a cultural and tourism data access control program; A processor is used to implement the steps of the cultural and tourism data access control method as described in any one of claims 1-7 when executing the cultural and tourism data access control program.
10. A computer-readable storage medium, characterized in that: The readable storage medium stores a cultural and tourism data access control program, and when the cultural and tourism data access control program is executed by the processor, the steps of the cultural and tourism data access control method as described in any one of claims 1-7 are implemented.