A customer system is the most basic function is to create, modify, delete, and query customers. To achieve such functions, it is usually to build a Customer table in the database and then implements the above basic functions through the program. In a personal environment, a user can operate any of all customers, and there is basically no permission control problem. In multi-user systems, the customer belongs to a person or a group of people, and the operation permission to the customer is not like everyone. So you need to perform permission control over the user's operation.
It is necessary to discuss the permissions control method itself, some system uses the menu to control, such as "New Customer", "Browse Customer", often use the operand to add a resource name representative, such permission control A flaw is generally missed a resource range, such as what kind of customer browsing, has not explained. Of course, you can also add, such as browsing individual customers, browsing department customers, browsing company customers, but as needed to control resource types, it is not a good way to control by increasing menu items. In the menu control in the B / S system, there are 2 heaviness, one is the real menu, no permissions can not see the corresponding menu item, and another in order to prevent the user from submitting information, the server is submitted to the user The URL is checked to see if there is this permission. For example, if the user requested ListCus.do, please check if the user has access to this URL:
Public class ListCusAction Extends action {... public actionforward execute (...) {... // must provide a method of checking. Permitil.checkpermit (UserID, URL); List = DAO.QUERY (SQL); ...}} Another control method is to define permissions to operation and operational resource, such as User A, can modify the customer. Such fine granular permissions control has great advantages to the scalability and security of the procedure, but the implementation is more than the previous fees, and the following is characterized by analyzing the characteristics of two ways.
As the simplest consideration of the customer system, it is the customer to manage your own customers. Under this circumstance, we can know which user corresponds to which user can be found by adding a user field in the Customer table. As shown in the following class:
Public class customer {private string ctmno; ... private string userid; // getters and setters} Then through the menu control method, we believe that users who have access to customers can create their own customers. What is customer creation right, you can see and select the user who adds a customer menu item. At the same time, "customer browsing" means browsing a customer, so that users who create customers can see their customers, and do this, we have completed this demand by menu control. It should be noted that before the user performs the corresponding operation, we first determined that this customer belongs to this user, it is possible to operate, not. As shown in the following example:
Public class delcusaction extends action {... public actionforward execute (...) {... // must provide a method of checking. DAO.CHECKPERMIT (Customer, Userid); DAO.DELETE (CUSTOMER); ...}} Conduct this judgment is for security consideration, especially in the software system of the B / S architecture, you can't prevent customers from providing the server Any submission of information. For example, user a does not use the menu, request "delcus.do?ctmno=no1" to the server, and NO1 belongs to user B. If it is not judged, the customer is deleted. Therefore, the display completion permission control of the control menu item is not complete. Now that we have contacted a more complicated demand, that is, customer transfer, bring customers from one user, assign another user. Based on the above implementation, as long as an interface is added, the user belongs to the user belongs, and the problem is solved. as follows:
Public class changingUseraction extends action {... public actionforward execute (...) {... DAO.CHECKPERMIT (Customer, UserID); // Change the customer's users to NewUserID. Dao.changeuser (Customer, NewUserid); ...}}
Each user can now manage your own customers, or handle customers to others management, the problem solves perfect. Let's consider the actual situation, a customer may be able to be seen by a user, but it is not possible to be modified or deleted. How do we control such permissions, add a menu item - "View Customer", User A can perform this operation, but can not select a menu item - "Modify Customer", we add a menu item for each action. The content we need to control has become more and more. In-depth analysis, it can be found that in fact, the above solution can no longer meet the needs. Two customers We know that one can be seen by the user A, a management issue that cannot be, there is a resource management problem, and there must be an additional program to perform such permissions. We design a resource class:
Public Class CustomerResource {// Customer Number Private String Ctmno; // Operation Type Private String Action; // User Private String UserId; // Setters and getters.} Re-design A resource management class:
Public Class CustomerResourceManager {Private Static List Resources; private static void address {resources.add (resource);} // Loads the corresponding user's customer operation permission from the database. Private Static Void RetrieveResources (String UserID) {...} // Checks whether the appropriate permissions exist in Resources. Private static boolean checkpermit (customerResource permit) {...}} Client Using Categories:
