Different classes of validation failures

Đang mở
  • Có gì không ổn?
#253 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
javascript
Lĩnh vực
authentication, backend

Hướng nghiên cứu

Issue tập trung vào validation handler và tùy chọn clearInvalid; trước tiên hãy lần theo cách các lỗi validate được phân loại và xem xét các test mới được đề cập trong #252. Hoàn thành có nghĩa là các lỗi credential-invalid có thể xóa trạng thái, trong khi các lỗi xác thực nội bộ tạm thời giữ nguyên trạng thái và trả về phản hồi 500, còn các lỗi policy được xử lý riêng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

support

Opening a new issue since the described issue is broader than the one that was reported.

I think the behavior discussed in this thread is the cause of a more general problem that I have seen.

In our validate function, we run a database query to see if the user still exists, as is recommended in the docs. Most of the time, it works fine. However, if there's a connection failure to the database, the database client throws an error, and errors in validate seem to log the user out no matter what.

I don't think it makes sense to log the user out just because the backend can't contact the database. Probably a 500 error should be returned, with the user still logged in so they can try again.

Originally posted by @sholladay in #245

The current validation handler assumes any error is caused by invalid credentials. Given that it is indeed common to need an external call to perform the validation, another class of validation errors are (temporary) internal validation errors. A third class (from #245) are policy errors, though these should generally be generated after validation. These errors should ideally be handled separately to avoid clearing, what could still be valid, credentials and return a code 500 or similar.

Not clearing the state on these kind of errors could probably be handled as a bug fix. Eg. by only clearing the cookie on a Boom.unauthorized() error.

Ideally, the original error would be returned as well, as suggested in #245. This could also be argued as a non-breaking change, especially if non-Boom errors are still treated as Boom.unauthorized().

It should be noted that system errors (like TypeError) already don't clear the cookie, and return a code 500 response (as demonstrated in my new tests from #252.

@sholladay FYI, your specific clearing issue can be mitigated by not using the clearInvalid option.

Ngôn ngữ chính
JavaScript
Star
229
Fork
99
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của hapijs/cookie

Tất cả issue của hapijs/cookie

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.