[RESOLVED] Passing SQL through POST: wise?

void_function

Hi!

I have a table with 16 columns and a search page which can take any number of those 16 columns (fields) as input. Given the enormous amount of records to be stored, I will have to spread the results through many pages.

Now, all that changes among those pages are page number (dealt with LIMIT n, rows) and ORDER BY.

Do I need to pass each and every field into the script that reselects the page, or can I store a hidden input type with formatted SQL query, minus the LIMIT and ORDER BY clauses?

For example:

1: "SELECT * FROM the_table WHERE this=that AND some_column=value AND [up to 16 conditions]"

plus

2: " LIMIT n, row ORDER BY sortcolumn"

Now, can store the query in #1 in a hidden input form field and have the page selector script only append proper LIMIT and ORDER BY?

The columns in question hold no secret info, like passwords. Even if there were any passwords, those would be one-way encrypted. This is an intranet application. Evenso, I'd like to encrypt this SQL query, simply for the reasons not to reveal table and column names to unauthorized personell (which they could see by viewing the page source). So, my questions are:

Is this wise? To pass encrypted formatted SQL query through hidden input form field?
Which two-way encryption algorithm you would suggest?

Please note that I think this is the easiest thing to do, script-wise (yeah, I'm a lazy ass). I will have a search.php that takes the input and formats the SQL, routing to show.php that would then take only the encrypted SQL as input. I know I could do this with a separate table and store latest SQL per user, but for certain reasons, I wish to avoid that. Also, I wish to avoid using $_GET.

Thank you!

mrhappiness

why not passing the criteria the user defined and creating the statement every time?

leatherback

void_function wrote:
1. Is this wise? To pass encrypted formatted SQL query through hidden input form field?

No.
Imagine a person trying to get acces to your page. He submits his own little query to your database. And since you already expect the string to be sql, you suspect nothing, and he sneecks in, and meets your system setup. Even if you encrypt it, you are adding unneeded trouble to your system.

As mentioned by mr happiness: Just pass the query parameters. Since you already have the code to create the query from that, it is not so much extra coding.

void_function

Avoiding the processing of variables in more than one script? And the script taking the input can't be the one showing the output. I have my reasons for this. 🙂

mrhappiness

void_function wrote:
Avoiding the processing of variables in more than one script?[/b]

[man]include[/man], function create_sql_select()

ethe script taking the input can't be the one showing the output. I have my reasons for this. 🙂

wanna tell us?

void_function

leatherback wrote:
No.
Imagine a person trying to get acces to your page. He submits his own little query to your database. And since you already expect the string to be sql, you suspect nothing, and he sneecks in, and meets your system setup.
(...)

Well, I thought of that. The "SELECT FROM the_table" would be added to the query in the show script, not passed via POST. So a "DROP database" for example would be prepended with "SELECT FROM the_table" and appended with LIMIT and ORDER BY, something I figure would render an invalid query.

But I hear you. It seems this is not as wise as I thought it would be. Ah, well, multiple scripts edit each time they come up with some new column or table...

void_function

mrhappiness wrote:
[man]include[/man], function create_sql_select()

wanna tell us?

Heh, I can't. That would be breach of NDA, but let's say it involves distributed, compartmentalized development. :o

But if mrhappiness, whose oppinion I respect a lot, says don't do it then I won't do it. Thread resolved 🙂