Passing data through sessions

I don't to let the user edit some unique ids, when I pass it through $_POST so I'm using $_SESSION instead, because as far as I know, a session can not be edited.

Is that a good & safe solution? Offcourse I'm unsetting it after reading.

I want to be sure, so thats why I'm asking.

Some code where I'm doing it:

if(!isset($_POST['save'])) {
     $posts = $_POST['special_ids'];
     [..]
     $_SESSION['posts'] = $posts;
     echo "<input type="hidden" name="save" value="1"/><input type="submit开发者_StackOverflow" value="Submit!"/>";
     [..]
} elseif(isset($_REQUEST['save'])) {
     //then I'm reading the $posts
     $posts = array($_SESSION['posts']);
     [...] //doing what I need with it.
     unset($_SESSION['posts']);
}

If you define the values on the server and don't want to allow the end user to edit them it is definitely safer to use $_SESSION rather than sending them to the client, and getting them back again as, yes, they could have been tampered with.

It's not possible, short of server vulnerabilities, for a client to alter their session values directly.

I think this is a good Solution. I don´t now your Framework and your specific requirements perhaps its better to save only a reference to a User in an Database and save the Data in the DB and write a function to get the Values.

But for the most applications this will be a working Solution.

What is the data that you are passing around?

In general, session should be used ONLY for data that should "float around" indefinitately. It should not be used as an "easy" way to pass data from one screen to another.

If you have data associated with the user's login in general, that would be applicable to many many screens in your app, like his account number or zip code or some such, then session data is an appropriate place to keep it.

But if you have data that you want to pass from one screen to another, session is a really really bad place to keep it. This is especially true if the data controls program flow. This is so for all the reasons that global data is dangerous and then some.

First, in a web app you have no control over what the user will do next. He may click the Submit button, or he may hit the browser back button, or he may type in the URL of some entirely different page in your app. You say you will clear the session data after using it, but how do you know you will even get to the screen where you clear it? You have no way to force that to happen. Suppose your intent is: The user brings up screen A and clicks submit. You save something he entered in session and then display screen B. When the user clicks submit, data entered on B plus the session data is processed by screen C. Now instead the user brings up screen A and clicks submit, then when screen B displays he types in the URL of screen D. Half an hour later, after visiting many many other pages, he enters the URL of screen C. The session data is still there. What should happen? This gets even worse if your program checks for the presence of the session data and gives a different display depending on whether it's there or not. Like what if you say that you display screen A, collect the session data, and then go to B. But your program does this by saying that when program A is displayed, if the session data is present that must mean we were already here so go to B, otherwise stay on A. I've seen lots of programs that work like this. Then if the user presses browser back or types in a URL, this session data is left behind, and the next time he tries to come to screen A, he is magically and mysteriously transported to screen B without having entered anything.

Second, it creates a maintenance nightmare. Six months from now you come back to maintain this program. You see a program picking up data from a session variable. How did it get there? What program put it there and under what circumstances? Who else is reading it? When? When you pass a value to a subroutine as a parameter, you can easily see exactly what is passed, when, and how. But when you use global data like session variables, it's all a mystery.

Global data may seem like the easy way out of complex data-passing scenarios. But it's a trap.

Well, I don't know exactly what the data is that you need to pass around or how it will be used, so the above may or may not be relevant to your case.

Clarification in reply to Matt

Session data should be used for data that is associated with a SESSION, as opposed to data that is associated with a single transaction, i.e. a single round-trip to the server. So for example, if you have data about the user, like an account number or what time zone he's in, that's reasonable to keep in session data. But data about a particular transaction, like what record is being updated or an error message being sent back, should not be kept in session data.

If you have to be sure to clear a session variable right after use because otherwise the next transaction will process incorrectly, then this shouldn't be in session data. Because it is somewhere between difficult and impossible to guarantee that the data will be cleared.

Not only are "other routes" possible, but they are impossible to control. You have no idea what URL the user may type into the browser. In principle, I guess you could make every single page in your application check for every session variable that you ever set anywhere, somehow figure out which ones shouldn't be set when coming to this screen, and clearing those. Then any time you create a new session variable you've got to update every screen to add this one to the list. Okay, it could be a common function, so you wouldn't necessarily have to update a hundred screens every time a new session variable is added. But you'd still have to remember to update this function and properly check for all session variables. Why create a maintenance headache? Just don't do it.

Even if you can make it work, you still have the global data problem. Global data is bad.