How to read session values form another session instance in PHP?

Question

Hello guys,

I am doing something in PHP where I have to read session values for another session instance. example

Browser1: $_SESSION['value']="user1";

Browser2: $_SESSION['value']="user2";

Browser1 will need to get "user2" value from certain request. The request will also include cookie(key, value).

How can I do that?

Thanks, Wa'el

Answer 1

You will need to use create some sort of data storage system that is accessable to all users of your application. Cookies & Sessions are limited to the current user/browser.

A database or file is an example of what you need to use.

Answer 2

The default session storage is a file. You can access each file like you would access any other file. Session data is encoded and must be decoded before you can use it. There is a number of solutions for this in the comments for

• session_decode - session_decode — Decodes session data from a string

Answer 3

1 PHP server that handles SSO(single sign on) the other is a web applicarion runs on ruby on rails(ROR)

[...]

but we need to implement new functionality where the ROR server needs to submit an authentication request at the SSO on behalf of the browser

Your SSO model doesn't need to work that way. In fact, it shouldn't.

SSO usually works like this. I'm using non-standard names because I'm tired and don't remember what their official names are:

• End User: The dude with the browser that needs to log in.
• Page Server: The site the End User is trying to log in to.
• Authentication Server: The site that actually owns the master version of the End User's data.

1. End User requests a page from the Page Server.
2. Page Server checks End User's existing login status. If the End User isn't logged in, the Page Server redirects the End User to the Authentication Server with a unique token.
3. The Authentication Server gets the request from the End User with the unique token. It does whatever it needs to do in order to log the user in.
4. Once the user is logged in, the Authentication Server sends the End User back to the Page Server with another, different, unique token.
5. The request the End User makes to the Page Server causes the Page Server to make a request to the Authentication Server. The request includes both the original unique token and the another, different, unique token.
6. The Authentication Server responds to the Page Server with information about the user, or an error message if the tokens are invalid. Once user data is retrieved, the tokens are invalidated by the Authentication Server. (This prevents request replay. By the way, you should be using SSL for this entire process.)
7. The Page Server logs the user in and stores whatever information it needs to about the End User.

At no point does the Page Server "impersonate" the End User, and at no point do the Page Server or the Authentication Server need to touch each other's End User session data.

At no point does the Page Server get a copy of the user's credentials. Actual authentication of the End User only happens on the Authentication Server. The Page Server requests data about the user after the Authentication Server bounces the user back with the proper request token.

You can make this process more complex, if you'd like. For example, the URL that the Authentication Server bounces the user back to might need to be customizable. You can include the return URL with the End User request to the Authentication Server, but if you do so, you should sign it (using, say, HMAC) to ensure that some malicious cretin doesn't manipulate it on the way.

Clear as mud?