views:

39

answers:

2

Hi,

I have multiple web applications (PHP) which are being served to different customers from their own domain. Each domain obviously has separate cookies and sessions (with the domains and paths all set correctly).

Should I need to set up a completely separate sessions table in the database for each website to try to ensure unique sessions? I'm guessing that I don't need to, because if we were using file-backed sessions, then each server uses the same session-store. So I'm guessing that with a DB-store I can just re-use the table too.

It is just that with the session code (I am using ADODB), I can not see any code to handle a session ID collision during session create.

+1  A: 

It won't cause your application any problems, however, just for the sake of security I would use different tables unless consolidating all sessions is part of some feature on your site.

I haven't done it before, but I really do not think there would be any problems.

Laykes
A: 

You can modify a session id to include a short site prefix. Just modify your create session to call session_id($new_id) before creating a session.

This will also allow you to list all current sessions per site searching for the prefix. More optimal solution would be to split a session key in two fields, indexed both by prefix and by the unique key,prefix index. You will need to modify your session create function in order to implement this.

You can even validate by this prefix and reject session if tied to the other web site improving the security.

Otherwise if your session id is properly generated you should not have problems with collisions.

Goran Rakic
Not an answer, but close enough. I haven't tried it but setting a session id prefix may work. It would need something like session_id($prefix.session_id()) and according to the php.net page doing this will cause problems with session cookies too. I figure that the last sentence is the most important.
brofield