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_start() and 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.
It says:
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.
Specifically:
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.
1
This has very little to do with wordpress, but if this answer will help eliminate the usage of session, it might be worth it….
Sessions are stored on the hard disk of the server. This is problematic in a shared hosting scenarion because the session directory is most likely readable and writable by all process running on the server, not only your site. All shared resources on a shared hosting server that do not have OS level user based protection (like directory permissions) is at least suspicious and you should not use it for anything secure or private.
lets repeat Sessions are stored on the hard disk of the server. What happen if you are running in a multi server enviroment? How will you be able to locate your session information. The only way to have it work is to tie users to specific servers which is not optimal.
And again Sessions are stored on the hard disk of the server. If you use sessions as integral part of your HTML generation it means that you can not cache your HTML.
WPEngine, is a shared hosting in a multi server enviroment that does caching by default.
As for WC, as it said in what you are quoting, they do not use php sessions, and invent their own mechanism by storing session information in the DB. This is also a problematic solution as it means that heavy traffic might bring the site down if you do not do it with extreme care (I guess in that case the session starts only when a user starts the process of buying a product). Why they do it like that and do not rely on cookies, you will have to ask them, I assume that tracking incomplete transactions is part of it, another part is that cookie information on http sites is basically public, and if you want to avoid information leakage you need to store it on the server.
What is adviced in your case? this will be hard to say without more details, but probably you should work to eliminate the use of anything which feels like a session. HTTP was not designed to have sessions, and it is best not to fight this fact of life.