Loading...
 
Skip to main content

Finishing a WYSIWYG edit using WYSIWYG plugin (may) leave(s) page locked with Session storage location set to Database

Status
Open
Subject
Finishing a WYSIWYG edit using WYSIWYG plugin (may) leave(s) page locked with Session storage location set to Database
Version
18.x
Category
  • Bug
Feature
WYSIWYG (What You See is What You Get)
Resolution status
New
Submitted by
Philippe Cloutier
Lastmod by
Philippe Cloutier
Rating
(0)
Description

Editing a WYSIWYG section in a page may leave the semaphore on the page after saving or cancelling the edit, due to a session bug exposed. This can be worked around by waiting the lock's expiration, or by editing the full page and using Cancel Edit.

The bug seems to occur only when session_storage is set to Database. File-based storage apparently does not trigger. When 2 concurrent AJAX requests are processed, changes to the session made by the first can be lost by the second request. Presumably, this is only true because the first request completes after the second one starts but before it ends.

The scenario where the WYSIWYG plugin exposes is that initiating an edit causes 3 AJAX calls to SemaphoreController:

  1. one to is_set
  2. one to set
  3. one to tohtml


Request 2 modifies $_SESSION to add a key storing a UNIX timestamp (on the pre-last line of action_set()). On a wiki page named "TestWYSIWYGPluginNoHTML", that key would be 'semaphore_TestWYSIWYGPluginNoHTML_ wiki_page'.

When cancelling (for instance), 2 requests are made. The problematic one is the call to unset. The call to $this->table->delete() in unset() fails because $lock is empty. $lock is empty because $_SESSION[$this->getSessionId($input)] evaluates to null.

This affects revision 65380 of trunk.

Importance
8
Easy to solve?
2
Priority
16
Demonstrate Bug on Tiki 19+
Demonstrate Bug (older Tiki versions)
Ticket ID
6558
Created
Tuesday 30 January, 2018 20:42:41 UTC
by Philippe Cloutier
LastModif
Tuesday 30 January, 2018 20:46:41 UTC


Show PHP error messages