如何限制仅ADMIN类型用户可调用UserDao的删除用户方法？

Absolutely, there are several solid, practical ways to make sure only ADMIN users can call that delete method. Let's walk through the most common approaches, with code examples tailored to your setup:

1. Direct Permission Check in the DAO Method #

This is the simplest, most straightforward approach for small-scale scenarios. You’ll add a check directly inside your deleteUser method to verify the current user’s type before executing the database operation.

First, here’s your User class with the enum:

public class User {
    public enum UserType {
        ADMIN, REGULAR_USER, GUEST
    }

    private Long id;
    private UserType type;
    // Getters and setters
}

Then update your UserDao to include the check:

public class UserDao {
    // Helper method to fetch the currently logged-in user (adjust based on your app's context)
    private User getCurrentAuthenticatedUser() {
        // Example: Pull from a ThreadLocal context or request scope
        return UserSessionContext.getCurrentUser();
    }

    public void deleteUser(Long userId) {
        User currentUser = getCurrentAuthenticatedUser();
        
        // Validate user type
        if (currentUser == null || !User.UserType.ADMIN.equals(currentUser.getType())) {
            throw new SecurityException("Access denied: Only ADMIN users can delete users");
        }

        // Execute actual database delete logic
        // jdbcTemplate.update("DELETE FROM users WHERE id = ?", userId);
    }
}

Pros: No extra dependencies, easy to implement.
Cons: Couples permission logic with DAO business logic; repetitive if you need this check across multiple methods.

2. Use Custom Annotations + AOP (Aspect-Oriented Programming) #

For cleaner, reusable code (especially if multiple methods need admin checks), use AOP to decouple permission validation from your DAO logic.

Step 1: Create a custom annotation #

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface AdminOnly {
    // No extra attributes needed for basic checks
}

Step 2: Implement an AOP aspect #

@Component
@Aspect
public class PermissionValidationAspect {
    @Autowired
    private UserSessionContext userSessionContext;

    // Run this check before any method annotated with @AdminOnly
    @Before("@annotation(com.yourpackage.AdminOnly)")
    public void enforceAdminPermission() {
        User currentUser = userSessionContext.getCurrentUser();
        
        if (currentUser == null || !User.UserType.ADMIN.equals(currentUser.getType())) {
            throw new SecurityException("Only ADMIN users are authorized for this action");
        }
    }
}

Step 3: Annotate your DAO method #

public class UserDao {
    @AdminOnly
    public void deleteUser(Long userId) {
        // Just your database delete logic here—validation is handled by the aspect
        // jdbcTemplate.update("DELETE FROM users WHERE id = ?", userId);
    }
}

Pros: Clean separation of concerns; reuse the annotation across any method that needs admin access.
Cons: Requires familiarity with AOP; adds minor complexity if your project doesn’t already use Spring (or another AOP framework).

3. Leverage Framework-Level Security (e.g., Spring Security) #

If you’re using Spring, take advantage of its built-in security annotations to handle permission checks with minimal code.

First, ensure your user’s UserType is mapped to Spring Security authorities/roles (e.g., in your UserDetailsService). Then annotate your DAO method:

public class UserDao {
    // Use hasAuthority if you mapped ADMIN directly, or hasRole if using a "ROLE_ADMIN" prefix
    @PreAuthorize("hasAuthority('ADMIN')")
    public void deleteUser(Long userId) {
        // Database delete logic
    }
}

Pros: Integrates seamlessly with Spring’s security ecosystem; handles edge cases like unauthenticated users automatically.
Cons: Ties you to Spring Security; overkill if your project doesn’t already use this framework.

4. Validate in the Service Layer #

If you prefer to keep your DAO layer purely focused on database operations, move the permission check to the service layer that calls the DAO:

public class UserService {
    @Autowired
    private UserDao userDao;
    @Autowired
    private UserSessionContext userSessionContext;

    public void deleteUser(Long userId) {
        User currentUser = userSessionContext.getCurrentUser();
        
        if (currentUser == null || !User.UserType.ADMIN.equals(currentUser.getType())) {
            throw new SecurityException("Only ADMIN users can delete users");
        }

        userDao.deleteUser(userId);
    }
}

Pros: Keeps DAO layer clean; centralizes business logic in the service layer.
Cons: Requires ensuring no other code bypasses the service layer to call the DAO directly (use package-level access or internal modules to enforce this).

内容的提问来源于stack exchange，提问作者Jesse James