homepage Welcome to WebmasterWorld Guest from 54.198.42.105
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
Tutorial on using query strings in PHP
littlegiant




msg:1288266
 1:11 pm on May 12, 2006 (gmt 0)

Greetings,

I'm having problems finding a good simple tutorial on how to use query strings in URLs in PHP. I know how to do this using Javascript well enough. I'd like to learn how to do the same thing in PHP. I'd like to send info from one page to another using a query string something like:

http://www.example.com/example.php?id=myname

I see links like this all the time and I know that information is being sent to the page example.php which then builds the page dynamically according to the parameters 'id' and 'myname'. How do I do this using PHP? I think it has something to do with the explode() function.

All I'm coming up with in Google is how dynamic URLs are bad and how to convert them into search-engine friendly URLs. I already understand all this. I need something that goes back one step and just teaches me the basics.

Any comment would be appreciated or just a link to a good tutorial. Much thanks.

 

omoutop




msg:1288267
 1:34 pm on May 12, 2006 (gmt 0)

Two ways to pass your variable to your query:

A) Select * FROM table WHERE field='".$_POST['querystring']."'

use POST/GET/REQUEST

B)
$myvar = $_POST['querystring']; and thus
Select * FROM table WHERE field='$myvar'

Notice the difference in (') and ('") in the two examples

Longhaired Genius




msg:1288268
 2:13 pm on May 12, 2006 (gmt 0)

Query-string variables are automatically put into an array called $_GET to be extracted at your leisure. It's so simple it's scary. Maybe that's what's confusing you.

jatar_k




msg:1288269
 3:17 pm on May 12, 2006 (gmt 0)

the php documentation [php.net] can tell you about it

Predefined variables [php.net]

The thing about the $_GET superglobal array is that it really is simple to work with. If you have done this with javascript then I won't waste time on how to build them, as you probably already understand the format. It is just a matter of putting the information you need into a url.

let's use your example
http://www.example.com/example.php?id=myname

you could access the value of the variable id in the $_GET array like so

echo $_GET['id'];

this would output "myname". It is common to pull these into a local variable such as

$myid = $_GET['id'];

this would be the some syntax for any var in your url, take this example

http://www.example.com/example.php?id=myname&start=40&section=mysupercat

$myid = $_GET['id'];
$start = $_GET['start'];
$section = $_GET['section'];

these vars could then be used to do whatever you need

Notes:
1. for security purposes, check all variables when they come in, any user can change the GET string and give out of range or erroneous data

2. Read through using register_globals [php.net]

3. as you mentioned, GET strings, especially with params called id or PHPSESSID are no good for SEO

4. don't pass too much data in your GET string, there are limits, they are fairly large but try to keep it short and sweet

does that help a bit?

dreamcatcher




msg:1288270
 4:32 pm on May 12, 2006 (gmt 0)

for security purposes, check all variables when they come in

This is the most important part. Always check whats coming in. Most script vulnerabilities start with unsanitized data from query strings.

dc

littlegiant




msg:1288271
 5:08 pm on May 12, 2006 (gmt 0)

Thanks a lot everyone! I 'GET' it now (har har har)!

littlegiant




msg:1288272
 6:55 pm on May 12, 2006 (gmt 0)

Okay just a quick follow-up on the subject of security. My script only takes 1 variable (let's call it 'myVar' for demonstrational purposes) which is retrieved from the URL using the $_GET superglobal. I've created a test using a regular expression to make sure the value of myVar is what I expect it to be (only contains 2 digits and nothing else). And I've created a test to make sure that myVar actually exists in the URL passed to the script. Is that good enough? Is it possible to inject other variables altogether using a query string? What else -if anything- should I be aware of?

littlegiant




msg:1288273
 7:02 pm on May 12, 2006 (gmt 0)

For example, how can I make sure that no other variables except myVar are injected using the query string in the URL?

jatar_k




msg:1288274
 7:12 pm on May 12, 2006 (gmt 0)

those 2 tests should be fine

as long as you don't have register_globals on then nothing else gets automatically brought in

whether off or on if you initialize all of the vars you use they will always start off empty

littlegiant




msg:1288275
 8:47 pm on May 12, 2006 (gmt 0)

Okay great. One last thing.. (sorry)... I've read through several pages from various sources on the net about 'initialising variables' and I'm still a little fuzzy on the concept. From what I understand, initialising a variable simply means assigning it a value in the actual script itself so that it can't be hijacked by malicious query string? Something like that? Is this correct?

jatar_k




msg:1288276
 10:29 pm on May 12, 2006 (gmt 0)

[php.net...]

initializing means you set them to a default value of the proper type before you use them, not specifically for security but it definitely helps with it

string
$myvar = '';

int
$myvar = 0;

array
$myvar = array();

boolean
$myvar = false;

or what have you, from a security standpoint this stops variables from having unknown values or allowing input to change their starting value/state.

ergophobe




msg:1288277
 9:29 pm on May 14, 2006 (gmt 0)

Not sure I follow Adam.

If I have register_globals on and someone types in

http://example.com/ergo_script?my_var=3

that will set/reset $my_var to 3. Initializing variables doesn't change that one way or the other (that's why having register_globals on is such a major pain).

On the other hand, if register globals is off, nobody will be able to use a URL to reset a variable outside the superglobal arrays, whether initialized or not.

I think initializing variables is good practice and contributes to stability and avoids unexpected results, which contribute indirectly to security, but with respect to injecting values into the script I don't see a security advantage.

From a security and stability point of view I think the key thing is making sure that the values sent are of the type and in the range of what you expect. Testing for a two-digit integer is a fairly strict test, so that seems pretty good.

jatar_k




msg:1288278
 3:10 pm on May 15, 2006 (gmt 0)

I actually don't think that is the case

this url
http://example.com/ergo_script?my_var=3

would mean at script start $my_var would have a value of 3

if you set

$my_var = 0;

at the top of your script it isn't going to be set again to 3 it will be 0

that was my understanding, that vars are imported into the local variable table at start of execution, if you reset them then they would be whatever you wanted.

though I haven't used anything with register_globals on in a long long time.

jatar_k




msg:1288279
 4:22 pm on May 15, 2006 (gmt 0)

ok I went and read through this page to make sure I wasn't losing my mind (always a possibility)

[php.net...]

if you look at Example 29-1 this line comes below the code

in our example above we might have first done $authorized = false. Doing this first means our above code would work with register_globals on or off as users by default would be unauthorized.

so yes, proper initializattion of all internal vars will stop variable poisoning due to register_globals being on

and later on

Of course, simply turning off register_globals does not mean your code is secure. For every piece of data that is submitted, it should also be checked in other ways. Always validate your user data and initialize your variables! To check for uninitialized variables you may turn up error_reporting() to show E_NOTICE level errors.

ergophobe




msg:1288280
 12:22 am on May 18, 2006 (gmt 0)

Ooops. Yeah that's obvious upon reflection. I just had some memory of being asked to fix a script and found the problem was variables being rewritten unexpectedly and it came down to a register_globals problem. It may have been because sessions vars were beign registered too and there were session vars and POST vars that unintentionally had the same name or some such nonsense.

jatar_k




msg:1288281
 3:00 am on May 18, 2006 (gmt 0)

>> session vars and POST vars that unintentionally had the same name or some such nonsense

man, I have had to deal with that too many times

>> upon reflection

hehe, I had to go back and read it all to be sure, it would be far from the first time I was wrong and you were right ;)

ergophobe




msg:1288282
 3:36 pm on May 18, 2006 (gmt 0)

For anyone starting out like littlegiant, I can't stress how much time some of these time-saving shortcuts like turning on register_globals will cost you. Definitely turn off register_globals and I would also say that if an open source script does what you want, but requires register_globals on to function (becoming more and more rare), find something else.

I'm glad that by the time I discovered PHP, I had a couple of advantages in that

- the PHP community had mostly progressed to turning register_globals off as a matter of standard and habit.

- I had a limited but sufficent background in C++ and Pascal to give me a negative attitude toward globals and uninitialized variables

That meant that I just haven't had to deal with the variable overwriting and other headaches that much.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved