Support

June 27, 2016 at 8:42 am

If using WP-Engine, you will NOT be able to use event espresso because they explicitly restrict sessions due to security vulnerabilities and state that you need to use javascript instead.

EVENTESPRESSO TEAM: Please revise your code and make this more secure. Thank you. For now, I’ve purchased something that is completely useless to me due to the lack of security measures taken during development.

Here’s their response to this issue:

https://wpengine.com/support/cookies-and-php-sessions/?utm_source=portal&utm_medium=support&utm_campaign=caching-issues

COOKIES AND PHP SESSIONS

On this page: This article explains in-depth how PHP sessions and cookies work on the WP Engine platform. Cookies and PHP session variables are used by many plugins and themes for WordPress.

Tags: cookies, php

Updated: April 26th, 2016

Cookies and PHP $_SESSION variables are used by many plugins and themes for WordPress. While we don’t currently prevent cookies or sessions, they may not work as you expect on our servers.

Caching

WP Engine implements Page caching as a primary method of speeding up the sites that we host. Here’s a rough overview of how page caching works:

Visitor 1 views your site.
The server receives the request
The server sends the request to WordPress
WordPress executes the Core PHP code, as well as the PHP code in the site’s plugins and theme
The HTML that is created by the PHP code is captured by the server, and cached (saved)
The HTML is served to Visitor 1
Visitor 2 views your site
The server receives the request
The server sends Visitor 2 the cached HTML, instead of sending the request to WordPress
When a visitor is served a cached version of the site, then the PHP code is not executed. This means that any PHP code that looks for cookies or handles session variables will not work, simply because it is not running.

There are certain special cases, where caching is disabled. One such case is when the website visitor logs into WordPress. WordPress sets cookies related to that login, and our system is set up to recognize those WordPress login cookies. When those cookies are found and are valid, then page caching is disabled.

Another special case where caching needs to be disabled is for eCommerce sites. Sections of the site, such as product pages, the cart, and the checkout page, need to be un-cached for all visitors. Because these settings can vary from site to site, we currently require you to open a 24/7 Live Chat, which you can do from within your User Portal.

Cookies

Cookies can still be used with page caching. However, they need to be handled predominantly with Javascript instead of PHP. If you try to use PHP to read cookies, it will likely only display an empty cookie array.

This does not mean that you cannot use PHP at all with cookies. If you want to use PHP, then you will need to use Ajax to make requests to the server and run PHP code. WordPress has native support for Ajax functionality, and also makes that functionality extensible. For more information on using Ajax with WordPress, see the Codex entries for Ajax and Ajax in Plugins.

PHP Sessions

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

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.
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.
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.
As mentioned before, Sessions generally aren’t compatible with page caching, because the arguments at the end of the URL that carry $_SESSION information are dropped. This means that if you (or your users) are logged into WordPress, Sessions will likely work as expected. Otherwise, Session data will appear to be empty.