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

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.

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...