Is there anyway of hiding the details of a url sending variables that are retrieved using $_GET? As the url is visible to users, and could be typed in manually or bookmarked, they could get to a page they shouldn't be able to at certain times.
you could - use sessions instead - use cookies - create a function to encode / decode variables or commands
I dont think cookies or sessions will work; during one login, a user could click on several different links, each of which would use the same php file, but with different results depending on which link is clicked, hence the use of the GET variables. Can you suggest any links to instructions on how to create the function to encode and decode the variables?
If you really want to stop them from seeing particular pages... use a login/registration system. To hide obvious variables use mod_rewrite to discourage experimentation. Can you explain your needs in a little more detail?
Users are already logged in. What it is, is a game played by registered users. I am modifying an exsting program. I want users in certain zones to click on a link, and then be taken to a map specific to that zone, which is what using GET will do. However, if the players can see the variables in the URL, they could enter them manually; basically cheating.
hmmmm ... how bout making a hash on the URL string elements ... then append a random key .. save the key to your server session ... does it make any sense ?
not sure i understand what you mean... can't session variables be used? whatever you can pass over to another page using $_GET, you should be able to do so using session variables... care to elaborate further?
hehe not sure either why he said that ... but anyway for his satisfaction here is one encryption function from PHP manual ------------------------------------------------- crypt (PHP 3, PHP 4 ) crypt -- One-way string encryption (hashing) Description string crypt ( string str [, string salt]) crypt() will return an encrypted string using the standard Unix DES-based encryption algorithm or alternative algorithms that may be available on the system. Arguments are a string to be encrypted and an optional salt string to base the encryption on. See the Unix man page for your crypt function for more information. If the salt argument is not provided, one will be randomly generated by PHP. ------------------------------------------------- example on how to use that is below <?php $password = crypt("My1sTpassword"); // let salt be generated # You should pass the entire results of crypt() as the salt for comparing a # password, to avoid problems when different hashing algorithms are used. (As # it says above, standard DES-based password hashing uses a 2-character salt, # but MD5-based hashing uses 12.) if (crypt($user_input, $password) == $password) { echo "Password verified!"; } ?> Code (markup):
I'm not sure if that will work, and reading back it looks like I've been having problems properly explaining things, so I'll have another go at it. Users are playing a phpBB based rpg game, where they can move around from zone to zone using a file called adr_zone.php and it's associated template. In each zone, it is possible to have a number of graphical representations of links (buildings) which are stored in a MySQL database. In a number of the zones, there will be a link to another file, dungeonnav.php which will have a number of variables added to the URL to define which map the user is sent to and where there character is located on the map, eg dungeonnav.php?mapid=4&xpos=1&ypos=3. This data is stored in and called from the MySQL database, and isn't a permanent link from the adr_zones.php file. Different zones will have different values in the URL variables. Does this make things clearer?
If you want to do it right you have to implement a check on the destination page that verifies if someone is allowed to do something. Security through obscurity is wasted time.
Thing is, the only way I can think of passing on the required information to show what the user is allowed to do is in the URL. The destination page is the same in every case, just the variables are different. If I had different destination pages, it would still have the same problems, as the different URLs would be shown.
as was talked before, make a check - in any case, if you will crypt variables, the hole will not be closed, understand me? this hole will be hidden, but it will be. So checking inside the script what user could access and what couldn't
I'm still not sure on how to do this. The only way of ensuring that the user gets to the right map, is by sending the information in the URL. The pages are dynamic, and what the URL is depends on which zone number the user is in. I don't think it's possible to add checks for every single map that the user could go to without making the code unwieldy, ie check for map1, map2 etc all in adr_zones.php. Or am I missing something?
If people can just type in the URLs they can cheat your system regardless. We don't know your system, so you have to figure out how you want to do that check.
If they can't see how the url is put together, they won't be able to cheat the script, because I can change the names of the variables being passed with the GET command. I just can't find any easy way of hiding them that would work for all instances of the command. It would be possible to do on a case by case basis, I think, but that's far too messy and complicated.
Given enough time security based on obscurity WILL be defeated, there's no point in denying that. You must have some check that only gives the user the correct links, right? So adapt that check for the destination pages. You MUST do this if you want to prevent people from cheating.
I can add a check that only allows users to access dungeonnav.php in the zones it is available; however, unless I add a check for every single map that can be accessed through that page, they will be able to access any map they want if they know what the posted variables are. Is it possible to do something along the lines of: if (dungeonnav.php link is clicked) execute a script that will hide the variables both in the address bar and the onmouseover
Forget about security through obscurity already. You can put the variables there, but if you don't check them the system will get abused. Understand that already for the love of God.