i'm working with sessions in PHP, and i have different applications on single domain. Problem is, that cookies are domain specific, and so session ids are sent to any page on single domain. (i don't know if there is a way to make cookies work in different way). So Session variables are visible in every page on this domain. I'm trying to implement custom session manager to overcome this behavior, but i'm not sure if i'm thinking about it right.
I want to completely avoid PHP session system, and make a global object, which would store session data and on the end of script save it to database.
That session variable would be implemented as singleton (i know i would get tight coupling with this class, but i don't know about better solution).
I'm trying to get following benefits:
i'm not sure if i'm overlooking any disadvantages of this solution. Is there any better way?
Thank you!!
UPDATE: i did not explain it in enough detail and caused a lot of confusion here, so i want to make clearer what i'm dealing with:
I'm building SOA server application, which would be deployed in many different enviroments. It won't have it's own webserver, so in those enviroments there could be another PHP applications. Employees of these companies will have user accounts in this application, so they will obtain a cookie with session Id into this application.
As we know, webserver running PHP when loading session data doesn't make difference (at least by default) what script from which directory created session. All it needs is a session ID. This session ID is sent with each request from client to server. From your answers i got a way, how could PHP restrict cookies for certain directory, but malicious user is able to edit cookie, because it's stored in his computer. Malicious user in my case can have access to write and execute php script in the same environment, although not having access to my application and it's database. If he create a script, he could use Session id from cookie of my application, thus he has access to read and edit session data on my application and gain access to parts of my application, that he shouldn't be allowed to.
I see there will be another security threats in deploying application in such environment, what i'm going for is the best isolation i could do, and default session handling seems too dangerous and not designed for uses like this.
So my question is, if you see something, which is less secure, less flexible in my design, than it would be with default session management..
Thank you for your answers,..
Have a look at the method session_set_save_handler
in PHP.
http://php.net/manual/en/function.session-set-save-handler.php
Well, to be factually correct, several companies use the approach of having custom session handlers for multi-domain, distributed in-memory/database backed session handling
I want to completely avoid PHP session system, and make a global object, which would store session data and on the end of script save it to database.
If you are thinking of serializing your objects, i wont recommend as its not a good practice to hold secure details.
http://www.php.net/manual/en/function.session-set-save-handler.php#81761
Have a look at the above example, he has given a good solution.
Maintaining your state across the domains.
Update:
First you need to restrict users to your application based on IP address, if you want to make it more secure which can be achived through crossdomain.xml restricting users.
You need to look into encryption of your session so that even if the user breaks it up he could not use it. Data should be encrypted with private keys and decrypted using public one. The Handshake is based on public keys.
You need to use:
session_set_cookie_params()
http://www.php.net/manual/en/function.session-set-cookie-params.php
In particular you need to set the "path" in each of your webapps.
i'm not sure if i'm overlooking any disadvantages of this solution. Is there any better way?
its very complicated - and its not going to work, e.g. remote_port will change between requests, remote_addr may change.
There's at least 2 very obvious solutions without reinventing the way session handling works:
1) use a different cookie name for the session in each app - see session_name()
2) have each application in a different sub directory (e.g. http://example.com/app1/, http://example.com/app2/, ...) and set the path on the cookie - see session_set_cookie_params or use different ini setting for session.cookie_path
If you don't want to have problems with shared sessions, you can use the session_save_path function to set a path where your application will save its session files. As it won't be the one used by other apps on the server, you wont run into session sharing problems.
Only one thing : make sure the path you save your session files in is not accessible from the web. Something like :
/YourAppFolder
/www (web accessible)
/ libs
/config
/ session (where you put your session files)
Here's what you can look into:
abcd.php?<?php echo session_name(); ?>=<?php echo session_id(); ?>&domain=<your-domain>