The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

overuse of $_GET??

I've made precautions to protect against injection attacks and if a user were to start messing around with the query string they're either shown a 'no results' message or in certain circumstances redirected to the homepage.

As long as the GET string does not exceed the browser address bar max length and the data being passed is not of a sensitive nature then really it doesn't matter.

Keep in mind though that using POST has implications on the use of the browser's back button and therefore in the context of an e-commerce site where users a likely to go back and forwards between pages frequently, POST should only really be used during the checkout process.

As long as the GET string does not exceed the browser address bar max length and the data being passed is not of a sensitive nature then really it doesn't matter.

Keep in mind though that using POST has implications on the use of the browser's back button and therefore in the context of an e-commerce site where users a likely to go back and forwards between pages frequently, POST should only really be used during the checkout process.

GET should be used to retrieve data, POST should be used to change it. Remember those simple rules, and you've eliminated a lot of the guesswork.

Personally, I prefer to POST any time that I can, just because I like to simplify my querystrings, but that's a personal preference.

POST is in no way more secure than get. Users may not be able to see parameters in the address bar, but a quick snoop at the source code of the form page shows exactly what is being posted. There are plenty of browser plugins about that allow you to modify what is posted also...

As previously said, it retrieves data. Think about it like this. So, you've got a search above. Meet 'Dorris'. Every week she looks on your site to see whats new and will probably buy something.

So, Dorris doesn't want to have to type in her search details every time, so she makes a bookmark.

Now, say you use POST. She clicks that bookmark and all of her search terms are gone, and she's greeted with an error page.

Say you use GET. The search terms are in the saved URL so, by clicking the bookmark, Dorris is now on the page she wants to be on.

By clicking that bookmark by accident, Dorris isn't going to change anything on your site - she's just going to see data.

If it was a request that, say, DELETED an item (for example), clicking on such a link by accident would change something, which you dont want. A POST request requires the submission of a form, so the user will know what they're doing.

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona

POST is in no way more secure than get. Users may not be able to see parameters in the address bar, but a quick snoop at the source code of the form page shows exactly what is being posted. There are plenty of browser plugins about that allow you to modify what is posted also...

Were you referring to my post? I'm well aware of these facts. My point was that the GET and POST methods were designated in HTML to perform a certain service (Getting and Sending data respectively), and that you should stick to those standards in your own code. I'm a firm proponent for always validating user input, regardless of the medium that passed it.

A side effect would be something which changes something important when you go to the page.

For example, a form to update a product would be through POST, because it's updating information. Same with deleting. It's also meant to be used when you're posting possibly sensitive data. You wouldn't want your login details to be displayed in the Address Bar, for obvious reasons.

However, viewing something would generally be through GET.

Off Topic:

This thread is being bombarded by posters today!

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona

I disagree. If you're transferring sensitive data, use https. POST is for changing state, not a security measure. However, logging in to a session-based system can be considered changing state.

In all those words, yes.

I would argue that using POST for sensitive data is a security measure. Shoulder-surfing is still a viable method of information disclosure. I wouldn't pass things like Passwords or account details in the URL bar, for instance.

It wasn't as a security-measure; it's common sense. If you have a password, even to VIEW data (say you need a password before being able to read, but the system doesn't use sessions etc), you should use post.

Why? Well, type in the start of a well-used URL on your computer. Most (if not all) browsers will give you a list of suggestions... including the $_GET string. Say you have a password in that $_GET string.

As I said, common sense

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona

I don't know if this is a concern of the OP, but for a seemingly commercial website you should consider using mod_rewrite to tidy up the URLs purely for the SEO advantage. When you have indefinite $_GET parameters search engines tend to get lost.

I generally think its fine for your search pages to produce a huge url, but for the "static" categories stick with a tidy url.

I would argue that using POST for sensitive data is a security measure.

If it's used for that purpose, it's misused. For authentication, the user/pass can be sent through post, after which the session is considered authenticated. I would use POST in that case, because it changes state (stores the authentication status in session).

Originally Posted by arkinstall

It wasn't as a security-measure; it's common sense. If you have a password, even to VIEW data (say you need a password before being able to read, but the system doesn't use sessions etc), you should use post.

I wouldn't go there. If you need authentication for each request, and you don't want to use sessions, use http-authentication. Nearly all http-clients support it.