Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#19,916 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
15/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
php, redis
Ambito
authorization, backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
PHP
Stelle
3.6k
Fork
706
Merge medio
10h 12m
PR unite (30g)
256

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di craftcms/cms

Tutte le issue di craftcms/cms

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.