I'm seeing a problem where some $_SESSION variables are passed from one page to another, and others are not.

The session is setup on login, with user identity held in $_SESSION["id"]. At a later date, I want to shift the identity to another, subordinate account. The change is handled by a simple form that is processed by the following snippet:

<?php
// $_SESSION["id"] is initially 2
if (isset($_POST["id"]))
{
	$member = cMember::retrieve($_POST["id"]); // pull new user object from DB
	$_SESSION["foo"] = $member->getField("me_id");
	$_SESSION["id"] = $member->getField("me_id");
	$_SESSION["bar"] = $member->getField("me_id");
	redirect("blank.php?".$_SESSION["id"]); //redirect($dest);
}
?>

and $_SESSION["id"] is being properly set, because it turns up in the URL used in the redirect. It does not come across as a session variable in blank.php, however.

<?php
include("incl/page_header.php"); // includes session_start()
echo "BEFORE HACK:<br>"
print_r($_SESSION);
if (isset($_SESSION["bar"]))
	$_SESSION["id"] = $_SESSION["bar"];
echo "AFTER HACK:<br>";
print_r($_SESSION);
include("incl/page_footer.php");
?>

The part that's odd? The output from blank.php is (after some editing cleanup):
BEFORE HACK:
Array ( [id] => 2 [foo] => 4455 [bar] => 4455)
AFTER HACK:
Array ( [id] => 4455 [foo] => 4455 [bar] => 4455)

In short, $_SESSION["bar"] is set and passed correctly. $_SESSION["id"] retains its old, pre-page-1 value, and doesn't reflect its new value until it is set in blank.php

Thanks for any and all ideas.

Jack

Hi,

In the first snippet where you are redirecting.

redirect("blank.php?".$_SESSION["id"]);

I think you wanted it to be with id=$_SESSION

redirect("blank.php?id=".$_SESSION["id"]);

Hope it helps.

Member Avatar for diafol

Also putting it in a url is dangerous - you display the data to the outside world. I didn't see a single $_GET in your code.

Do you really want ids to be passed (form or url)? Seems mightily unsecure to me. What's stopping somebody spoofing the form or changing the url to change to somebody else's id?

Also putting it in a url is dangerous - you display the data to the outside world. I didn't see a single $_GET in your code.

Do you really want ids to be passed (form or url)? Seems mightily unsecure to me. What's stopping somebody spoofing the form or changing the url to change to somebody else's id?

Thanks for your reply. Yes, posting the id in the open as a GET argument would be a huge security hole. I included the GET argument in this example code as a quick way to assure myself that the value was correctly set at the time of the redirect. The actual script relies on POST params and md5() to provide some level of security.

Member Avatar for diafol

OK, I'm a little confused as to why you need to change the id. This is for the currently logged-in user right?

OK, I'm a little confused as to why you need to change the id. This is for the currently logged-in user right?

Right. The application is a gift list site, and $_SESSION["id"] tracks the authenticated user identity. The problem is that the user can have subordinate accounts -- for their kids, for example. These second-level accounts are accessed through the same login credentials, as the kids often lack the email address that we use for a login string. I want the parent to be able to shift to and from their kid accounts, so their $_SESSION["id"] will need to change in the course of a site visit.

The thing I don't understand is why $_SESSION["id"] is being handled differently than $_SESSION["anything_else"]. I can swap and toggle other session variables without a problem; unfortunate naming conventions aside, $_SESSION["id"] is not the session id, but merely a variable set for the session.

Thanks for your interest.

Member Avatar for diafol

OK, that's a tricky one (for me!). I think if I was approaching this, I'd have:

$_SESSION as my user_id from login

I'd also have $_SESSION to allow me to peruse any associated accounts with my main one (e.g. children).

That way the 'id' is consistent and should be easy as an 'anchor' for swapping between many different children.
Just an idea.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.