Rant about losing $_POST when $_GET is used...

[ChenXiu]

So maybe this is normal, or maybe there is a "better way."
My website operates on $_POST (sanitized, of course), javascript, and hidden inputs.
Visitor posts inventory to my page. This inventory gets added to a big chart.
Sometimes, midway through the process, that visitor might add inventory via a 'referral link' which does a $_GET request to my page.
"Ker-Plunk"
All the $_POST variables are lost.
There.... that's my rant.

The only simple solution appears to be to always save $_POST data to $_SESSION["post"]  on the off-chance  some visitor some day ever decides to do a $_GET request from a referral link.

3 weeks of my life has been lost to correcting the neverending 'illegal string offset' and 'undefined index' errors etc. by making sure every last variable is declared...
At the very least, I quickly learned early on you don't simply slap $_SESSION["post"] = $_POST at the top of the page.
...and it can't be if(isset($_POST)) { $_SESSION["post"] = $_POST } either! (it has to be if ($_SERVER['REQUEST_METHOD'] === 'POST') {$_SESSION["post"] = $_POST; }

Anyway, blah blah blah, that's my rant.

Is there a better way? Or is this "how everybody does it?" It seems stupid to have to do all of this.

 

[Barand]

31 minutes ago, ChenXiu said:

The only simple solution appears to be to always save $_POST data to $_SESSION["post"]

or a database

 

[ChenXiu]

Yes sir. I did give this serious thought. I was able to make everything work by simply serializing $_POST data, and retrieving it when the $_GET request is made.
But then I read about all the dangers and pitfalls of serializing $_POST (not to mention, doing so would be uncultured and uncivil).
I made a list of pros and cons:
mySQL Cons
I am not very good at mySQL (writing the simplest prepared statement requires about 3 hours debugging afterwards)
I have to worry that one day a visitor will decide to Post too much inventory data and my varchar(255) columns would be too small.
(If I used "text" or "blob" I would be worried my table is taking too much unnecessary pace, greenhouse gases, etc.)
mySQL Pros
Visitor would NOT need cookies enabled.
Page loads 2000 milliseconds faster with Sessions off.
Session Cons
Pages take .02 seconds longer to load
I still don't know how to properly destroy a session
I don't like the "feel" of "something hanging around" (like having a ghost in the room)
Session Pros
I can monitor (better) what my Visitor is doing and where they are going using session_id()
Everybody uses sessions and cookies (that's why websites are so slow nowadays)
Sessions seem adequately secure.
If my website gets hacked, they'll leave immediately because my $_SESSION code has made a mess of everything.

If I knew mySQL as well as you do I'd have given full mySQL a shot.

...but I know my place.
 

[Barand]

The way to get to know it is to use it.

[requinix]

4 hours ago, ChenXiu said:

My website operates on $_POST (sanitized, of course), javascript, and hidden inputs.

Can I assume you mean that you use POST when performing certain operations, such as when someone wants to add inventory to the site, and that you use regular GET when it comes to simple browsing?

Because it doesn't sound like that's the case. And it should be.

[sen5241b]

Excellent rant, ChenXiu. I a dealing with the same issue but you seem to be ahead of me. Have you made a firm decision on what is best? It seems PHP does  not always provide a simple  way to do basic things.

[Strider64]

Yes sir. I did give this serious thought. I was able to make everything work by simply serializing $_POST data, and retrieving it when the $_GET request is made.
But then I read about all the dangers and pitfalls of serializing $_POST (not to mention, doing so would be uncultured and uncivil).
I made a list of pros and cons:
mySQL Cons
I am not very good at mySQL (writing the simplest prepared statement requires about 3 hours debugging afterwards)

It's pretty easy writing PHP to access the MySQL database table. It just takes practice and actually writing the code.

I have to worry that one day a visitor will decide to Post too much inventory data and my varchar(255) columns would be too small.
(If I used "text" or "blob" I would be worried my table is taking too much unnecessary pace, greenhouse gases, etc.)

Unless you are the size of Facebook, I don't think you have anything to worry about taking up space in a db table.

If I knew mySQL as well as you do I'd have given full mySQL a shot.

...but I know my place.

 

Find a good tutorial, practice coding and actually write the code. I didn't start off right away knowing how to code in PHP and everyone here has started off as a newbie.
I didn't learn PHP until I was in my 50s and now I am not only able to access MySQL using PHP PDO, but can do the following:

    /*
     * This is the update that method that I came up with and
     * it does use named place holders. I have always found
     * updating was easier that creating/adding a record for
     * some strange reason?
     */
    public function update(): bool
    {
        /* Initialize an array */
        $attribute_pairs = [];

        /* Create the prepared statement string */
        foreach (static::$params as $key => $value)
        {
            if($key === 'id') { continue; } // Don't include the id:
            $attribute_pairs[] = "{$key}=:{$key}"; // Assign it to an array:
        }

        /*
         * The query/sql implodes the prepared statement array in the proper format.
         */
        $sql  = 'UPDATE ' . static::$table . ' SET ';
        $sql .= implode(", ", $attribute_pairs) . ', date_updated=NOW() WHERE id =:id';

        /* Normally in two lines, but you can daisy chain pdo method calls */
        Database::pdo()->prepare($sql)->execute(static::$params);

        return true;

    }

Commenting your code also help reinforcing what you have learned.

Edited May 28, 2021 by Strider64