I'm writing a WordPress plugin to deal with a third-party API.
This API requires a session identifier be passed to it so that the API (which basically functions as a third-party cart) knows what item to add where - again, think of it like a cart.
I want to store this session identifier in the sessions of my WordPress users. The idea would be to connect to this API, request the session identifier, and then store it in the WordPress/PHP session so I can reuse it as they navigate around the site and add more items to their third-party cart. I recognize this is not ideal (why not use WooCommerce to do this directly?) but we need some additional functionality and data that only this third-party can provide.
Anyway, as I went about trying to do this, I found this from our host : https://wpengine.com/support/cookies-and-php-sessions/
Which I confess I find terribly confusing.
According to that, PHP sessions and functions like
session_id() are not advisable, and won't work on this host - ...our system specifically ignores headers defining a PHPSESSID cookie.
But as the docs there point out - IF PHP SESSIONS ARE A TYPE OF COOKIE, WHAT’S THE PROBLEM?
In my mind, these docs don't answer that question.
The biggest conflict when using PHP Sessions has to do with the unique session identifiers. Because every user’s identification string is unique, this “busts cache” with every new user to visit your site. This kind of a system will not scale with many concurrent site users! With that in mind, our system specifically ignores headers defining a PHPSESSID cookie.
My question here is, isn't this true of the sessions they advocate, which are done via merely a different cookie which then leads to a database connection?
They say here:
The reality is, there’s a better way to store user session data! The correct method is to use the database to store session data. WooCommerce and other eCommerce solutions have already converted to using this method over traditional PHP Sessions, and also use their own cookie naming conventions.
These docs go on:
Beyond the performance and scaling implications, PHP Sessions present other problems. By default, PHP Sessions store data to the filesystem as their own unique file. Writing data to a file is an I/O process, and these kinds of processes are known to back up and cause high server load if your site gets too many concurrent users. Not to mention, this kind of session storage simply doesn’t work if your site is on a clustered solution spanning multiple web servers.
Why is this any worse/better than storing the sessions in a database? Isn't that also I/O?
I'm trying to understand - why is the default PHP session considered bad and the WooCommerce session considered good? I've looked into the WooCommerce source code on sessions, but I am not experienced enough in this arena to decipher why what they are doing avoids vulnerabilities as mentioned in the host's docs.
There are multiple security vulnerabilities centering around PHP Sessions. Vulnerabilities include Session data being exposed, Session fixation, and Session hijacking.
How does WooCommerce mitigate this where PHP sessions do not? What is advisable for my use case?
Obviously, I don't want insecure sessions, but developing a session manager/cookie/database connection, as Woo seems to have done, would take some time. So I'm trying to understand why/if this is necessary to replicate before I invest the time into avoiding PHP sessions.