Using Sessions to Filter Posts - bad thing?

Question

I have a post type archive with filtering in a sidebar and pagination at the bottom. One of my biggest problems is that I'll always lose any $_POST filtering whenever I click pagination as the page refreshes. I decided to circumvent this by storing my filtering variables in $_SESSION variables when the page posts, then use these along with pre_get_posts to get my filtered posts. The only thing in my $_SESSION is an array of filter variables which does persist through multiple pages ( doesn't get refreshed, pagination ) and cleared whenever a user visits something that is not the post_type_archive() or whenever a user submits the filtering form. It works and it works well as far as I know.

I showed my workaround to a friend and he thinks that using $_SESSIONS in this instance is a bad practice since it does store files in the server and on a on a high traffic site it could become cumbersome. He also mentions that locked down browsers may not handle sessions very well which I suppose is a possibility.

My question is, in this instance is using $_SESSIONS really a bad thing? From my understand they were made for this type of persistence. Are there any drawbacks to this type of design?

Answer 1

As far as their use within WordPress, there is no native method to use $_SESSION. This means it is entirely on you to mitigate any security issues this presents.

Other problems depend on how your session data is saved. One problem I'm aware of is when the allocated memory for memcache is reached, it will drop the least recently used objects to make room for new ones1. But then, this also shouldn't a problem for $_SESSION if you can allocate the appropriate amount of memory to support your site's level of traffic.

WordPress has an API for transients where the data is stored in the database unless a caching plugin is used (I believe this is ultimately determined by wp_using_ext_object_cache2). When stored in the database, the loss of least recently used data shouldn't be an issue with transients. There may be advantages and disadvantages to this (database vs fast memory), but I just wanted to demonstrate an example of WordPress's native stateless design solution to storing temporary data. This problem would have to be solved on the server side, outside of WordPress if it should arise while using $_SESSION.

There are performance advantages/disadvantages depending on whether session is saved in hard disk files, RAM, database or other. These relate more to how the server is set up than the use of $_SESSION in WordPress though, since WordPress is essentially blind to the use of $_SESSION.

WP Engine has posted a good outline for why they don't recommend the use of $_SESSION with WordPress3, which I've posted below. Some of these are more applicable to how the server is set up, but take a look and decide how they might affect your site and if you think $_SESSION is a good solution for you. As I said, WordPress is blind to the use of $_SESSION, it's not handled natively, which leaves this open to the broader scope debate of whether it should be used in your PHP code at all.

PHP Sessions
We do not currently recommend using $_SESSION variables at all. This is for a number of reasons:

1. While WordPress itself supports the use of $_SESSION, WordPress is stateless and does not natively use $_SESSION. The proper way to work with WordPress is using cookies.

2. There are a number of security concerns when using $_SESSION.:

   • Session Poisoning
     
     • The attacker first visits the victim’s page, and e.g. logs on. Attacker then uploads a PHP script to his account, and has it display context of $_SESSION (set by victim script).
     • Attacker determines which variable needs to be changed, uploads a script which sets this variable, executes it.
     • Attacker visits victim pages to see if anticipated exploit worked.
     • This attack only requires that victim and attacker share the same PHP server.
     • The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the session identifier cookie from one cookie domain to another.

   • Session Fixation (on shared servers) For more information, see these two links:

     • http://phpsec.org/projects/guide/4.html
     • http://phpsec.org/projects/guide/5.html Session ID Hijacking (on shared servers)

   • Session ID hijacking can be a problem with PHP Websites. The PHP session tracking component uses a unique ID for each user’s session,
     but if this ID is known to another user, that person can hijack the
     user’s session and see information that should be confidential.
     Session ID hijacking cannot completely be prevented; you should know
     the risks so you can mitigate them. Depending on what plan you’re on
     with us, your site may run on a shared Web server. Be aware that any
     session variables can easily be viewed by any other users on the same server. Generally, the best way to mitigate this vulnerability by
     storing all sensitive data in a database record that’s keyed to the
     session ID rather than as a session variable. Non-sensitive data can
     be stored in cookies.

3. For our customers who are set up on clusters, we would have to completely change how our load balancers work, just to make sure that $_SESSION variables were available between different servers.

Answer 2

Short Answer, Yes, $_SESSION == 'bad thing'

Another possibility would be to disable the "built in" pagination and add ajax'd pagination. Then you can wire up your queries to respect the filters.