SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 45 of 45
  1. #26
    SitePoint Enthusiast webdesignhouston's Avatar
    Join Date
    Dec 2010
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StevenHu View Post
    In summary:
    The cvid is correctly carried over the first time. When changes are made to the fields, that's when the cvid is undefined.
    The first time the form is loaded, you pull cvid from query string. Upon submission, you are passing cvid as a hidden form variable. So upon submission you should expect cvid to be present in $_POST.

    It is possible for you to be consistent by retrieving cvid from $_GET['cvid] regardless of whether your page was accessed via the GET or POST method:

    PHP Code:
    <!-- For pages that contain a link to the edit page -->
    <a href="cv-edit-page.php?cvid=<?php echo $cvid?>"></a>


    PHP Code:
    <!-- On the cv edit page itself -->
    <form action="<?php echo $_SERVER['PHP_SELF']; ?>?cvid=<?php echo $cvid?>" method="post">
    .
    .
    .
    </form>
    I hope this makes sense.

  2. #27
    Who turned the lights out !! Mandes's Avatar
    Join Date
    May 2005
    Location
    S.W. France
    Posts
    2,496
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    OR add this to your page

    PHP Code:
    if (isset $_POST['cvid']) {
      
    $_GET['cvid'] = $_POST['cvid'

    A Little Knowledge Is A Very Dangerous Thing.......
    That Makes Me A Lethal Weapon !!!!!!!!

    Contract PHP Programming

  3. #28
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Now I'm confused because now we're talking about he cvid in the form not being carried over and the thread started by talking about the cvid in a hyperlink not being carried over.

    Can someone please clarify which of the two we're now looking at? (Sorry been busy last few days).
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  4. #29
    Who turned the lights out !! Mandes's Avatar
    Join Date
    May 2005
    Location
    S.W. France
    Posts
    2,496
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Back in post 21, Stevenhu said that the value was correctly carried over in the URL the first time, but subsequent times he was getting errors.

    The first time the data is passed as a GET, but all times following that the data is passed as a hidden field in a form whoch is set to POST.

    PHP Code:
    <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post"> 
    .....
    .....
     
    <input type="hidden" name="cvid" value="<?php echo $cvid?>" />
    .....
    .....
    </form>
    A Little Knowledge Is A Very Dangerous Thing.......
    That Makes Me A Lethal Weapon !!!!!!!!

    Contract PHP Programming

  5. #30
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, I saw him say its carried over the first time but didn't realise that translated to the form although looking at the source again that does make sense.

    This is why I always combine my _GET and _POST arrays into one array (similar to _REQUEST but without cookies) so I can access things without worry as to how they've been submitted.

    I do this in my scripts - makes life much easier:
    PHP Code:
    $_HTTP $_GET $_POST
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  6. #31
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tangoforce View Post
    Ok, I saw him say its carried over the first time but didn't realise that translated to the form although looking at the source again that does make sense.

    This is why I always combine my _GET and _POST arrays into one array (similar to _REQUEST but without cookies) so I can access things without worry as to how they've been submitted.

    I do this in my scripts - makes life much easier:
    PHP Code:
    $_HTTP $_GET $_POST
    This is a security flaw, in the same way that register_globals is. You should ALWAYS know where your variables are coming from when you use them.

  7. #32
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That may be so but it works. Additionally any attacker would have to know about it anyway and then on top of that if you know it could be coming from either place and you know that data needs processing anyway you're still going to be accessing it directly by its key anyway.

    Its still safer than $_REQUEST.
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  8. #33
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    register_globals 'works' and has all those other conditions, doesn't stop it being a security flaw.

  9. #34
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Register globals is not the same thing and while I see what you're saying (IE values could be sent by $_GET for a post form) as long as the processing script is crafted to do a good job and assess the submitted values then it works well.

    I never allow input of anything which could be attacked anyway - IE prices. Anything like that is linked by its index in the database and then the rest of the info pulled from the DB when the form is submitted. I don't allow opportunity for anyone to alter things via a form.
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  10. #35
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    That's what you may think, but I can think of at least one attack where your site could be compromised because of this.

    In any case, it's just bad practice.

  11. #36
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If thats the case please PM me with those attack details and I'll reconsider the approach.
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  12. #37
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tangoforce View Post
    If thats the case please PM me with those attack details and I'll reconsider the approach.
    Having been PM'd by Stormrider he has indeed pointed out a way in which my technique could potentially be abused if you're not prepared for it and how an attacker could in fact fool someone else into becoming the attacker and thus hiding the original attackers own IP.

    While I do stand by my method for my own use (it works well in my system which was designed to intentionally accept input from both $_GET and $_POST) this may not be the case for everyone. I therefore recommend that unless you are familiar with checking submitted data thoroughly and defending against attacks, you only use my technique for testing and debugging purposes and THEN change to $_GET and $_POST where appropriate.

    There is technically nothing wrong with my method as it is slightly safer than PHPs own $_REQUEST which combines get, post and cookies but if you do use it use it with the same caution that you would use $_REQUEST.
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  13. #38
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    By default, $_REQUEST no longer includes cookies, but I still maintain you shouldn't use that either.

  14. #39
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It doesn't? - So its what.. just $_POST and $_GET now? - I give up lol.
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  15. #40
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,011
    Mentioned
    56 Post(s)
    Tagged
    0 Thread(s)
    Rather than fight it, embrace it. Allow the context to have meaning. In my system $_GET['save'] retrieves a form. $_POST['save'] commits the form.

    Get and Post are supposed to have two VERY different purposes. Get is for read operations. Browsers are expected to cache the results of pages fetched with get.

    Post is for write operations. Browsers are not supposed to cache a page delivered as part of a post and warn the user if they attempt to refresh the page.

    This system was devised by people quite a bit smarter than you or I tango - it would be prudent to pay attention to it, come to an understanding of why it is the way it is and use it the way it was intended.

  16. #41
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Storm and myself have been exchanging several PMs regarding this.

    While I do not dispute what you're saying, there are times when you may want to use both. EG say you have a page which contains several submit buttons - all of them do a different thing: Add, Edit, Delete which take you to a seperate page containing a form. You might however want a hyperlink on another page which also allows you to add something - processed by the same script. This hyperlink might be represented by an image (like the post reply image below this).

    So in this scenario it sounds like you're telling me I need two scripts to process an add request instead of being efficient and processing both from one script?

    Thats the point I'm making. Sometimes you may use a hyperlink AND / OR a button to do the same thing. Thats all I'm saying. I'm not fighting it but because there are pages on my site which use the same script in different ways I opted to allow both $_GET and $_POST to pass the mode to the script. I'm aware of how to access both get and post in my scripts but because of the way I've created some of the pages they need to be able to use both.

    In case its this thats worrying you, I never set the method of my forms that carry data to get - I always use post.

    While I agree that the methods were created by people smarter than you and I, even Sir Tim Berners Lee (inventor of the web) admitted a year or three back that the two forward slashes were "unnecessary"

    In a Times article in October 2009, Berners-Lee admitted that the forward slashes ("//") in a web address were actually "unnecessary". He told the newspaper that he could easily have designed URLs not to have the forward slashes. "There you go, it seemed like a good idea at the time," he said in his lighthearted apology.
    There are many cases of people being smarter than you or I. It doesn't mean they are correct and their solutions are absolute. Nasa spent millions inventing pens that could be used upside down while the rest of us used a pencil. Does that mean its now wrong to use a pencil upside down because its not the correct convention as defined by the smart bods at Nasa? Another example would be that smarter people design and build cars while the rest of us just repair them. It doesn't mean that they designed them perfectly because a lot of them rust, break down, end up as scrap etc. No-one is perfect no matter how smart they are.

    The way I see it is that its about how you use what is available. If no-one thought out of the box and tried different things we'd still be in the stone age.

    I don't base my forms and lookups on $_GET['save'] to retrieve and $_POST['save'] as you described, I use $Mode inside a switch and then process any input in a way that I expect the data to be transmitted.

    Although a button in a form may not carry data thats sensitive it can still carry a value and so technically its not wrong to post it when the value could be sent using get.

    For example I may have something like this:

    PHP Code:
    switch ($Mode)
       {
       case 
    'lookup':
          
    //Do lookup here
          
    break;
       case 
    'save':
          
    //Save data here.
          
    break;
       } 
    It allows me to write clear easy to understand and follow code which doesn't have php jumping in and out of html all over the place and have sloppy code all over the place.

    Thats all I'm getting at.

    I feel that we're now going off topic so we might need to consider moving the last few replies into their own thread.
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  17. #42
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    There is nothing in using POST/GET separately which means you have to add another page to do it...

  18. #43
    SitePoint Guru
    Join Date
    Aug 2009
    Posts
    669
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    True but I prefer to do all my processing for each module in one script - otherwise I start to get confused
    I'll do anything to avoid working on my own code

    Are you using: if (isset($_POST['submit'])) ?
    IE has a bug and does not always send the value.

  19. #44
    SitePoint Wizard
    Join Date
    Feb 2007
    Location
    Southern California
    Posts
    1,316
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AmjadMahmood View Post
    I had encountered the similar problem once and then i used $_REQUEST instead of $_GET and it really worked for me.
    That only works when the whole page works. In my case, the page is not working yet.

  20. #45
    SitePoint Wizard
    Join Date
    Feb 2007
    Location
    Southern California
    Posts
    1,316
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webdesignhouston View Post
    The first time the form is loaded, you pull cvid from query string. Upon submission, you are passing cvid as a hidden form variable. So upon submission you should expect cvid to be present in $_POST.

    It is possible for you to be consistent by retrieving cvid from $_GET['cvid] regardless of whether your page was accessed via the GET or POST method:

    PHP Code:
    <!-- For pages that contain a link to the edit page -->
    <a href="cv-edit-page.php?cvid=<?php echo $cvid?>"></a>


    PHP Code:
    <!-- On the cv edit page itself -->
    <form action="<?php echo $_SERVER['PHP_SELF']; ?>?cvid=<?php echo $cvid?>" method="post">
    .
    .
    .
    </form>
    I hope this makes sense.
    OK, I got the page working once I implemented this suggestion AND change the form to...

    name="mag_name" value="<?php echo $mag_name; ?>"

    ...where it was...

    name="Magazine Name" value="<?php echo $mag_name; ?>"


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
  •