0

I'm developing my first project and I've done a some reading on maintain state across pages. From the few hours I've spent on the subject, it would appear that serializing and unserializing using $_SESSION seems a pretty simple and effective approach.

However, it seems to get frowned upon because of two main (and often disputed) reasons:

  • Performance
  • Security

I have a very typical (3 page) application process within my project 1>Select Category 2>Input Details 3>Confirmation => Add to database. And it makes sense to store the my object information within the $_SESSION.

On the performance front, the time to serialize the object was around 4 microseconds and to unserialize was 5 microseconds.

It would appear (from my reading) the preferred approach would be to use the actual datastore but surely to ask the database to save and retrieve this (often partial) information would take far longer and would result in a lot more code?

On the security front I understand the actual session information is stored on the server so isn't this secure?

I realise this has been asked before but the closest I found was asked 7 years ago

PHP: Storing 'objects' inside the $_SESSION

And was looking for more up to date opinions.

Community
  • 1
  • 1
JAMMac
  • 121
  • 10

1 Answers1

0

TL;DR: IMHO storing objects in the session is not that much of a big deal if within system requirements

Longer story: It really depends on the requirements / specifications of the system. i.e. the webserver is shared and everybody can read session storage... then i would not store it in session :P... i would not store a session at all

On the requirements point of view: is it required that a user can pick up where he left off during the process? If so, I would use a "persistent" store (i.e. the data store). If it is a process which cannot be resumed (only valid during the current session), I would not bother storing it in the datastore.

As security is involved: If your webserver is compromised, chances are they can access the database server as well (as in: get the DB login information from your scripts etc.). Meaning your data is compromised anyway. Either way around they could get the data if they would want to.

My suggestion in your case from your reading: just use the session for it, since it is much easier implemented (less code)

Ronald Swets
  • 1,669
  • 10
  • 16