storing in SESSION vs dbTable

[phppup]

Within the quiz that I am assembling (which does NOT allow a user to return backwards), there are answers to previous questions

For example, #1 ....what color was John's coat.

                      #3.... what was the problem with John's blue coat?

                      #4.... After Mary fixed John's torn coat pocket, where did they go?    etc.

At the end, the person will be asked, "Do you want to submit these answers or take the test again"?

If they decide to re-take the test, then no answers will be evaluated.  If they submit their responses, then the replies will be saved in the database.

I see two approaches: either I can save each answer in $_SESSION and INSERT them ALL if the user clicks the "SUBMIT my answers" button

OR, I can INSERT and UPDATE to the table after each question is answered and either DELETE the record or overwrite it as the quiz progresses, until they decide to choose SUBMIT.

Which is the best approach? Why?  Are there any other realistic options to consider?

 

Edited May 26, 2022 by phppup
Typos

[Barand]

To keep the debate lively I'll throw in another option - store the answers in an html form's input fields. When they finish they can submit or start again.

You could show the questions one at a time, using javascript to hide the one just answered and display the next.

[schwim]

1 hour ago, phppup said:

Which is the best approach? Why?  Are there any other realistic options to consider?

In my mind, if I weren't worried about exploiting SESSION vars(and in your usage, I wouldn't personally), I'd use SESSION as it would require less overhead and would result in less code.

If you were looking to save for later use(like user leaving and returning later), then I'd look at using the db to store the values.

[requinix]

Sessions are for stuff that needs to be accessed in different parts of the site. If you want data only for the quiz (and what's more, only for that particular quiz) then it doesn't belong in the session.

+1 to storing it as hidden inputs in the form. That's what I've done previously: generate the quiz questions and answers ahead of time (a dynamic quiz that pulls from a pool of questions and randomizes it all), serialize and encrypt the data, store that in a hidden input, update the data with answers as they complete the questions, then process it at the end.

Assuming the data isn't supposed to be persistent.

[schwim]

6 minutes ago, requinix said:

Sessions are for stuff that needs to be accessed in different parts of the site. If you want data only for the quiz (and what's more, only for that particular quiz) then it doesn't belong in the session.

This is interesting.  What's the downside to utilizing SESSION to store data that isn't used elsewhere?  Is it slower, prone to failure? I ask because I've used it in the past this way and have never run into a shortcoming that I had noticed.

I hope this isn't seen as a derailment to the topic at hand, it's intended to remain relevant to the OP's post.

[phppup]

@schwim I was conflicted because I've heard that $_SESSION might be easily compromised, however, I would think reposting the same data in HTML through a hidden input as suggested by @requinix suggested, could be even more vulnerable. How would I do it securely?

I found it interesting that the next post after this one titled login user only one device at a time seemed to align with a similar vagueness regarding the implementation of whether a SESSION or a TABLE would be more effective as a Best Practice to handle movement of information.

Remarks?

[schwim]

21 minutes ago, phppup said:

How would I do it securely?

The general rule is that you can never trust client input, so if you're thinking along that line of thinking and with your needs, it's going to be susceptible to exploitation attempts no matter what you do. They're either able to spoof session data, they can modify the form input carried over from a previous page or they simply find a way to move back a page when you didn't want them to.

Since nothing was mentioned regarding why you wouldn't use SESSION in this case other than because PHP says so, I would still consider that a viable option for this example.  I've used it for well over a decade and have never run into an issue that kept me from using it successfully in cases such as these.  I would sanitize the input, store it and use it on the next page load, regardless of that page load is on the same page or a different one.  It would require less coding and barring input from the others that are much more savvy than I at coding, I can't see a shortcoming to it.

[requinix]

22 hours ago, schwim said:

This is interesting.  What's the downside to utilizing SESSION to store data that isn't used elsewhere?

1. It clutters the session. If you have a lot pages storing their arbitrary data in there then you start to lose track of what values are in there and why. It's the same problem as with global variables.
2. Making sure the session is clean of old data can be hard. Consider if someone browses through the quiz and then stops partway: what happens to the data? It stays in there until something either overwrites it or removes it (like doing another quiz) so the longer a user is on the site and the more they don't conform to the expected behavior for a user, the more data piles up.
3. Upgrading users through data changes becomes a problem. If the quiz works one way for a long time and then it's changed to work differently (requiring the session data be stored differently) then you have to worry about users with long-lived sessions who have old data still in there.
4. It is actually slower to some degree. Every time you fire up the session, PHP has to deserialize the entire session from its cache, and if there are large chunks in there you don't care about then it is wasteful.

[requinix]

1 hour ago, phppup said:

@schwim I was conflicted because I've heard that $_SESSION might be easily compromised,

No. The session is stored on the server so as long as the server isn't compromised then the session data won't be compromised.

It's like my refrigerator. There's no lock on it so anyone could take and leave what they wanted at any time, so in that sense it's insecure, however the doors to my home are locked so people can't get inside.

[schwim]

1 minute ago, requinix said:

1. It clutters the session. If you have a lot pages storing their arbitrary data in there then you start to lose track of what values are in there and why. It's the same problem as with global variables.
2. Making sure the session is clean of old data can be hard. Consider if someone browses through the quiz and then stops partway: what happens to the data? It stays in there until something either overwrites it or removes it (like doing another quiz) so the longer a user is on the site and the more they don't conform to the expected behavior for a user, the more data piles up.
3. Upgrading users through data changes becomes a problem. If the quiz works one way for a long time and then it's changed to work differently (requiring the session data be stored differently) then you have to worry about users with long-lived sessions who have old data still in there.
4. It is actually slower to some degree. Every time you fire up the session, PHP has to deserialize the entire session from its cache, and if there are large chunks in there you don't care about then it is wasteful.

Thank you very much for that.  As a layman, I would have had no idea the scope of working with session storage and it's pitfalls.