Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#19,916 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
15/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
php, redis
Domain
authorization, backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
PHP
Stars
3.6k
Forks
706
Avg merge
10h 12m
Merged PRs (30d)
256

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from craftcms/cms

All issues in craftcms/cms

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.