I'm currently switching from PHP's built-in session management based on the filesystem on the server and stuff like $_SESSION and session_start() to my own approach (I know there are frameworks out there like symfony etc., but my application will most likely do the same of the very basic stuff and no more is needed, so it's not necessary in my point of view to rely on an extension for this).

I'm simply planning on using the traditional session management approach (

To use this approach efficiently, I was looking for a way in PHP to pass data to a variable that lies in a scope that is available for all callbacks called during runtime, but still somewhat scoped / protected. Just like $_SESSION or any other superglobal, but additionally fulfilling the following criteria:

• Data / Array key collision chances must be minimal; so the variable is ideally empty by default
• The used variable should not be linked to any additional storage system, such as $_SESSION is tied to the server's filesystem (or whatever you specify in your session handler)
• The used variable should exclusively be used for that, only be available for the calling script, and die after the runtime of the script

Considering all of this, I am currently thinking of using something like $_ENV[prefix_udata], populated with the data gathered from step 4a of the image from each request. This would avoid that I would need to add extra code or an extra parameter to all of my callbacks by simply replacing stuff like $_SESSION['uid'] with $_ENV['uid'] and so on.

I just wanted to double-check that $_ENV is not tied to external storage systems, is exclusively available on runtime, and exclusively to the running request. My research let me conclude that that's the case; but better double-check..?

CodePudding user response：

You cannot create your own superglobals, and each of them has a defined purpose - $_ENV is for values passed from the "environment" of the script, such as information provided by the web server. It doesn't seem like a good idea to re-use one for a different purpose, just to take advantage of its special scoping rules.

However, you can create normal global variables, and access them either using the global keyword or via the $GLOBALS superglobal.

So if you make a global variable called $my_session_array, you can simply replace all code like $_SESSION['foo'] with $GLOBALS['my_session_array']['foo'], and there's no need to abuse superglobals intended for other purposes.

Another alternative would be to use a static property on a class. Like a global variable, a public static property can be accessed from anywhere within the request.

For example if you define this:

class MySession {
    public static $sessionData = [];
}

Then you could replace $_SESSION['foo'] with MySession::$sessionData['foo'].

Both approaches have all the problems associated with shared global state - code using it is generally harder to test and debug than code that is defined in terms of explicit inputs and outputs.