CompositeContentGuard should return a 401 authentication challenge when a sub-guard requires authentication
Maintainer thường phản hồi trong vòng 1 ngày
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
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- api, authentication, backend
Hướng nghiên cứu
Read pulpcore/app/models/publication.py and pulpcore/content/handler.py, then inspect the content guard and handler tests for permission failures and cached authentication. Implement the configurable authentication challenge across composite guards and the handler. Done means missing authentication returns 401 with WWW-Authenticate, authorization denial remains 403, and an allowed sub-guard still permits access.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
CompositeContentGuard.permit() evaluates its sub-guards with OR semantics: the first guard that passes permits the request, and if all guards fail it raises a single PermissionError. The content app handler translates that PermissionError into an HTTP 403 Forbidden.
This conflates two distinct situations:
- Authorization denied — the request has an identity, but that identity is not allowed.
403 Forbiddenis correct. - Authentication missing — the request carried no identity at all. The correct HTTP response is 401 Unauthorized with a
WWW-Authenticatechallenge, so the client knows it should authenticate and retry.
Because CompositeContentGuard only knows about PermissionError, a request that fails purely for lack of authentication still gets a flat 403. A client (e.g. a package manager, or a browser behind basic auth) never receives the WWW-Authenticate challenge and has no signal to supply credentials.
Current behavior
pulpcore/app/models/publication.py — CompositeContentGuard.permit():
for guard in self.guards.all():
detail_guard = guard.cast()
try:
detail_guard.permit(request)
return # success on first-pass
except PermissionError as pe:
errors.append(...)
# If we get here - FAIL
raise PermissionError(_("Access forbidden. Refusals: {}").format(errors))
pulpcore/content/handler.py — _permit() maps any PermissionError to HTTPForbidden (403). There is no path that produces a 401 with a WWW-Authenticate header.
Proposed behavior
- Introduce (or adopt) a distinct exception that a content guard can raise to mean "authentication required" rather than "forbidden" — e.g. an
AuthenticationErrorseparate fromPermissionError. - In
CompositeContentGuard.permit(), track whether any sub-guard raised the authentication-required error. If no guard passes and at least one raised authentication-required, re-raise that authentication error instead of the genericPermissionError. (Authorization denials still collapse toPermissionError→ 403.) - In the content handler's
_permit(), translate the authentication-required error intoHTTPUnauthorized(401) with aWWW-Authenticatechallenge header. Also update the cached-auth path so a 401 is handled like a 403 (not cached as a pass).
This preserves the OR semantics: if any guard permits, access is granted; a 401 is only returned when the sole reason for failure is missing authentication.
Reference implementation
pulp-service already carries this as a downstream patch and it works in production for packages.redhat.com:
The patch:
- Catches a new
AuthenticationErrorinCompositeContentGuard.permit(), remembers the first one, and re-raises it after the loop if no guard passed. - Catches
AuthenticationErrorinhandler._permit()and raisesHTTPUnauthorizedwithWWW-Authenticate: Basic realm="packages.redhat.com". - Updates
auth_cached()to treatHTTPUnauthorizedlikeHTTPForbiddenand to avoid caching when the guard result is indeterminate.
Upstreaming this would require a general mechanism (the realm / challenge value should be configurable rather than hard-coded), but the core behavior — a composite guard surfacing an authentication challenge instead of a blanket 403 — belongs in pulpcore.
- Ngôn ngữ chính
- Python
- Star
- 619
- Fork
- 176
- Merge trung bình
- 16 giờ 51 phút
- Pull request đã merge (30 ngày)
- 117
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pulp/pulpcore
-
Reclaim Space Server ErrorĐang mởIssue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
pulp/pulpcore#5802 · 10 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Issue
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Content app answers 404 instead of 502 when the remote of on-demand content is unavailableCó thể đã có người làm @gigi206 đã nhận 14 ngày trước. Đang mở
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 66/100
pulp/pulpcore#8217 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Issue
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 28/100
pulp/pulpcore#8214 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của pulp/pulpcore
Issue tương tự
-
bug P1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Toloka/tolokaforge#1947 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SageMaker provider: streaming fails with NoStreamDataError on DJL Serving (LMI) endpointsCó thể đã có người làm @balajiaru đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
UKGovernmentBEIS/inspect_ai#6127 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
pydot/pydot#601 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
letsencrypt/cp-cps#361 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100