<?php
session_start();
// Require encryption file
require("/functions/encryption.inc.php");
// Query for all active facilities alphabetically
$query = "SELECT id, name FROM facility WHERE active ='y' ORDER BY name";
$result = mysql_query($query, $con);
// Loop through all facilities
while($row = mysql_fetch_array($result)) {
// Only display facilties where you have rights
if(allowedToGo($row['id']) {
echo('<a href="http://www.me.com/showFacility.php?'.
encrypt($key, 'facility='. $row['id']) .'">'. $row['name'] .'</a><br />');
}
}
How many facilities are there? Could be 9, could be 4261. How big is your one time pad? You want to store all of those variables in the session when you'll only ever need one of them? That just seems like an enormous waste of space (and work) to me. And if I come back at a later date to add a feature, I have to waste time coding the one time pad and all of that. With the encrypted URL, you don't have to do that. Just encrypt() or updateURL() whatever you want to add, and it just flows to the target nice and neat.
What I want to prevent is someone typing in "?facility=7" when they don't have rights to view that facility, or 'startDate=1950-13-92' and causing something strange to happen on a page that was written by our jr. programmer. Obviously, they won't be able to do either with your one time pad example either.
Also, by doing it with an encrypted URL, you can't even see what the variables are, let alone change them. I could pass "lukesFather=DarthVader" and you would have no idea. By the way, I could also pass "lukesFather=Darth Vader" and because of the way I'm setting up the URL, it would work just fine even with the space.
Encrypting the URL also prevents people from adding their own variables to the end of a URL to try to affect what happens on the page. I know it's bad programming practice to not initialize variables properly and all of that, but when you're working with somewhat less skilled programmers like I am, this gives me nice peace of mind knowing that our users can't take advantage of a hole like that.
And no, session variables don't have to be constant throughout the session. They just have to persist (until you destroy them).
Of course, you're right about that. I mis-spoke on that. Sorry, I think I was still half asleep. 
