[wp-trac] [WordPress Trac] #58903: set_transient() allows invalid transient name

[WordPress Trac]

#58903: set_transient() allows invalid transient name
--------------------------------------+---------------------
 Reporter:  jeremyescott              |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  6.4
Component:  Options, Meta APIs        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by jeremyescott):

 Hi Felix. Thanks for the review. Super fun to go from meeting at WCUS'22
 and hanging at the same table for contributor day to now having you read
 my code. haha.

 > The only thing that I'm less sure about is how to deal with the 172
 character limit. Is this because of the database column type and its
 limitations? If so, I think this particular restriction would be better to
 discuss separately for whether we want to enforce it at the code level or
 not, because it applies in several different areas as well. For example,
 options would be subject to such a limit too, but I don't think the code
 enforces that. So I think that particular point would be better to
 discuss/explore separately from this ticket.

 In preparing a response I originally felt indifferent to removing or
 keeping the 172 char check, but I now actually want to encourage it stay.

 My original thought process was that since I was stepping in to add input
 validation and testing to set_transient() to prevent the problem I
 encountered, I may as well add validators for all the conditions listed in
 the docblock at one time.

 > Is this because of the database column type and its limitations?

 I figured the DB was the limit, but I did not see the 191 char limit in
 the `add_option()` function and saw no mention/documentation.

 So, I found the current (and I assume, longstanding) DB schema declares
 varchar(191) on option.name so if '_transient_timeout_' is 19 characters
 191-19 = 172 and thus the transient limit.

 Assuming WP is not using strict SQL, the DB will should simply truncate a
 too-long name. And this is why we should enforce the transient limit while
 not modifying the option name limit. Since transients are simply options
 with a prefix, and since two records are made for each transient...

 Hypothetically we create a 173 character transient. WordPress makes two
 add_option calls:

 _transient_timeout_173chars
 _transient_173chars

 The first record for the two-part transient will be truncated to 191
 chars, dropping the 173rd character in the name, however the second
 record, since the prefix is 8 characters less, will not exceed the db
 varchar(191) limit and not be truncated. The result is the two parts of
 our transient have mismatched names and will not work. Ensuring a 172 char
 limit on a transient makes sure they both match and function as intended.

 With that research, I actually favor keeping the 172 char check and I
 don't think we need to perform any checks on add_option() unless we want
 to.

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