SitePoint Sponsor

User Tag List

Results 1 to 18 of 18
  1. #1
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    overuse of $_GET??

    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?

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    SitePoint Member
    Join Date
    Jun 2007
    Location
    Gold Coast, Australia
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #4
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Vinno View Post
    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.

  5. #5
    SitePoint Zealot evilunix's Avatar
    Join Date
    Jun 2008
    Location
    York, UK.
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

  6. #6
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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

  7. #7
    SitePoint Zealot Steveiwonder's Avatar
    Join Date
    Nov 2008
    Posts
    151
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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.
    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.

  8. #8
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by evilunix View Post
    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.

  9. #9
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Steveiwonder View Post
    Could you give an example of a side effect? Just so im not missing out on anything

    Thanks

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

  10. #10
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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

  11. #11
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  12. #12
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    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.
    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.

    Quote Originally Posted by elduderino View Post
    Yeah, great response! I think the general consensus is that it's correct to use $_GET to retrieve data!?!.....so my approach is right!
    In all those words, yes.

  13. #13
    SitePoint Addict
    Join Date
    Apr 2009
    Posts
    248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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.

  14. #14
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    POST is for changing state, not a security measure.
    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

  15. #15
    SitePoint Zealot Steveiwonder's Avatar
    Join Date
    Nov 2008
    Posts
    151
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, makes sense now
    Follow the dream, don't chase the competition.

  16. #16
    SitePoint Wizard wheeler's Avatar
    Join Date
    Mar 2006
    Location
    Gold Coast, Australia
    Posts
    1,369
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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:
    .com/results.php?s=womens&category=t-shirts&brand=adidas&sort=highprice
    could be
    .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

  17. #17
    SitePoint Wizard
    Join Date
    Oct 2005
    Location
    London
    Posts
    1,678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes I will clean these up eventually

  18. #18
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SituationSoap View Post
    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).

    Quote Originally Posted by arkinstall View Post
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •