Có thực tiễn tốt để xử lý các lỗi Xác thực/Cấp phép sử dụng ngoại lệ không?

Question

Nếu ứng dụng thấy rằng người dùng không được xác thực/ủy quyền để làm điều gì đó, đó có phải là điều không mong muốn không?

try { 
    if (notAuth()) 
     throw new UnAuthException(); 
} catch (UnAuthException e) { 
    Log . error(e); 
    return false; 
} 

nếu nó được dự kiến ​​trường hợp, vậy tại sao có rất nhiều khuôn khổ có riêng UnAuthException họ nếu thất bại Auth không phải là ngoại lệ?

Answer 1

Phụ thuộc vào phạm vi.

Trong logic kinh doanh lớp "dùng không có quyền/chứng thực" tình hình là ngoại lệ, và sẽ dẫn đến thời gian chạy ngoại lệ, ví dụ (mã Java):

public String salutation(User user) { 
    // may lead to a runtime exception if user is not authorized 
    return String.format("Hello, %s!", user.getName()); 
} 

Thực hiện User (đó là một giao diện , tất nhiên) sẽ trả lại tên của người dùng hoặc ném NonAuthenticatedException trong getName().

Trong kiểm soát truy cập lớp tình trạng sử dụng giấy phép/chứng thực được xử lý như bất kỳ trạng thái bình thường khác, và không nên được coi là trường hợp ngoại lệ, ví dụ:

if (!user.isAuthenticated()) { 
    httpResponse.addHeader("WWW-Authenticate", "Basic realm=\"secure content\""); 
} 

Answer 2

Vâng, đó là một thực hành tốt để xử lý xác thực \ uỷ quyền qua trường hợp ngoại lệ vì:

1) Một ngoại lệ là một tình huống bất thường mà hệ thống không thích và do đó thông qua xử lý ngoại lệ chúng ta đang phản ứng với hoàn cảnh đó . Các trường hợp ngoại lệ xác thực và ủy quyền về cơ bản là các vi phạm về bảo mật, tức là hệ thống bất thường và thực tiễn tốt là phản hồi vi phạm. Khung xử lý ngoại lệ là một cơ chế phổ biến để báo cáo các lỗi bất thường của hệ thống và do đó chúng tôi sử dụng khung này để phản ứng với các tình huống như vậy.

Đó là lý do tại sao tất cả các khung phổ biến (bao gồm .NET) đều có Auth. các lớp ngoại lệ để đóng gói các lỗi .