How do you pass using SESSION variables

[nduarte]

I was recently posting information and using $_GET to move between pages. However, becasue of security concerns, I have to change this. How do you pass a SESSION variable to a new page from an array. Here is what I used to have

while($data = mysql_fetch_array($result))
{
  echo '<a href="viewpage.php/" . $data['id'] . '">';
}

because the id would be in the nav bar, I have to find a way to remove it. I wanted to use a SESSION variable, but if I just added creating a session variable to the array, then the targetpage.php would just get the last record created.

Any help?

[Will Gresham]

The session is a server-side temporary data store, you can initialise the session by putting session_start() at the top of any page you with so utilise the session data on.

Storing and retrieving information from a session is similar to _GET, they are both arrays of data.

$_SESSION['somedata'] = 'somevalue'; //Store data
echo"somedata is set to: " . $_SESSION['somedata']; //Get data

Nothing special, as long as you put the session_start on any page you want to use session data in, it will work (Session needs to be initialised before any output is made, to at the very top of the page is a good place.

[diafol]

ARe you talking about the 'address bar' as opposed to the 'nav bar'? I don't really follow what you're saying here. To use sessions, you have to place

session_start();

at the top of the page before anything can be output (including the DTD).

Where does targetpage.php come in? Is this the viewpage.php/xxx?

Do you have a list of viewpage.php/xxx pages or is it just one? It seems multiple from the loop, but the code below...

echo '<a href="viewpage.php/" . $data['id'] . '">';

...shouldn't work as you don't have any link content or a closing tag. All in all, it's a bit of a mess isn't it?

Have a think about what you're doing or trying to do and post back.

[Will Gresham]

Re-reading your post, session data is set by the server, you cannot set it on the page without the data being passed to the server, so you will still require use of _GET or _POST to send the data to a server-side script.
A redirection page may serve the purpose of abstracting the data from the URL, however, it will still need to be sent.
When you say 'security' what do you actually mean? Data passed to the server can be read regardless. If you are trying to stop people from altering the query string so that they get pages or information that they are not supposed to be able to access, then I would suggest you need some data checking on your current scripts. Never, ever, trust the data a client sends, always check it was what you were expecting.

[madCoder]

You are concerned that a user can alter the url to retrieve records they are not meant to access. Sessions are probably only a piece of the solution for you. You will need to pass a key in the request for the record. I think we need a better sense of the context of your problem to offer a solution or approach.

-- How do you currently know which records to show the user?
-- Does a user need to log in to see these records?
--- What uniquely identifies the user?

[benjaminFowl87]

The code you have written is fine however you are hoping to prevent users from viewing pages that they don't have access to.

You need to give permission to a user to view the page, this can be done by what you mentioned, using a SESSION variable

say you have a user that is an admin, he is allowed to view say page 1, on page 1 you would need code that checks that user is an admin user, if not, then don;t show them the page (access denied)

hope this helps, and is sought of what you meant.

[nduarte]

So here is what I have come up with. I decided to set it up as follows:

while($data = mysql_fetch_array($result)
{
  <form action="targetpage.php" method="post">
  <input type="hidden" name="userid" value="<?php echo $data['id']; ?>">
  <input type="submit" value="submit">
  </form>
}

Then on the receiving page i just use

$id = $_POST['id'];

The only problem I am running into now is that the first record that is returned from the array doesn't work, and it adds an extra line that makes the formatting of the first line look weird.

madCoder was right, generally what I am trying to do is to not allow the user to change a value in the address bar to navigate to an undesired page.

The problem with benjaminFowl87s idea is that it isn't a certain user type that can generally be used. For instance, I have 5 staff members, each staff member needs to be able to see certain people, but only people in their group. And since this is done dynamically via php scripts, we don't want them to change the id and be able to access another person.

Make sense?

Thanks!

[madCoder]

NDuarte, so what we've been eluding to is that you store the information that stays constant for a user into a session.

1. User logs in successfully
2. User id is stored into a session: $_SESSION['userId'] = $loginCheck['user_id'];
3. If they can only be a member of one group, assign the group id to another session variable: $_SESSION['group'] = $loginCheck['group_id']
4. When a record/page is requested that is restricted, query for the information including a restriction on group.

So as an example,

SELECT *
FROM clients 
WHERE client_id = '{$client_id}'
AND group_id = '{$_SESSION['group']}'

(This is a really simple query and you likely want to join to a group_members table or something. I'm keeping the query simple only to illustrate the point about how the session variable is used.)

***GROUP should be in lower-case in the above query. The parser is capitalizing it for some reason.

If the staff member tried accessing a client record that is not part of her group, the query returns nothing.

[Will Gresham]

The problem with benjaminFowl87s idea is that it isn't a certain user type that can generally be used. For instance, I have 5 staff members, each staff member needs to be able to see certain people, but only people in their group. And since this is done dynamically via php scripts, we don't want them to change the id and be able to access another person.

1 word. Permissions.

I will assume (bad thing to do, I know) that the data is coming from a database. Lets assume my assumption is correct.

You will need somewhere in the database to hold permissions, be that another column on a 'users' (for example) table containing the ID of the staff member responsible. Or, if there is more than one member of staff who should be able to access the details, possibly another table with multiple entries for staff/users:

id   staff_id   user_id
1    2          3
2    2          4
3    1          4
4    5          2

etc.

You should query this table, and only display the information if there is an entry in the database where the staff id and user id appear in the same row.

While you have removed the ID from the URL using the above mentioned methods, it is still absurdly easy to go into the source, alter the values in the HTML and submit the form with values other than those you supplied originally. Not secure. A will reiterate my above statement: Never, ever, trust the data a client sends, always check it was what you were expecting.

[cossay]

If the user has successfully logged in, assign the user's user name and password as below:

$_SESSION['user_id'] = $_POST['user_id'];
$_SESSION['password'] = $_POST['password'];

Now on every every page that you want only users who have logged in to access, you will write something like this:

<?php
session_start();

if(!isset($_SESSION['user_id']) || !isset($_SESSION['password']))
{
	//The user is trying to access a restricted page without first logging in so take the 
	//user to the login page
	
	header("Location:login.php");
}
else
{
	//The user in currently logged in.
	//Here you use the user id and password stored in the session array to do whatever 
	//you want, such as querying the database for any information relating to the user
	//whose  id and password are contained inthe session array.
}

?>

Warning: you should destroy session after a user has logged out.

session_destroy();

[nduarte]

That all makes a lot of sense, but it seems like a lot of coding. Here is the scenario:

I have a database that holds all the users. In the database, there are certain columns that, if they have a value of 1, make them admin, staff, etc. Now a staff member is in charge of a group. The group is made up of several people. When you click on a persons name, it takes you to a page and uses the user id in the URL to identify who's information should be retrieved. For instance: www.memberinfo.com/memberinfo.php?memberid=1. The memberinfo.php page searches the database for the user with memberid 1 and displays the info for that member. However, with it being in the address bar, you can easily change the 1 to a 2 and display someone else's information. So while everyone has permission to view that page, only a few have the option to view that particular member info.

So by coding it as indicated above, I would have to individually create a page for each member and provide access to only certain staff members. That is a lot of work.

[madCoder]

I agree with cossay about testing the $_SESSION on each page (this is usually an include() or require()) but there is no need to store the password in a session. At some point you may need to debug something in a live environment (you shouldn't, of course, but emergencies happen) and you might do something like print_r($_SESSION]); which will reveal passwords.

[diafol]

POST is no better than GET. Anybody can 'spoof' a form.
Simply just check the rights of the logged in user to access the record of another member of staff. Your DB will have some sort of link table where the staff id and user id are placed. As Will stated:

id   staff_id   user_id
1    2          3
2    2          1
3    1          4
4    5          2

Is the way to go. Trying to cobble some session stuff doesn't make much sense here.

The validity check simply takes the logged in id (staff id) and checks to see if the record of the requested user id is allowed. Simple.

[Will Gresham]

That all makes a lot of sense, but it seems like a lot of coding.

Not really, although if it were simple and quick to make a secure script, then everyone would be doing it.

So by coding it as indicated above, I would have to individually create a page for each member and provide access to only certain staff members. That is a lot of work.

Again, no.

Lets take an example I have knocked up quickly, replace any comments with relevant code. Note this isn't a copy-paste job, it will still require work. This will be the basic design for the 'memberinfo.php' page, I'm going to leave the previous page to you and assume that the memberid is still sent in the GET.

<?php
session_start(); //Start the session

/* Ideally this chunk should be done on another page when the staff member logs in, not on every page.
//Insert SQL statement here to get the staff

$_SESSION['id'] = $mysql_result['id'];
*/

$memberid = $_GET['memberid'];
$staffid = $_SESSION['id'];

// Sample SQL to check permission: SELECT * FROM `permissions` WHERE `staff_id` = $staffid AND `member_id` = $memberid

if(mysql_num_rows($permission query) == 0) {
  // Display an error, the staff member is not allowed to view this
} else {
  // Insert code to display info
}

?>

As I said, this will require some thought and modification on your part, I don't believe providing you with all the code will benefit you in any way. Read through that and by all means ask if you don't understand something, but hopefully it is fairly clear.

Also, note that there is no error checking in this, for example: on the values in GET, you should be validating that the value in the query string is correct (In this case, a number)

Sample of table 'permissions'
id: int, auto-increment, key field
staff_id: int
user_id: int

id   staff_id   member_id
1    2          3
2    2          1
3    1          4
4    5          2

[nduarte]

I appreciate the response Will Gresham. I will definitely be able to use that. So the general consensus that I am hearing is that I should use a table to set permissions for each person and then check to see if the user has the apropriate permissions at the appropriate page.

To get the users in the script, is there a generally smart way to do it or should I create an option on each member page to add a user to the list of permissions for an individual?

Thanks again!

[Will Gresham]

If you implement a permissions table, then you will need to add 1 new row for each relationship.

How/where you implement this is up to you, wherever it fits best in your site, or even on a new page entirely.

However, this should follow the same guidelines, only allow people who should be able to assign the permissions access to it.