| SitePoint Sponsor |
Hi,
I'm in the process of building a e-commerce style site. I've used HTTP_GET a lot...so sometimes my url may look something like so:
http://www.site.com/results.php?s=wo...sort=highprice
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.
I'm just wondering if i should have used $_POST instead?
The choice between GET and POST should be based on whether the request has side effects or not; POST is not just a safer version of GET.
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.Originally Posted by Vinno
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...
Use get for this kind of thing.
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
Could you give an example of a side effect? Just so im not missing out on anything
Thanks
Steve
Follow the dream, don't chase the competition.
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.
Side effects in this case I would imagine are referring to "Does this operation change data permanently?". If the answer is yes, you should use POST, if not, then GET is the recommended method.
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
Yeah, great response! I think the general consensus is that it's correct to use $_GET to retrieve data!?!.....so my approach is right!
Many thanks guys
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.POST is for changing state, not a security measure.
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
Thanks, makes sense now
Follow the dream, don't chase the competition.
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.
for example:
could be.com/results.php?s=womens&category=t-shirts&brand=adidas&sort=highprice
.com/womens/t-shirts/adidas/
Studiotime - Time Management for Web Developers
to-do's, messages, invoicing, reporting - 30 day free trial!
Thomas Multimedia Web Development
Yes I will clean these up eventually
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).
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.
Posting Permissions
Bookmarks