[Phpmyadmin-devel] Problems with Garvin's Patches

[Garvin Hicking]

Hi Robin!

I just reply to parts of your mail, because other items simply went to my TODO-List.

> One bug to report, on the table create/alter pages the number of data
> fields and the actual fields do NOT line up.

I today fixed that issue, it was because of to conflicting DIFFs.

> Looking at the HTML for that page, I see you are passing filenames for
> the field_transformation variable. Take out the .inc.php3 part and go
> and double check that code for security holes, as it may be susceptible
> to data injection.

I got a grip of that problem on the other side. I don't do any input validation, but
rely on the dropdown-input. Because when evaluation the columns in browse mode,
there's a check to only allow a transformation, if it fits certain rules
(<mimetype>_<subtype>__<transformation>.inc.php3), and only in the
libraries/transformations directory. Because data is passed via a select field I
surely think we could trust user data there. Warning shouldn't be an issue, because
you can only trick false data in by using your own POST/GET-requests, so in this
case the user already knows, he is hacking into our application and may get false
results.
But even if he gets an invalid transform into the table, it simply isn't used in the
output.

Any objections to this approach, which is already coded this way and thereby takes
no coding-time to keep it that way (*broad hint* ;-))

> On that note, please update Documentation for your tranforms...

This is the last point on my TODO-list, but I won't forget that. :)

> Here is an idea for the quickbox, give it three mini-tabs:

Maybe it is a bit complicated to make a three-part query window, so I'll see what
can be done there. Worst thing would be to have input-buttons as TAB-icons instead
of text links, or to rely on javascript for that, again.

> Garvin, a question + suggestion:
> does the SQL history work thru links only?

In reality, this works by javascript and POSTing the data. So, yes. Query history
can and will get tuned to table support.

> behaviour:
> on login and logout or a large number of rows existing, run a query on

How to you get to know, if a user "logs in" or "logs out", without session
management? You mean, everytime a user makes a call to main.php3?

-- 
Bye,
Garvin.