[Tsheetx-developers] max_post_size issues, actions

[Scott M. <sco...@gm...>]

Hi all,

As discussed in Bug #65 <http://bugs.timesheetng.org/view.php?id=65>, the
simple timesheet form is vulnerable to having "posted" data silently
truncated if the php.ini configuration specifies a small max_post_size.

I've created and borrowed a few lines of code that checks for what that
max_post_size variable is set to, and I'm proposing that if it is too small,
the system should simply refuse to function.

So, I started looking into this because I'm working on improving the simple
form, and while improving it, I've basically doubled the size of the "post"
data.  The problem with attempting to anticipate how large things COULD get
is the text descriptions of the work being done.  Since http textarea can
hold a theoretically infinite amount of data, and mysql allows us to store
64K for our descriptions, this would makes things difficult if we don't take
some leeway and use some more reasonable limits.

So, typing in the longest semi-reasonable description I could come up with
was around 150 characters; I entered two of these lines, and a third with a
somewhat shorter description, and the post size ended up being around 3000
bytes.  So, if we use that as an upper limit to the amount of data any
single line of entry on the simple form, and we want to ensure that people
can enter a minimum of 10 lines of data, this comes out to just a bit under
32K of data.

Therefore, I'm proposing the addition of the max_post_size check within the
initial page setup stuff, and if the number returned is less than 32K, an
error message is spit out.  I would also like to recommend within that error
message that the max_post_size be set to no less than 64K.  PHP's
"out-of-the-box" setting is 8 Megabytes, or 128 times larger than 64K.
There are anecdotal tales of system admins changing this variable to a mere
8K, which would limit the number of entries to around 10 with no
descriptions.

-Scott