Newbie question, Which way is best?

Hi,

I have a script that contains a form and a pagination routine that calls
itself. I want to pass an sql query along with some other variables to the
called script. The code to acheive this, using the form, is working but when
I try to write the code, using the scripts URL to call itself, I am having
problems successfully passing the SQL query string within the url.

The form is used to construct a string containing a sql query. Whereas when
the pagination calls the script all it does is changes the LIMIT part of the
sql query. I know it won't pass the original query unless I add it to the
URL address.

Is there a 'proper' way to write this code? Should I add the query to the
URL or is there a better way?

TIA
George

On Wed, Mar 19, 2008 at 3:47 PM, George J <georgejamieson@btconnect.com> wrote:
> Hi,
>
> I have a script that contains a form and a pagination routine that calls
> itself. I want to pass an sql query along with some other variables to the
> called script. The code to acheive this, using the form, is working but when
> I try to write the code, using the scripts URL to call itself, I am having
> problems successfully passing the SQL query string within the url.

WHOA! Passing the SQL query via a URL is a Very Bad Idea[tm]!

Show some code so that we can all see more about what you're
trying to do. Maybe I'm misunderstanding your question.

--
</Daniel P. Brown>
Forensic Services, Senior Unix Engineer
1+ (570-) 362-0283

On Wed, Mar 19, 2008 at 3:47 PM, George J <georgejamieson@btconnect.com> wrote:
> Hi,
>
> I have a script that contains a form and a pagination routine that calls
> itself. I want to pass an sql query along with some other variables to the
> called script. The code to acheive this, using the form, is working but when
> I try to write the code, using the scripts URL to call itself, I am having
> problems successfully passing the SQL query string within the url.
>
> The form is used to construct a string containing a sql query. Whereas when
> the pagination calls the script all it does is changes the LIMIT part of the
> sql query. I know it won't pass the original query unless I add it to the
> URL address.
>
> Is there a 'proper' way to write this code? Should I add the query to the
> URL or is there a better way?
>
> TIA
> George

My personal preference is to add all of the query parameters as hidden
fields in your form and pass them along from page to page. I wouldn't
send the actual SQL query (or any part of it) as part of the URL.

Andrew

Hi Daniel,

> WHOA! Passing the SQL query via a URL is a Very Bad Idea[tm]!

As a newbie I just have to ask why. I suspect you're going to say it gives
the table and field names used in my database. I'm not really aware of all
the possible avenues that this method might open up. It just feels wrong to
include these details. This is the reason I've asked for help.

The form part of the script works fine so can we ignore that or does it
impact on the pagination code that I'm having trouble with.

When the form calls the script it passes all the parameters that the script
uses to construct a SELECT query. This works fine.

When the pagination calls the script it passes a new page number. This works
fine but is where my limited experience lets me down. I need to pass the
SELECT query, as is, back to the same script with a way to change just the
LIMIT part of the query. Changing the LIMIT parameters simple lets me
display another page of the returned query. I can do this change prior to
call but what options have I on including the query in my call. Could I
camouflage the query parameters in an array for example?

George

On Wed, Mar 19, 2008 at 4:45 PM, George J <georgejamieson@btconnect.com> wrote:
> Hi Daniel,
>
>
> > WHOA! Passing the SQL query via a URL is a Very Bad Idea[tm]!
>
> As a newbie I just have to ask why. I suspect you're going to say it gives
> the table and field names used in my database. I'm not really aware of all
> the possible avenues that this method might open up. It just feels wrong to
> include these details. This is the reason I've asked for help.

That's exactly what you should be doing, George. That's how you learn! ;-)

Not only are you giving away the schema of your database, but it
makes it that much easier to do VERY nasty things. For example, say
you access the file like so:

http://www.domain.com/path/script.ph...MIT%2020,%2030

I could change it to something like this:

http://www.domain.com/path/script.ph...LE%20WHERE%201

And your database table is gone.

> The form part of the script works fine so can we ignore that or does it
> impact on the pagination code that I'm having trouble with.

As long as you sanitize anything sent to the database, I'm sure
it's fine. Check out mysql_real_escape_string() for more on that:
http://php.net/mysql-real-escape-string

NOTE: If you're using mysqli, you don't need to add
mysql_real_escape_string() because it's already handled automatically.

--
</Daniel P. Brown>
Forensic Services, Senior Unix Engineer
1+ (570-) 362-0283

On Mar 19, 2008, at 4:45 PM, George J wrote:

> Hi Daniel,
>
>> WHOA! Passing the SQL query via a URL is a Very Bad Idea[tm]!
>
> As a newbie I just have to ask why. I suspect you're going to say it
> gives
> the table and field names used in my database. I'm not really aware
> of all
> the possible avenues that this method might open up. It just feels
> wrong to
> include these details. This is the reason I've asked for help.
>
> The form part of the script works fine so can we ignore that or does
> it
> impact on the pagination code that I'm having trouble with.
>
> When the form calls the script it passes all the parameters that the
> script
> uses to construct a SELECT query. This works fine.
>
> When the pagination calls the script it passes a new page number.
> This works
> fine but is where my limited experience lets me down. I need to pass
> the
> SELECT query, as is, back to the same script with a way to change
> just the
> LIMIT part of the query. Changing the LIMIT parameters simple lets me
> display another page of the returned query. I can do this change
> prior to
> call but what options have I on including the query in my call.
> Could I
> camouflage the query parameters in an array for example?
>

Hi George,

As a relative newbie my self I think I understand what you are trying
to do.

The reason Dan asked for the code though is because when you show the
code we can easily point out what/where the issue is. If potental
attackers have access to your field names they can much easier try and
insert stuff into your database.

What I would probably do though is something along the lines of this:

//Always escape your data to make it a little harder on the hackers
$par1 = mysql_real_escape($_POST['parameter1']);
$par2 = mysql_real_escape($_POST['parameter2']);

$sql = "SELECT * from tablename where parameter1=".$par1." AND
parameter2=".$par2"": etc etc etc...

There is more to this, but this should get you started.

that way you can run the script calling the variables which were
POSTed instead of GETed so they won't be passed in the URL. It also
has the benefit of not revealing your field names.

Now all of that was typed from memory so please do check to make sure
it makes sense why it's working.

JP

Hi Jason,

Hope this helps -
my 'display_products.php' script
----------
<form method='post' action='display_products.php'>
....
<input type='hidden' name= 'query' value=$query>
<input type='submit' Value='Go'></td>
....
// pagination routine
conditional code...
}else{
echo("<a href=\"display_products.php?page=$i\"><img src=$st border=\"0\"
></a> ");
}
-----------

So calling the script via the form works i.e it passes the neccessary
variables to constrct the sql query for the next call. If the user clicks
one of the pagination links, that calls itself, all that is passed is the
page=$i variable. I need to include the 'SELECT * FROM...' query either as a
string or an array of seperate values for the changed query.

So, as I see it, the pagination links won't POST the form variables. How do
I pass the 'SELECT * FROM mytable WHERE selection=option LIMIT start, range'
query
to the called script?

George

De: George J [mailto:georgejamieson@btconnect.com]

> So calling the script via the form works i.e it passes the
> neccessary variables to constrct the sql query for the next
> call.

As Shawn said, if you really need the query again add it to session, never,
NEVER give the user the ability to see/execute queries by himself (remember
POST data could be easily manipulated). Remember what Daniel said, adding a
DELETE FROM is not hard and veeery bad.

> If the user clicks one of the pagination links, that
> calls itself, all that is passed is the page=$i variable. I
> need to include the 'SELECT * FROM...' query either as a string
> or an array of seperate values for the changed query.

Ok, let me ask you something. Why post to itself? You could have a script
only to do form actions, that way you can:
1 Separate huge php validations with your html form.
2 Use functions to handle the incoming data and writing the new query (or
the old one again).

As it's built at server side, the user is never going to see your query or
[1]manipulate it as you're writing it all over again, just using your old
parameters (they could be added as hidden fields in the form if strictly
necessary).


> So, as I see it, the pagination links won't POST the form
> variables. How do I pass the 'SELECT * FROM mytable WHERE
> selection=option LIMIT start, range'
> query to the called script?

You should try building a default query where you only add the parameters
given by the user. If you can't seem to recover that, add them to $_SESSION
and you'll be fine next time you want them (if you don't overwrite it =] ).

> George
Welcome and keep asking :)


[1] As long as you treat the user input properly, as other said.




--
PHP General Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php

On Mar 19, 2008, at 5:13 PM, George J wrote:
> Hi Jason,
>
> Hope this helps -
> my 'display_products.php' script
> ----------
> <form method='post' action='display_products.php'>
> ...
> <input type='hidden' name= 'query' value=$query>
> <input type='submit' Value='Go'></td>
> ...
> // pagination routine
> conditional code...
> }else{
> echo("<a href=\"display_products.php?page=$i\"><img src=$st border=
> \"0\"
>> </a> ");
> }
> -----------
>
> So calling the script via the form works i.e it passes the neccessary
> variables to constrct the sql query for the next call. If the user
> clicks
> one of the pagination links, that calls itself, all that is passed
> is the
> page=$i variable. I need to include the 'SELECT * FROM...' query
> either as a
> string or an array of seperate values for the changed query.
>
> So, as I see it, the pagination links won't POST the form variables.
> How do
> I pass the 'SELECT * FROM mytable WHERE selection=option LIMIT
> start, range'
> query
> to the called script?
>
> George

I don't know if anyone has answered the question you have asked at
least twice... "How do I pass the query to the next page?" Here's how
I would approach it. Don't pass the query - all you need is the page
number. This code hasn't been tested, but I think you'll get the idea.

<?php
// thispage.php
if (isset ($_POST['submitted'])) {
$resultsPerPage = 50; // or whatever value
$page = mysql_real_escape_string ($_POST['page']);

$start = ($page * $resultsPerPage) - $resultsPerPage;
$length = $start + $resultsPerPage;

// Notice how you don't send the query in the POST or GET, just
the page number
$sql = "SELECT `field` FROM `table` WHERE (`field_a` =
'someValue') LIMIT $start, $length";
$results = mysql_query ($sql);
}

// Go to next page
$page = $_POST['page'] ? (int) $_POST['page'] + 1 : 1;
?>
....
<form method="post" action="thispage.php">
<input type="submit" value="Go" />
<input type="hidden" name="page" value="<?php echo htmlentities
($page); ?>" />
<input type="hidden" name="submitted" value="1" />
</form>
....

<?php
while ($row = mysql_fetch_array ($results, MYSQL_ASSOC)) {
// Display results
}
?>


Hopefully that helps a little bit.

~Philip

""Thiago Pojda"" <thiago.pojda@softpartech.com.br> wrote in message
news:004701c88a8a$eaab6480$0201a8c0@softpartech...
> De: George J [mailto:georgejamieson@btconnect.com]
>
>> So calling the script via the form works i.e it passes the
>> neccessary variables to constrct the sql query for the next
>> call.
>
> As Shawn said, if you really need the query again add it to session,
> never,
> NEVER give the user the ability to see/execute queries by himself
> (remember
> POST data could be easily manipulated). Remember what Daniel said, adding
> a
> DELETE FROM is not hard and veeery bad>
OK. I see the logic.

> Ok, let me ask you something. Why post to itself? You could have a script
> only to do form actions, that way you can:
> 1 Separate huge php validations with your html form.
> 2 Use functions to handle the incoming data and writing the new query (or
> the old one again).

I suspect that most folk in my position start the learning process by
finding a script that does a similar task and adapting it. This is basically
what I've done. I started by finding a form example and then added a
pagination routine then... Several deadends later... Not the best way to
write anything but the simplest of scripts. However, the numerous changes to
the code has entailed lots of learning during the process. So in answer to
your question. I didn't set out with any idea of the best way to write the
script. Just a broad idea of what I wanted to end up with.

> As it's built at server side, the user is never going to see your query or
> [1]manipulate it as you're writing it all over again, just using your old
> parameters (they could be added as hidden fields in the form if strictly
> necessary).
>
>
>> So, as I see it, the pagination links won't POST the form
>> variables. How do I pass the 'SELECT * FROM mytable WHERE
>> selection=option LIMIT start, range'
>> query to the called script?
>
> You should try building a default query where you only add the parameters
> given by the user. If you can't seem to recover that, add them to
> $_SESSION
> and you'll be fine next time you want them (if you don't overwrite it
> =] ).
>
My query code-

-------SQL query construction block
$query = "SELECT * FROM prods ";
if($catagory != 0){ //
if category != 0
$where="WHERE c = $catagory ";
if ($manu != 0){ // check
manu != 0
$and = "AND m = $manu ";
if ($searchstring != 0){
$and = $and."AND description LIKE \"%$searchstring%\" "; //
check like != 0
}
}else{
...
$query=$query.$where.$and.$like

-----------
Can you please explain your suggestion above in laymans terms. I can't see
what you have in mind. Is it your suggestion to use one script, containing a
from, that calls another script that handles my query construction? That far
I follow you but what happens next?