How to implement advanced session processing in PHP

Question

I work with sessions in PHP and I have different applications on the same domain. The problem is that cookies are domain specific, so session IDs are sent to any page in the same domain. (I don't know if there is a way to make cookies work differently). In this way, session variables are visible on every page of this domain. I am trying to implement my own session manager to overcome this behavior, but I'm not sure if I think about it correctly.

I want to completely exclude the PHP session system and create a global object that will store the session data, and at the end of the script store it in the database.

• On first access, I will create a unique session_id and create a cookie
• At the end of the script, save the session data with session_id, timestamps for the start of the session and last access, and data from $ _SERVER, such as REMOTE_ADDR, REMOTE_PORT, HTTP_USER_AGENT.
• In each access chceck database for session_id sent to the cookie from the client, check the IP, port and user agent (for security) and read the data in the session variable (if not expired).
• If session_id has expired, delete from the database.

This session variable will be implemented as singleton (I know that I am getting a tight connection with this class, but I do not know about a better solution).

I am trying to get the following benefits:

• Session variables invisible in other scenarios on the same server and in the same domain
• User session expiration control
• A way to view open sessions (something like a list of online users)

I am not sure that I do not notice any flaws in this solution. Is there a better way?

Thanks!

UPDATE: I did not explain this in sufficient detail and caused a lot of confusion here, so I want to clarify what I mean:

I am creating an SOA server application that will be deployed in many different environments. It will not have its own web server, so there may be other PHP applications in those environments. Employees of these companies will have user accounts in this application, so they will receive a cookie with a session identifier in this application.

As you know, a web server working with PHP when loading session data does not differ (at least by default) that the script from which the directory is created. All he needs is a session identifier. This session identifier is sent with each request from the client to the server. From your answers, I got a way how PHP can limit cookies to a specific directory, but a malicious user can edit cookies because it is stored on his computer. In my case, a malicious user may have write and execute PHP script access in the same environment, although he does not have access to my application and its database. If he creates a script, he can use the session identifier from the cookie of my application, so he has access to read and edit session data in my application and gain access to parts of my application that he should not allow.

I see that when deploying the application in such an environment other security risks will appear, what I'm going to do is the best isolation that I could do, and processing sessions by default seems too dangerous and not intended for such purposes.

So my question is: if you see something that is less secure and less flexible in my design than it would be with session management by default.

Thank you for your responses,..

Answer 1

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 a "path" in each of your web applications.

Answer 2

Take a look at the session_set_save_handler method in PHP.

http://php.net/manual/en/function.session-set-save-handler.php

Well, to be actually correct, several companies take the approach of custom session handlers for multi-domain, distributed session / memory processing with database / memory support.

Answer 3

If you do not want to have problems with shared sessions, you can use the session_save_path function to set the path in which your application will save its session files. Since it will not be used by other applications on the server, you will not encounter problems sharing sessions.

Only one thing: make sure that the path to which you save the session files is not accessible from the Internet. Something like:

 /YourAppFolder /www (web accessible) / libs /config / session (where you put your session files) 

Answer 4

Here you can see:

• Set the path and domain of the session identifier. If the domain is .mastergaurav.com, cookies will be sent back to mastergaurav.com, www.mastergaurav.com, blogs.mastergaurav.com, etc.
• Maybe instead of using the session identifier as a cookie - if you really need to go through multiple domain domains - make it part of the URL for a fully customizable implementation:
  abcd.php?<?php echo session_name(); ?>=<?php echo session_id(); ?>&domain=<your-domain>

Answer 5

I want to completely exclude the PHP session system and create a global object that will store the session data, and at the end of the script store it in the database.

If you plan to serialize your objects, I do not recommend using them as reliable information.

http://www.php.net/manual/en/function.session-set-save-handler.php#81761

Take a look at the above example, it gave a good solution.

Maintaining state through domains.

• First create a unique identifier.
• You can create a cookie that will be read every time you access the page. On each page, access to the cookie is sent from the browser to the server.
• You can also pass in your unique identifier as part of every URL you create if you want to use a different approach instead of a cookie.

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 achieved by restricting access to crossdomain.xml.

• You need to study the encryption of your session, so that even if the user broke it, he could not use it. Data must be encrypted using private keys and decrypted using the public. The handshake is based on public keys.

Answer 6

I am not sure that I do not notice any flaws in this solution. Is there a better way?

its very difficult - and it won’t work, for example. remote_port will change between requests, remote_addr may change.

There are at least 2 very obvious solutions without reinventing the session:

1) use a different cookie name for the session in each application - see session_name ()

2) have each application in a different subdirectory (for example, http://example.com/app1/ , http://example.com/app2/ , ...) and specify the path to the cookie - see session_set_cookie_params or use different ini for session.cookie_path