[wp-trac] [WordPress Trac] #15058: Validate option and transient name lengths

[WordPress Trac]

#15058: Validate option and transient name lengths
----------------------------------------+-----------------------------
 Reporter:  chrisjean                   |       Owner:  (none)
     Type:  enhancement                 |      Status:  new
 Priority:  normal                      |   Milestone:  Future Release
Component:  Options, Meta APIs          |     Version:  3.1
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+-----------------------------

Comment (by dartiss):

 I would like to kick-start some further conversation on this topic,
 particularly around transients (rather than options).

 The reason why I believe that this is now worthy of further discussion is
 that one particular point was missed - the two records created for an
 expiring transient are of different lengths. The prefix for these 2
 records are `_transient_` and `_transient_timeout_`. This means that the
 name for the timeout record is 8 characters less than the primary record
 (and the same for the network equivalents, although their maximum length
 will be 5 characters less). In this case, it's possible for the timeout
 record to be truncated and for the primary record not to be - the result
 is a potentially devastating situation where a non-expiring transient is
 created.

 It's unlikely, though, with 256 characters to play with. But not
 impossible. I would like to see something implemented to protect against
 this - ideally against any truncation happening but, at minimum, to
 protect again the above scenario occurring.

 From what I can tell from the conversation above, no changes have been
 made other than, via another ticket and for another reason, the field that
 the transient name is stored in was expanded from 64 characters to 256
 characters. However, if the transient name is still too long for the field
 then it will "silently fail".

 `set_transient` already returns a boolean response to indicate success of
 the transient being stored - a check of length against the minimum before
 truncation occurs and returning a `false` response would, to me, seem to
 be the most suitable solution. At worse case, if the user code isn't
 checking for this response, it will expect a transient to be stored and,
 when it's not there, will generate a new one - at least the data is fresh
 and I'd like to think this is the better result.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/15058#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform