Pods: Replace all session and session_id usage

Created on 12 Jun 2014 · 15Comments · Source: pods-framework/pods

We've had ongoing issues with incorrect session save path configurations, plus now we've encountered an added complication with modern hosting where sessions are handled by a dedicated machine via IP address stored in the session save path.

It appears our primary remaining usage of sessions is to use the session ID as added security for wp_verify_nonce() (and even then only when not logged in). After a little discussion with @sc0ttkclark I think we've agreed that we can replace that by incorporating the session management here: https://github.com/ericmann/wp-session-manager.

Puntable Enhancement

Source

pglewis

👀1

All 15 comments

WP_Session is now in WP Core, we should implement this instead going forward.

sc0ttkclark on 27 Oct 2014

👍1

I think it is not fixed: http://pods.io/forums/topic/issue-with-php-session-open_basedir/#post-192912

Enchancer on 24 Nov 2015

This doesn't indicate it's fixed, it's that it's on our roadmap for Future Pods Release. However, if you're looking for a workaround, you can discuss that here @Enchancer

jimtrue on 24 Nov 2015

The best would be to get rid of sessions totally. Indeed, even WP_Session drops a cookie.

Cookies, especially when they are dropped on every single page, are a problem for caching system like Varnish.

tristanleboss on 27 Jun 2016

possible workaround see #2542

This is what that particular config variable does:
PODS_SESSION_AUTO_START – false – Disables Sessions from starting when Pods is loaded. Sessions are used by Pods for securing usage of public forms visitors who are not logged in.

quasel on 19 Jul 2016

Maybe instead of wholesale removing sessions, we should think about why we needed them and what solutions exist now to achieve the same goals.

From what I remember, we had sessions to uniquely identify that someone (logged out) was indeed who they were supposed to be and that they only had access to the fields presented in the form itself.

Now, what pros/cons can we see with removing sessions? Let's put together a list to start.

sc0ttkclark on 22 Jul 2016

👍1

I haven't used forms from Pods, so I haven't had an opportunity to use sessions. However, I did recently run into this, and have disabled sessions to get caching to work properly. I haven't had any other issues with it, so my cons list is very short:

Sessions don't currently play well with caching
May be deprecated; this is just from the context from the earlier posts in this issue, it seems we didn't have an alternative when this was implemented

maiki on 23 Jul 2016

After trying to figure out why my client's site isn't caching for a very long time, I have stumbled across this. This issue is really important and has become a showstopper for me - I am considering ditching Pods. I will try setting PODS_SESSION_AUTO_START but I am not sure what I will be missing.

robrecord on 24 Jul 2017

We use sessions for public forms, so when you embed a form via the Pods shortcode or when you output one with $pod->form()

If you have no need for public forms, disabling the auto start should cover your bases.

sc0ttkclark on 24 Jul 2017

Thank you. Will you consider disabling sessions unless forms are actually in use by the setup? Especially considering that forms are secondary to the main feature set. This default behaviour causes a pretty big issue from my perspective, not least because people will not be aware of the workaround unless they have the persistence to go digging around for it.

robrecord on 24 Jul 2017

Open to ideas on how to accomplish that.

sc0ttkclark on 24 Jul 2017

Perhaps auto start could be disabled by default on new installs, with an option + information about it in the administration panel.

robrecord on 25 Jul 2017

PS I am sorry if I appeared to be rude, I appreciate your efforts on this plugin.

robrecord on 25 Jul 2017

Seconding @robrecord 's suggestion of making sessions an opt-in feature.