Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
20.9.2014 - We have just updated our course layouts and descriptions and added our 2015 schedule.

Passing a URL variable

Posted by hl5 (hl5), 16 September 2005
Hello:

I am new at this.
When I pass a URL variable:
http://somesite/test.php?state=nevada

The test.php:

<?php
$next = $state;
?>

Is this going to set $next to nevada?
Or is there a syntax error here?

I am receiving an error:
"Parse error: parse error, unexpected '=', expecting T_VARIABLE or '$' "
What does that mean?

Thanks,

- Harry

Posted by hl5 (hl5), 17 September 2005
OK, I figured it out.

Thanks,

- Harry

Posted by admin (Graham Ellis), 17 September 2005
on 09/17/05 at 04:42:44, hl5 wrote:
OK, I figured it out.


I didn't .... what was it?

Posted by curtis (curtis), 8 October 2005
Syntatically speaking, that should've been fine. Just to warn you, you should always escape user input. The data passed through either GET or POST submissions should be escaped by htmlspecialchars or htmlentities

Code:
<?php
$state = isset($_GET['state']) ? htmlentities($_GET['state']) : false;

....

if ($state) {
  // do stuff
}

....

?>


Posted by admin (Graham Ellis), 8 October 2005
Hi, Curtis, and welcome to Opentalk.

When I made my initial answer here, I wondered whether I should refer to $_GET and/or $_POST .... or perhaps to $_REQUEST which combines both of them (and a couple of other tings too) so that the code will work whichever method was used.  

I decided against making such a comment, since it clearly wasn't the issue which was a syntax problem.  I'm also very much aware that many users of this board may have older versions of software running on servers that were set up a while back, and over which they don't have control.   In older versions of PHP, $_GET and $_POST aren't actually available, even though they're the reocmmended way of doing things in the current version.

On a more serious note, I'm going to suggest that your call to htmlentities is incorrect in this context, but I might have acceped stripslashes.

As you read from a form element into a variable within your program, you need to tidy up any specialcharacters that are in there and PHP may (depending on its configuration) have added extra backslashes.   Period.   End of things to do on input.

As you write text back out, you should deal with special characters such as < and " which mean something special to the browser, and at that point you should use htmlentities or an alternative.   To call this as you're dealing with the input means that you're going to have to work your business logic on encoded strings rather than the true text.

To complete the story, if you're going to save the string you've read into a database, use it as part of your where clause, or use it for some other similar purpose, you should addslashes to prevent malicious injection attacks.

Can't even a simple input be complicated!  

Posted by curtis (curtis), 8 October 2005
Thanks for clearing that up, Graham, and for the welcome .

I do understand what you were talking about, I just mentioned that because it's good to get in the habbit of escaping user input. I knew that my response had specifics in it, like: super globals and query string. I forgot about stripslashes because I turn off magic quotes for my local setup, as it's irritating to me.

I get so used to talking with my friends who have the same type of set up, that I didn't really think about it.

Concerning database escaping, I'm glad that you mentioned it, because I see a lot of people writing scripts that take in form data directly without escaping with either addslashes, mysql_real_escape_string, etc. You may or may not be surprised how many scripts are made freely available for people and are unsafe.

Posted by admin (Graham Ellis), 9 October 2005
Alas, one of the downsides of PHP being a fast-developing language has been that the best solution under the current release won't work under earlier releases, and that solutions under earlier releases aren't ideal under current releases.   Add to that facilities like short_open_tag, magic_quotes_gpc and register_globals which can be configured on or off and effect the source, and portability / support advise needs to be carefully considered and statements qualified!

Posted by curtis (curtis), 11 October 2005
I'm not too well informed on how much people still use older versions of PHP. Is it still common for people to still be developping on versions 3 or even 2? I have gotten into the habbit of viewing the response headers to several of the sites I visit, and it seems that the majority of the sites I come across powered by PHP are running at least version 4. Of course, this hardly represents the whole of the Web, which is why I am asking.

Thanks again for your insights, Graham, it seems I still have a really long way to go



This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2014: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 899360 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho