lloydthemidgetkicker Posted May 12, 2006 Share Posted May 12, 2006 I'm trying to make one of my programs more secure, and I'd like to keep all GET and POST statements out of the URL. I'm pretty sure I have to tweak one of the php_ini settings, but I can't figure out which one. Anybody know how i can do this? Quote Link to comment Share on other sites More sharing options...
wildteen88 Posted May 12, 2006 Share Posted May 12, 2006 Ok, POSTed data is not sent through the url. However GET data is. Now if you dont want your GET data in the url then use POST on your forms. Quote Link to comment Share on other sites More sharing options...
lloydthemidgetkicker Posted May 15, 2006 Author Share Posted May 15, 2006 When I am navagating by links instead of forms I need to use $_GET[] (I think) to determin which page I need to display. I thought there was a way to link with a variable, such as <a href='?page=a'>, without actually displaying the variable in the url. I believe it's a php_ini setting, but I can't seem to figure out which one. I use some $_POST in the program I'm writing, but sometimes it seems necessary to use $_GET. Quote Link to comment Share on other sites More sharing options...
jeremywesselman Posted May 15, 2006 Share Posted May 15, 2006 I am pretty sure that you cannot keep $_GET from posting the variables in the URL. That is why it is called $_GET. You are getting the variables from the URL. $_POST is posting the variables to the action page.I don't believe that there is any way around this.[!--coloro:#990000--][span style=\"color:#990000\"][!--/coloro--]Jeremy[!--colorc--][/span][!--/colorc--] Quote Link to comment Share on other sites More sharing options...
alpine Posted May 15, 2006 Share Posted May 15, 2006 if you filter all GET variables properly (and POST ofcourse) you shouldn't have to worry. You can also make yourself one-time selfexpire random keys to use along when you are navigating admin area, perform delete operations etc. Quote Link to comment Share on other sites More sharing options...
_will Posted May 15, 2006 Share Posted May 15, 2006 If you cannot get around passing variables in the GET, you can always [a href=\"http://us3.php.net/manual/en/function.bin2hex.php\" target=\"_blank\"]convert the values to hex[/a] and add or decrement an offset, or use the [a href=\"http://us3.php.net/base64_encode\" target=\"_blank\"]Base64 encoding[/a] so that the information in the URL looks like garbage to the user, but has a meaningful value to the web app. Quote Link to comment Share on other sites More sharing options...
lloydthemidgetkicker Posted May 15, 2006 Author Share Posted May 15, 2006 Thanks for the replies. I'm working on a project for my prof, so I'll tell him what you've told me. Quote Link to comment Share on other sites More sharing options...
lloydthemidgetkicker Posted May 16, 2006 Author Share Posted May 16, 2006 Ok, I'm glad I posted in the newb area, cause I feel like one now. I talked to my prof and what he really wanted was for me to find out how to keep [b][u]session ids[/u][/b] out of the URL. I've been reading about using [u]session.use_only_cookies[/u] and looking for code examples. My prof also wants me to find out how to keep information from re-submitting if the user hits back and forward, and basically anything else that has to do with cookies and cookie security. Shouldn't be to difficult, but any code examples or links to info would help. Thanks Quote Link to comment Share on other sites More sharing options...
.josh Posted May 16, 2006 Share Posted May 16, 2006 well here's my 2 cents, one noob to another [img src=\"style_emoticons/[#EMO_DIR#]/laugh.gif\" style=\"vertical-align:middle\" emoid=\":laugh:\" border=\"0\" alt=\"laugh.gif\" /]i guess it depends on what you are trying to prevent the user from doing when (s)he keeps clicking back and resubmitting. For instance, to prevent spamming, most message boards have a flood control option that basically keeps track of the last time someone posted and if they try to submit another post in (example) less than 30 seconds, it will not accept it (as in, not update relavent info into the database). or i guess you could do an IP check, for random surfers. keep a log of IPs and timestamp of when info was submitted and then do a check on submit to see if the IP address was logged x amount of time earlier...also you could check to see if the cookie already exists.but actually i think a javascript solution might be better, seeing as how it is clientside... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.