How could I do this?

davespring

Ive got a simple lottery game, and am using an sql database to keep track of the numbers bought. But, when the person comes to buy the ticket, I have to relay to my process page which ticket they want. How could I do this?

<?php
session_start();
$page = array();
$page['title'] = 'OpenTheBox | DuffLotto';
$number = 1;
include('header.php');
require_once('/home/davespri/hidden/dbcon.php');

echo '<h1>OpenTheBox - The Original Community Game</h1>';
echo '<center>
   Available Numbers
</center>';
$connect = mysql_connect($host, $user, $pass);
if (!$connect) {
   die('Unable to connect to Mysql');
   }
mysql_select_db('davespri_Gamerecords', $connect);
$result = mysql_query("SELECT * FROM OpenTheBox2");
echo "<center><table border='1'><tr><th>Slot:</th><th>Taken by:</th></tr>";
while ($row = mysql_fetch_array($result)) {
   echo "<tr>";
   if ($row['Nickname'] = 'NULL') {
      $row['Nickname'] = "<center><form action=http://dufflotto.hostcell.net method=post>
<input type=submit value=Buy! name=" . $row['Slot'] . ">
</form>";

  }
   echo "<td>" . $row['Slot'] . "</td>";
   echo "<td>" . $row['Nickname'] . "</td>";
   echo "</tr>";
}
echo "</center></table></center>";
include('footer.php');
?>

gordonrp

Set the form action to the process.php?

Hard to understand what exactly you need with such little info.

davespring

What I mean is, Im setting the form to send to the 'process.php', which is happening. But, I need to know how on that process page which table part is being chosen. When I use the 'post' feature to send across, I dont actually know which part is being chosen, because the button has no value, only the name.

gordonrp

Are you trying to pass $row['slot'] to the next page?

If so, include this in your form

<input name=\"slotChosen\" type=\"hidden\" value=\"$row['Slot']\">

e.g.

if ($row['Nickname'] = 'NULL') {
      $row['Nickname'] = "<center><form action=http://dufflotto.hostcell.net method=post>
<input name=\"slotChosen\" type=\"hidden\" value=\"$row['Slot']\">
<input type=submit value=Buy! name=" . $row['Slot'] . ">
</form>";

And you can access it on process.php with
$POST['slotChosen']
or
$REQUEST['slotChosen']

More info on hidden form elements here: http://www.oreillynet.com/pub/a/php/2004/08/26/PHPformhandling.html

davespring

Thats worked, thanks alot! 🙂

bradgrafelman

Note that if you use a hidden form element, then you're allowing the end user to easily change that data before it's submitted.

Instead, I would recommend using a [man]session/man from one page to another to store the data; session data is stored on the server, meaning the user can't maliciously alter the value chosen.

davespring

bradgrafelman;10937554 wrote:
Note that if you use a hidden form element, then you're allowing the end user to easily change that data before it's submitted.

Instead, I would recommend using a [man]session/man from one page to another to store the data; session data is stored on the server, meaning the user can't maliciously alter the value chosen.

That doesnt matter really, beacause when I go to alter the db, i will be escaping the string to prevent security breaches within the db

laserlight

davespring wrote:
That doesnt matter really, beacause when I go to alter the db, i will be escaping the string to prevent security breaches within the db

The issue of escaping input to the database and that of preventing users from altering what they should not alter are orthogonal. In this case, you may be right to say that it does not matter if the user does change the ticket: presumably one ticket is as good as another, and changing to an invalid ticket is just the user's fault, assuming that you handle it correctly everywhere.

On the other hand, using a session is better because it means an extra layer of protection: you can be more certain that the data has an expected and valid value.

gordonrp

bradgrafelman;10937554 wrote:
Note that if you use a hidden form element, then you're allowing the end user to easily change that data before it's submitted.

Instead, I would recommend using a [man]session/man from one page to another to store the data; session data is stored on the server, meaning the user can't maliciously alter the value chosen.

Correct me if I'm wrong, but I believe your logic is flawed:

At some point he has to display options to the user and allow the user to make a choice/input. Putting the data into a session after it is submitted is no more secure than any other method, as the data still has to be displayed to the user first and submitted back to the site using a form or other method (which can be changed). Perhaps I misunderstood you, and you could explain more?

I agree that the inputted value should be validated in process.php, e.g. double checking that the ticket number bought is still available and valid. But I don't see where a session comes into the input processing part (perhaps later after having chosen the ticket / displaying on the site).

Anyway, glad you got it working OP, be sure to validate all inputs.

davespring

Thats exactly what the next step of the jigsaw was, after I got this sorted out 🙂

bradgrafelman

@: You're right; I didn't read the code very carefully. I had assumed that the OP was generating random lottery tickets - my mistake!

laserlight

gordonrp wrote:
Putting the data into a session after it is submitted is no more secure than any other method, as the data still has to be displayed to the user first and submitted back to the site using a form or other method (which can be changed).

As I mentioned, it is an additional layer of security. If the form permits the user to change the lottery ticket again at this point, then certainly it is pointless to store the data in a session. However, since a hidden form element is used (or at least you suggested it 🙂 ), it implies that the lottery ticket is not expected to change at this point. Therefore, storing it in a session is better than sending it as a hidden form element since the data has already been validated and cannot be made invalid: there is no need to re-validate it, which would have to be done if it were sent as as the value of a form element, hidden or otherwise.

gordonrp

I think you're thinking in circles ;-0

The user is buying a ticket on the OP's first page of code, so we don't care if they hack the input and POST false data. We are going have to validate the data submitted anyway to ensure that there wasn't someone else who purchased that ticket between the time that the first page (available) tickets was displayed and the time the user clicks "buy".

Simply using a session on the first page to display say 10 available tickets and then checking the ticket selection on the next page against the session would be an insufficient solution. I see no need for sessions here, except perhaps for a login system, and using the username to store against the purchased ticket record.

The whole process of choosing a ticket requires that data be submitted in some fashion, and we can't really do that without a hidden field in this case.

Anyway.... I think we both understand the correct way to code this!

davespring

gordonrp;10937598 wrote:
I think you're thinking in circles ;-0

The user is buying a ticket on the OP's first page of code, so we don't care if they hack the input and POST false data. We are going have to validate the data submitted anyway to ensure that there wasn't someone else who purchased that ticket between the time that the first page (available) tickets was displayed and the time the user clicks "buy".

Simply using a session on the first page to display say 10 available tickets and then checking the ticket selection on the next page against the session would be an insufficient solution. I see no need for sessions here, except perhaps for a login system, and using the username to store against the purchased ticket record.

The whole process of choosing a ticket requires that data be submitted in some fashion, and we can't really do that without a hidden field in this case.

Anyway.... I think we both understand the correct way to code this!

I am working with another website, and need to keep the users info in the session so I can make API calls 🙂

laserlight

gordonrp wrote:
The user is buying a ticket on the OP's first page of code, so we don't care if they hack the input and POST false data. We are going have to validate the data submitted anyway to ensure that there wasn't someone else who purchased that ticket between the time that the first page (available) tickets was displayed and the time the user clicks "buy".

That is true, if we only validate the ticket after the final stage. We could validate it immediately after the stage where it is selected, and thus after the final stage only need to check that it is still available instead of performing a full validation.

There is actually another possibility, which perhaps involves greater use of the database: immediately after selection, the ticket is reserved until the termination of the process or a timeout. Subsequent users would not be able to select the ticket, even if the first user has not completed the process. This reduces the chance of a user being frustrated by reducing the window of time between ticket selection and confirmation, while allowing for intermediate stages.

With this method, the ticket will certainly need to be fully validated immediately after selection, but would not need to be checked for availability at the end.

gordonrp wrote:
The whole process of choosing a ticket requires that data be submitted in some fashion, and we can't really do that without a hidden field in this case.

Not really: a cookie, a session or even the database can be used. This is really all about maintaining state.

gordonrp

laserlight;10937605 wrote:
Not really: a cookie, a session or even the database can be used. This is really all about maintaining state.

Clicking a URL which sets a cookie, or using a hidden form field, it's all the same because they can both be forged.

My point earlier was simply that by bringing in a session you don't automatically get any more security, as you can't trust any input from the user and for this app there will always be input (selection of ticket) by the user.

Lets not over complicate things, now I must bow out of this thread before my fingers fall off! 🙂

laserlight

gordonrp wrote:
Clicking a URL which sets a cookie, or using a hidden form field, it's all the same because they can both be forged.

Obviously 🙂

gordonrp wrote:
My point earlier was simply that by bringing in a session you don't automatically get any more security, as you can't trust any input from the user and for this app there will always be input (selection of ticket) by the user.

Yes, I can agree with the "you don't automatically get any more security" part. But the principle to recognise here is one of validating the data, and then keeping the validated data away from modification by untrusted users. This is better than having to re-validate it, or delaying validation, both of which are more susceptible to oversight.