Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[5.x]: Session authorizations get lost with `yii\redis\Session`: "View" on a disabled element answers 403, then "Invalid token"

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

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
15/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php, redis
Lĩnh vực
authorization, backend

Hướng nghiên cứu

Start with Session::authorize() called from ElementsController (around line 363) and SessionBehavior::authorize()/deauthorize(), which append to session data read when the session opened. Then read PreviewController::actionCreateToken() and createPreviewLink() in the element editor JS. Reproduce with the two overlapping curl requests in the issue, then check that B's authorization survives A's later session write.

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

Mô tả

bug repo:cms
What happened?

Description

With sessions on yii\redis\Session (the Redis example in the docs), a session authorization granted by one request is lost when another request of the same session was already running and finishes later. In the control panel it shows like this:

  1. Open the edit page of an element that is not live and click View: preview/create-token answers 403 "User is not authorized to perform this action" (requireAuthorization('previewElement:<id>')).
  2. Click View again: the link now goes straight to the site with the pre-generated token, which was never saved, so the site answers 400 "Invalid token".

Cause, as far as I can tell:

  • The edit page grants previewElement:<id> (or previewDraft:, previewRevision:) through Session::authorize() (ElementsController, around line 363 in 5.11.5).
  • SessionBehavior::authorize() takes the authAccess mutex, but appends to the session data that was read when the session was opened. yii\redis\Session does not lock and writes the whole session at the end of the request.
  • Request A reads the session. Request B (the edit page) grants its authorization and finishes. Then A finishes and writes its older copy, and B's authorization is gone. The mutex does not cover A's read and write.
  • The second symptom comes from createPreviewLink() in the element editor JS. Its click handler calls activatePreviewToken() 1 ms after the click, whether or not preview/create-token succeeded, and rewrites the View links to the tokenized URL.

The other session authorizations go through the same method (editStructure:, reorderNestedElements::, saveAssets:, graphql-schema:), so I would expect them to be affected in the same way. I have not tested those.

Steps to reproduce

  1. Configure the session component with yii\redis\Session as in https://craftcms.com/docs/5.x/reference/config/app.html#session
  2. Log in to the control panel and keep the session cookie (jar.txt). Pick two elements with preview targets whose edit pages this session has not opened yet: A with the slower edit page, B with the faster one.
  3. Load both edit pages so that A starts first and ends last:
curl -s -b jar.txt -o /dev/null "$CP/<edit page of A>" &
sleep 0.05
curl -s -b jar.txt -o b.html "$CP/<edit page of B>"
wait
  1. Take elementType, canonicalId, siteId and hashedPreviewToken from the element editor settings in b.html and request B's View link:
curl -s -b jar.txt -o /dev/null -w '%{http_code}\n' \
  "$CP/actions/preview/create-token?elementType=<type>&canonicalId=<B>&siteId=<site>&previewToken=<hashedPreviewToken>&redirect=<url>"

Expected behavior

302 to the redirect URL, and the token is saved.

Actual behavior

403, in 3 of 3 runs. Without the request for A in step 3 it answers 302. Authorizations pile up in the session, so B has to be an element the session has not opened before; otherwise A's older copy already holds B's key.

I reproduced it with Commerce product edit pages. The code path is ElementsController, so I expect entries to behave the same. In production, editors hit it in the browser when edit pages or background requests of one session overlap.

Possible fixes

  • In PreviewController::actionCreateToken(), check the user's permission to view the element instead of, or in addition to, the session authorization.
  • In authorize() and deauthorize(), read the stored value again inside the lock and write it right away, or keep the authorizations in a store with atomic updates.
  • In the element editor JS, activate the preview token only after preview/create-token succeeded.
  • Mention in the docs that yii\redis\Session does not lock sessions.

Related: #5488 (same 403, closed in 2020 as a hosting session setup).

Craft CMS version

5.11.5

PHP version

8.4

Operating system and version

Linux (DDEV locally, Servd in production)

Database type and version

MySQL 8

Image driver and version

No response

Installed plugins and versions

Craft Commerce 5.7.6 (its product edit pages are what I used for the repro), yiisoft/yii2-redis 2.0.20

Ngôn ngữ chính
PHP
Star
3.6k
Fork
706
Merge trung bình
12 giờ 30 phút
Pull request đã merge (30 ngày)
274

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 craftcms/cms

Tất cả issue của craftcms/cms

Issue tương tự

Thêm issue về PHP

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.