db, SESSION, and security!
Permalink
Hi, maybe a dumb question but here goes...
I've got a test model with a testID and a testValue. I'm using the 'extends Model' approach.
Now to keep the object persistent, I store the objects testID in the $_SESSION. Then for sets and gets I pull the testID back out of the $_SESSION and load in the object from the db.
2 questions:
1) Is this the best (most common whatever) way to do it?
2) Can a user modify $_SESSION variables?
I ask coming from Ruby On Rails where I didn't have to deal with it because even though persistent data is readable it is checksumed so if the data is edited localy the action will fail. (so a user can't change userID=someotherUserID, or sessionID=someoneElsesSessionID)
So I guess my question #2 is really "Is forgery protection built in to Concrete5, or is it something I need to implement on a per controller basis?"
Whew! I look forward to working with concrete5, I really like your marketplace idea, and plan on developing for it.
Cheers,
-Bradley Beach
I've got a test model with a testID and a testValue. I'm using the 'extends Model' approach.
Now to keep the object persistent, I store the objects testID in the $_SESSION. Then for sets and gets I pull the testID back out of the $_SESSION and load in the object from the db.
2 questions:
1) Is this the best (most common whatever) way to do it?
2) Can a user modify $_SESSION variables?
I ask coming from Ruby On Rails where I didn't have to deal with it because even though persistent data is readable it is checksumed so if the data is edited localy the action will fail. (so a user can't change userID=someotherUserID, or sessionID=someoneElsesSessionID)
So I guess my question #2 is really "Is forgery protection built in to Concrete5, or is it something I need to implement on a per controller basis?"
Whew! I look forward to working with concrete5, I really like your marketplace idea, and plan on developing for it.
Cheers,
-Bradley Beach
1) Rails just did it that way (behind the scenes) so I figured it was the "general" best approach.
2) Is that something I'm going to have to code my self, or is there a config setting for Concrete5 that will make it use the db as a session store?
It's weird moving to php after RoR, I feel like I have a ton more control but also feel like I have to micro manage everything. I guess if there was a perfect programming language we'd all be using it.
2) Is that something I'm going to have to code my self, or is there a config setting for Concrete5 that will make it use the db as a session store?
It's weird moving to php after RoR, I feel like I have a ton more control but also feel like I have to micro manage everything. I guess if there was a perfect programming language we'd all be using it.
It is mentioned here that Concrete5 saves SESSION data to the temp directory. It is also asked is there any way, prehaps a config setting, to make c5 store SESSION data in the database?
This thread stopped running 5 years ago so I am asking this question again. I hope that this thread gets picked up again and an answer is forthcoming.
This thread stopped running 5 years ago so I am asking this question again. I hope that this thread gets picked up again and an answer is forthcoming.
1.) Sure. you could also simply serialize the entire object and deserialize it and it might save you a bit of overhead, but you'd have to test for it and also depends if the data the model is grabbing is subject to change? You don't want out of date data so your current approach makes more sense.
2.) Not really, but depends on the app. Sessions are stored as text files in the temp directory unless specified otherwise and those can be shared between domains, so it is generally better to have the session in the db. If you don't provide an interface through which someone interacts with the session id or not having the form encrypted string pairs utilized (namely not using the form vault token for a form method) or using some querystring [$_GET] value verbatim as this session lookup value you should be ok.
Hopefully others will chime in as those are my thoughts and i'm still relatively new to php and haven't delved a ton into security.