Can a text link pass php variables?

[nathanpacker]

Hey, say I have a table that spits out the information from a mysql table. Say it gives you the names of users, and certain information about each user, say address, phone number, whatever. Doesn't matter.

What I want to do is make each of the persons' name a hyperlink that you can click on to edit their information. When you click on their name, it would pull up a form with their current information already filled out in it. Then, you would be free to edit any of that information, and submit it to update the database.

I'm sure I've seen it done before, but how do I pass a record id onto that form so it knows which record to pull the information about?

[MCP]

Just build each link like:

<a href='editform.php?id=53'>John Doe</a>

[nathanpacker]

Just build each link like:

<a href='editform.php?id=53'>John Doe</a>

Dude, it's that easy? Thanks! Oh, then how do I call it on the edit page, once I'm there? I need to some how grab that id number on the edit page to fill it with all the info.

[nathanpacker]

Hey, never mind on how to call the variable. I just realized that it is a variable. I can just use it like any other variable! Man, you saved my life. This is great. Thanks again.

[MCP]

No problem! FYI, you can pass multiple variables by doing:

whatever.php?id=5&variable2=whatever&xyz=aaa

[nathanpacker]

No problem! FYI, you can pass multiple variables by doing:

whatever.php?id=5&variable2=whatever&xyz=aaa

Sweet, thanks, I was just wondering that.

[cpickering]

If i was doing this, I would use a form.

Passing variable's to the URL is problematic and open to abuse. By changing the URL at the top, people would be able to see others information.
You can protect this obviously, by employing sessions, and when they log in, their session ID is inserted into the db and tied to their account. You would have to code the edit page to first check the session, then run a mysql statement to confirm that the session ID ties to that account, if it does, render the rest of the page. If it doesn't redirect them to the login page again and kill their session using session_destroy()

Form:
By using a form, you've locked down the ability to change the ID of the page that people will be editing. Using the following code would be a very simple implementation of this.

<form action="edituser.php" method="post" enctype="multipart/form-data" name="edit" id="form">
<input name="id" type="hidden" value="<?php echo "$uID"; ?>">
<input type="submit" value="Edit" name="submit">

You would have to deploy an SQL statement at the top of this page to get the $uID, again, I'd use sessions and insert the sessionID into the user table at point of login.

Your edit page would then use the following code to get the information

<?
//insert session checker here and use header to redirect

// Get userID
$user = $_POST['uID'];

// get user detals mysql here
// select user,name from table where user = $user
?>

HTH

[php_daemon]

[...] I just realized that it is a variable. I can just use it like any other variable![...]

Note that register_globals can be turned off, and is off by default in later PHP versions as it's considered a bad practice. Use $_GET superglobal instead.

Also don't forget to validate the user input. In this case id is integer value so the correct access should be:

$id=(int)$_GET['id'];

If it's not numerical, use mysql_real_escape_string() before putting them into your queries.

[loopylouis]

This is something that will pull variables from the database and link the username to a file called "edit.php"

echo "
<Table cellspacing=2><tr><td width=30><b>Line number</b></td><td width=180><center><b>ID</b></center></td><td width=80><b>Username</b></td></tr>"  ;

//select a table from the database order by id in descending order

$var1 = Mysql_query("SELECT * FROM `table` ORDER BY id DESC");

//Fill table with variables

while ($var2 = Mysql_fetch_array($var1))
{
        $num++ ;
echo "<tr><td width=30><b>$num:</b></td><td width=180><center>$var2[id]</center></td><td width=50> <a href=edit.php?id=$var2[id]>$var2[username]</a></td></tr>";

}
echo "</table>";

"edit.php" should look something along the lines of this:

if (!$id){
//no id present
echo"there was no id to edit";
}else{
/*put all your edit script here editting via $id
for example the queries should run:
mysql_query("update `field` set 'feild'='$formvariable' where 'id'='$id' ");
*/
}

Hope this helps you out.

[nathanpacker]

This is all really great, and I would just use a form, but that would get a little bit out of hand, seeing that I would have ot have so many different forms, because each name in the list would be a link to edit it's account. And I realize that using the link like the first person replied could be insecure, I will have to keep that in mind for future projects, whereas this one does not require a whole lot of security, as it's a small little church thing, and probably won't have more personal info than a phone number stored in it. But I could use cookies and sessions to verify it.

When I get back around to it, I'll try to remember to let you all know what I've decided.
Thanks!

[MCP]

This is all really great, and I would just use a form, but that would get a little bit out of hand, seeing that I would have ot have so many different forms, because each name in the list would be a link to edit it's account. And I realize that using the link like the first person replied could be insecure, I will have to keep that in mind for future projects, whereas this one does not require a whole lot of security, as it's a small little church thing, and probably won't have more personal info than a phone number stored in it. But I could use cookies and sessions to verify it.

When I get back around to it, I'll try to remember to let you all know what I've decided.
Thanks!

While a form using the post method is less obvious then the ?id=xyz in the url, they're both just as hackable. If you want to verify (assuming you're running windows), check out Microsoft Fiddler, and you'll see exactly what gets passed along to your server. What you'll find is that the post method will have the same plaintext id=xyz in it, and any newbie hacker will be able to change the xyz to whatever he/she pleases. Don't be fooled into thinking post is more secure because you can't see the id being passed.

Personally, I prefer the whatever.php?id=xyz version because it's easy to create, easy to debug, easy to change on the fly if I need to, and my pages don't do a "Are you sure you want to repost the data?" everytime you refresh a page that's the result of a form press.

What you need to do in either case is use sessions (or some other mechanism such as Apache's basic auth) to properly validate that the user is authenticated and has access to the page. Only then are you sure you can somewhat trust the data being sent back.

Cheers,
MCP

[nathanpacker]

While a form using the post method is less obvious then the ?id=xyz in the url, they're both just as hackable. If you want to verify (assuming you're running windows), check out Microsoft Fiddler, and you'll see exactly what gets passed along to your server. What you'll find is that the post method will have the same plaintext id=xyz in it, and any newbie hacker will be able to change the xyz to whatever he/she pleases. Don't be fooled into thinking post is more secure because you can't see the id being passed.

Personally, I prefer the whatever.php?id=xyz version because it's easy to create, easy to debug, easy to change on the fly if I need to, and my pages don't do a "Are you sure you want to repost the data?" everytime you refresh a page that's the result of a form press.

What you need to do in either case is use sessions (or some other mechanism such as Apache's basic auth) to properly validate that the user is authenticated and has access to the page. Only then are you sure you can somewhat trust the data being sent back.

Cheers,
MCP

Good point! I really love the whatever.php?id=xyz, it's so easy. Sadly enough, I have put this project on hold for bit while I work on an automailing plugin for my wordpress site. :) That project was spiraling quickly into a never ending abyss of code, which was just depressing me. I'm sure I'll get back to it some time, but it was just a personal thing for my wife, that she really didn't care about. But I'm sure I'll be using that function in there somewhere too, it's just so simple and easy to use. Thanks again for all your input.

[digital-ether]

While a form using the post method is less obvious then the ?id=xyz in the url, they're both just as hackable. If you want to verify (assuming you're running windows), check out Microsoft Fiddler, and you'll see exactly what gets passed along to your server. What you'll find is that the post method will have the same plaintext id=xyz in it, and any newbie hacker will be able to change the xyz to whatever he/she pleases. Don't be fooled into thinking post is more secure because you can't see the id being passed.

Personally, I prefer the whatever.php?id=xyz version because it's easy to create, easy to debug, easy to change on the fly if I need to, and my pages don't do a "Are you sure you want to repost the data?" everytime you refresh a page that's the result of a form press.

What you need to do in either case is use sessions (or some other mechanism such as Apache's basic auth) to properly validate that the user is authenticated and has access to the page. Only then are you sure you can somewhat trust the data being sent back.

Cheers,
MCP

Yes, sending the id in the url (HTTP GET Request) and in the form (HTTP POST Request) are both plain text.
Forms are viewable when viewing the HTML Source, so any "hidden" fields are visible in plain text.
Forms may be a little bit harder to edit then the URL, but anyone who wants to edit the HTTP request usually can, so you should NEVER trust ANY data sent from the client. Your PHP should be written independent of what your server sends to the client and under the assumption that the client will send you bogus data of every kind.

A plain URL (HTTP GET Request) is one of the "Safe methods" and should be used for requesting a resource on the server (a page, or database result) that can be cached and does not change frequently. (In fact, a URL is considered a resource identifier, so should be used as such)

A FORM POST (HTTP POST Request) is one of the "Idempotent methods" and should be used to invoke a change on the server, like saving a database result, uploading a file etc.

Ref: http://www.ietf.org/rfc/rfc2616.txt - "Safe and Idempotent Methods".

In your case, you are just retrieving the users data from a database. Therefore the GET method (id=xyz) is more appropriate. That way the page will be cached appropriately by HTTP and by the users browser and won't prompt on refresh as FORMs do. (as MCP mentioned)

Once the user edits the data, and sends it to the database, you should use a FORM POST. This will make sure the user is prompted by the browser is they click refresh. It will "ensure" the browser or HTTP doesn't cache the data. The user is also accustomed to seeing FORMS as a way of submitting new or edited data.

In both cases however, you should authenticate the user as mentioned in the other posts.

[nathanpacker]

Yes, sending the id in the url (HTTP GET Request) and in the form (HTTP POST Request) are both plain text.
Forms are viewable when viewing the HTML Source, so any "hidden" fields are visible in plain text.
Forms may be a little bit harder to edit then the URL, but anyone who wants to edit the HTTP request usually can, so you should NEVER trust ANY data sent from the client. Your PHP should be written independent of what your server sends to the client and under the assumption that the client will send you bogus data of every kind.

A plain URL (HTTP GET Request) is one of the "Safe methods" and should be used for requesting a resource on the server (a page, or database result) that can be cached and does not change frequently. (In fact, a URL is considered a resource identifier, so should be used as such)

A FORM POST (HTTP POST Request) is one of the "Idempotent methods" and should be used to invoke a change on the server, like saving a database result, uploading a file etc.

Ref: http://www.ietf.org/rfc/rfc2616.txt - "Safe and Idempotent Methods".

In your case, you are just retrieving the users data from a database. Therefore the GET method (id=xyz) is more appropriate. That way the page will be cached appropriately by HTTP and by the users browser and won't prompt on refresh as FORMs do. (as MCP mentioned)

Once the user edits the data, and sends it to the database, you should use a FORM POST. This will make sure the user is prompted by the browser is they click refresh. It will "ensure" the browser or HTTP doesn't cache the data. The user is also accustomed to seeing FORMS as a way of submitting new or edited data.

In both cases however, you should authenticate the user as mentioned in the other posts.

Good info, I guess I'm going to have to look into the GET method, I haven't used it much.

[digital-ether]

I blogged my post here: http://fijiwebdesign.com/content/view/92/77/ if anyone wants to read a bit more on GET vs POST methods...

[nathanpacker]

I blogged my post here: http://fijiwebdesign.com/content/view/92/77/ if anyone wants to read a bit more on GET vs POST methods...

Thanks. Ha, looks like you're the one helping me with my other problem right now. ;)