Forum Moderators: coopster

Message Too Old, No Replies

Odd string written in a session

keeping sessions in table

         

gasell

2:06 pm on Sep 20, 2008 (gmt 0)

10+ Year Member



I'm keeping sessions in a database like described here: [shiflett.org...]

However once in a while instead of usual "variableName¦s:5:"value";" pattern I find that in the data column there's a alphanumeric string. I'm clueless how such a thing happens. Any ideas?

eeek

12:06 am on Sep 21, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I'm keeping sessions in a database

Ok, but I have to ask why you are doing this.

I find that in the data column there's a alphanumeric string.

Are you escaping the strings you feed to the database?

henry0

5:37 pm on Sep 21, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I'll be interested too in knowing why you need such an implementation

However a few items I picked up:

It adds security (data in a DB are more secured than in a flat file) I mean if someone breaks in your scripts and if your db conn is away from root the breaker should no be able to mod your db

It will help if you need to load sharing

You have an easy access to session content from your db thus helping in debugging

The above is a digest of what I once read while enquiring on the topic
But there is more…

eeek

7:38 pm on Sep 21, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



It adds security (data in a DB are more secured than in a flat file)

Snort! You are much more likely to be exploited by SQL injection than having someone able to remotely read the session files.

It will help if you need to load sharing

So will NFS (or other network file sharing method).

What it mostly gives you is complexity. If adding complexity doesn't get you something you need, why do it?

eelixduppy

7:44 pm on Sep 21, 2008 (gmt 0)




You are much more likely to be exploited by SQL injection than having someone able to remotely read the session files.

This is not true for shared hosts; it's actually VERY simple on a shared host to read the session files on the file system with a simple script since all of the session files are kept in the same location for everyone. On a shared host, if you want any real sense of security, you should be storing your session information in a database.


What it mostly gives you is complexity. If adding complexity doesn't get you something you need, why do it?

If anything it makes it easier to keep track of sessions, plus allows you to expand upon the session information for your own personal needs. Not only is it more safe, but you use it in EXACTLY the same way that you use regular sessions so your code wouldn't even need to change if you wanted to have this implementation, you would just need to set the session handler and you're done.

As for a random string showing up in your DB, it might have something to do with your code somewhere. Maybe for certain cases you didn't account for? Not sure, it's going to take some investigation to get to the bottom of it on your part.