I am currently passing variables across via hyperlinks for example

http://www.nameofsite.com/page.php?home=234&name=ade

When these variables get sent to the next page this url appears in the address bar and in the users history later, I can see this as potentially dangerous later on, especially if it involves updating a database.

What I wanted to know is if there is a way to pass the variables across pages so that are not displayed in the users address bar?

I know that if you use a standard Submit button this is not the case, I just wanted to know is if you can do this via a standard url.

    Well yes, if there is another way Id like to hear it.

      ok no problems. Will check out sessions. Thank you for your help.

        Using JavaScript you can submit a form with the values you want to send. The JavaScript function would be called via a link. I have seen this being implemented before - it may be browser dependant though.

          Originally posted by PHPMagician
          Using JavaScript you can submit a form with the values you want to send. The JavaScript function would be called via a link. I have seen this being implemented before - it may be browser dependant though.

          It also relies on the client using Javascript, and on the assumption that the data will not be altered while stored on the client.

            Originally posted by Weedpacket
            ... and on the assumption that the data will not be altered while stored on the client.

            I don't really see how that is more of a concern than when passing the data via get. The JavaScript basically gives the impression of clicking a link but really submits a POST form - basically, it makes the URL in the address bar look prettier because there is no query string appended. Alteration of data is always an issue when the data originates from the client - no matter COOKIE, GET or POST. Some are easier to modify than others though - someone with little knowledge of HTTP may not know how to alter a cookie. This should not be relied on for security. I don't really see the problem in GET in these circumstances: sensitive data should not be passed to or from the script, and proper validation of all input should mean less concern over the query string being displayed to the end user.

            I don't really recommend this method - if you don't want to use GET, don't. Come up with an alternative and standard method of communication. However, it is a quick hack that can be used.

              I don't really see how that is more of a concern than when passing the data via get.

              I think Weedpacket didnt mean to make a comparison between GET and POST in this case.

              While it is true that all incoming data cannot be trusted, as you have noted, some input is more easily altered than others.

                Write a Reply...