HTTP request failed! HTTP/1.1 404

[Sim]

Warning: imagecreatefrompng(http://rpg.phpengines.info/gamedata/Test/items/body_Dark Brown Body.png) [function.imagecreatefrompng]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /public_html/phpengines.info/rpg/gamefiles/admin/charimg.php on line 10


The weird thing is that my image is there.. if you go to that url, you will see ;\ any suggestions

Code: [Select]

<?php
session_start();
require "../config.php";

$name = $_GET['game'];

$imgOutput = imagecreatetruecolor(48, 64);
imagefill($imgOutput, 255, 255, 255);

$imgBody = imagecreatefrompng("$game_data$name/items/body_" . str_replace("_", '',$_SESSION['body']) . ".png");
imagecolortransparent($imgBody, imagecolorat($imgBody, 0, 0));

if(isset($_SESSION['top']))
{
$imgBeard = imagecreatefrompng("$game_data$name/items/head_" . str_replace('_', '',$_SESSION['head'] . ".png"));
imagecolortransparent($imgBeard, imagecolorat($imgBeard, 0, 0));
}

imagecopymerge($imgOutput, $imgBody, 0, 0, 0, 0, 48, 64, 100);

if(isset($_SESSION['top']))
{
imagecopymerge($imgOutput, $imgBeard, 0, 0, 0, 0, 48, 64, 100);
}


imagepng($imgOutput);
?>

[Sim]

arg. fixed. because of the spaces ;]

[chrisjenkinson]

Just FYI you should never access the filesystem without sanitising any user-submitted variables including $_GET and $_SESSION.

[JGadrow]

$_SESSION data is actually stored on the server (only the session ID is client-submitted) and is safe to use. But, yes, definitely validate anything from $_GET.

[DV8]

I validate anything from $_GET and $_POST. It got a little silly for a while that I was over-validating those things.

[JGadrow]

over-validating

You, sir, speak of the impossible!

[Chris]

over-validating

You, sir, speak of the impossible!

It drives me sick but I have to agree with JGadrow a second time this year Getting paranoid over data validation for multiplayer games is a healthy habit.

[DV8]

Haha, I'd do things like this:

Code: [Select]

$intExample = ( isset( $_GET["example"] ) && ereg( "^[0-9]*$", $_GET["example"] ) && $_GET["example"] != "" ) ? $_GET["example"] : 0;
Which, I think you'll agree, is a little double up.

[CygnusX]

Could:

if(isset( $_GET["example"] ) && $_GET["example"] != "" )

Not be replaced with:

if(!empty($_GET["example"]))


?

The latter is easier to read and save precious typing time.

[JGadrow]

Attempting to access a non-existent array index will generate a PHP Warning (or maybe it's Notice... I forget which).

The best version would be:

Code: (php) [Select]

$intExample = (isset ($_GET['example']) && is_numeric($_GET['example'])) ? intval($_GET['example']) : 0;

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[JGadrow]

It used to... It'd be nice if that's been corrected as I hate having to type isset() before this... always feels so redundant.

In any event, empty() isn't the right function for this anyways because the string 'apple' isn't empty but if attempted to convert to an integer value, it will be converted as 1 where the code would expect it to be 0.

[codestryke]

$_GET and $_POST get all the love but don't forget about there ugly sisters $_COOKIE and $_REQUEST

$_COOKIE gets forgotten about a lot which is why it's a great exploit

[CygnusX]

Code: (php) [Select]

$intExample = (isset ($_GET['example']) && is_numeric($_GET['example'])) ? intval($_GET['example']) : 0;[/quote]

I would agree with this.   after going back and reading the documentation, isset seems to be the better means of checking if a variable is defined.  empty would through false if the value was 0 or false. 

also, is_numeric > ereg for checking if a variable is a number.  so much easier to code : )

[JGadrow]

Mainly because you really shouldn't use those anyways. $_REQUEST has long been considered evil. Sure there are situations where it could be useful (say you don't care if the variable comes from $_GET or $_POST) but as a "best practice" you should explicitly check the super-globals you care about rather than leaving the decision over which should take precedent to whomever has control over the php.ini (not always the developer).

As for $_COOKIE... why use $_COOKIE when you have $_SESSION? The less data you actually give to the client, the less you need to worry about validating for XSS / cheating / etc..

[codestryke]

Mainly because you really shouldn't use those anyways. $_REQUEST has long been considered evil. Sure there are situations where it could be useful (say you don't care if the variable comes from $_GET or $_POST) but as a "best practice" you should explicitly check the super-globals you care about rather than leaving the decision over which should take precedent to whomever has control over the php.ini (not always the developer).

As for $_COOKIE... why use $_COOKIE when you have $_SESSION? The less data you actually give to the client, the less you need to worry about validating for XSS / cheating / etc..

I've found $_REQUEST extremely useful especially when creating summary / detail type drill downs where the summary is used as a $_GET and the detail is processed as a hidden variable in the detail. Each to his / her own I use it regularly and sanitize the input which is what I was trying to relay in my post.

As for cookie this comes with the ability for both JavaScript and PHP to share information via cookie data. I don't need to clutter up $_SESSION data with data sorting preferences which I normally use it for. I have not found another way to share data between javascript and PHP without using a cookie. You can pass or push data between the two but to truly 'share' the data in one location, cookie is the only method that I'm aware of.

[JGadrow]

I've found $_REQUEST extremely useful especially when creating summary / detail type drill downs where the summary is used as a $_GET and the detail is processed as a hidden variable in the detail. Each to his / her own I use it regularly and sanitize the input which is what I was trying to relay in my post.

$_REQUEST is a coalescence of $_GET, $_POST, and $_COOKIE (by default, in that order, but not necessarily)... There's nothing that can be done with it that cannot ALSO be done using the other super-globals.

If you're not in control of your php.ini file (which I'm assuming you are... but that's not always the case) then you have no control over the order this is processed in. It's a better practice to do:

Code: (php) [Select]

if (isset ($_POST['var']) && !empty ($_POST['var'])) {
    $var = $_POST['var'];
}
elseif (isset ($_GET['var']) && !empty ($_GET['var'])) {
    $var = $_GET['var'];
}
Than it is to do:

Code: (php) [Select]

$var = $_REQUEST['var'];
Using a default configuration... these two code snippets do the same thing. However, if you change hosting for some reason and the new host has a different order specified in their php.ini file, you have just silently introduced a bug into your program!

And, yes, this is a lot longer to type so I can see how $_REQUEST is convenient. But, you can get the convenience back (and eliminate the potential config-level bug) by defining this function:

Code: (php) [Select]

function req($var, $order = 'gpc') {
    $globals = array(
        'c' => $_COOKIE,
        'g' => $_GET,
        'p' => $_POST,
    );

    $val = NULL;

    foreach((array) $order as $superGlobal) {
        if (isset ($globals[$superGlobal][$var]) && !empty ($globals[$superGlobal][$var])) {
            $val = $globals[$superGlobal][$var];
            break;
        }
    }

    return $val;
}
Now, you have the ability to do the exact same thing you wanted to do except you are now in control of the order instead of the php.ini file. On top of that, it's actually fewer characters to type in and it bakes in a small amount of default validation. Obviously, you could modify the function to use something other than !empty() because '0' returns TRUE from the empty() call... but I think you can see my point here.

As for cookie this comes with the ability for both JavaScript and PHP to share information via cookie data.

<off-topic segment removed, don't worry, it's at the bottom>

I have not found another way to share data between javascript and PHP without using a cookie. You can pass or push data between the two but to truly 'share' the data in one location, cookie is the only method that I'm aware of.

There's still no way to share data between PHP and JavaScript. This is still passing it to JavaScript. However, you can go with the approach that Drupal uses which is to embed a small piece of JavaScript on the page that is meant to pass data to JavaScript relevant to that page. You know... the kind of stuff you just can't cache. This JavaScript is output in the <head> of your (X)HTML so that it's available to whatever JavaScript code might need it later on in the page.

I don't need to clutter up $_SESSION data with data sorting preferences which I normally use it for.

Isn't this what $_SESSION is supposed to be for? Preserving data / variables relevant for that individual user's session? And, actually, I would find it especially annoying if my preferences were stored in this manner. What if I login from work? Or I change browsers? Or I reformat my machine? Now I've just lost all the preferences that I had setup when I know perfectly well that if you had kept them in the $_SESSION instead of a cookie they could have been preserved.

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[Sim]

Wow, I stirred up quite a topic. =)

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[codestryke]

Thank you for the lesson on $_REQUEST, I was very aware of how and why it works. I don't do consulting work and I run my games on my server and development box where I have full control of the environments.

To me your session argument is invalid, as Mike has stated and I already knew, that session data is retrieved by a cookie or if cookies are turned off then by the query string (assuming standard PHP session handlers).

I've found, for my needs, that $_REQUEST and $_COOKIE can come in handy in different situations. I didn't post to argue that fact, all I posted was they also need to be sanitized if used. I even prefaced them with a quirky joke about being the ugly sisters of get and post.

[JGadrow]

What makes you think that your $_SESSION data will be available from work (presumabely on a different system) or after a format?

Not all of the session data. I mentioned my user preferences would be preserved. But, admittedly, that's because I make a habit of storing the active user (and the preferences are saved with the user object) in the $_SESSION. Why? It is that user's session. So, yes, maybe things like which actual page I'm on wouldn't be preserved (though you could do that... but not sure how feasible that would truly be) but my actual preferences should, by definition, be stored in the $_SESSION. It's a debate similar to "Why should I use <em> instead of <i>?" It a matter of semantics.

This would only happen if the site developer had altered the session system to work this way...

Let's just keep this little point in mind.

I set my own cookies with my own session system over using PHP's session system so that I can control things to a better degree. You could of course over ride PHP's default session behaviour but that just seems a messy way to do things.

So... you create your own session system. Rather than change the way that PHP's sessions are implemented. Do you not see how unfriendly that is? And, yes, I change the default session handler to store data in the database. Partly because there's almost always a database connection active which means less overhead when accessing, and also because I dislike the way PHP's cleanup leaves a bunch of empty files laying around the temp directory (at least on Windows... don't remember if it does the same in 'nix). And I can say, it's really easy to change how PHP handles its sessions.

By default PHP's session system has various problems which I'm not interested in working around when I can control the session/cookies implementation myself.

You can control it with the default system as well. Only now, you're able to utilize default PHP functions. Which means if someone is programming after you they don't need to learn a new way of working with sessions. That point is more relevant to the business world than games, but maybe you want to eventually remove yourself from the programming aspect once you make a billion dollars and just sit around all day thinking of ideas that you'll make that poor sap implement... everyone has different dreams. lol

Basically we're comparing cookies vs a system which utilizes cookies (who uses the query string to pass session identifiers?) to maintain sessions anyway, so this little debate is just plain stupid.

Hey, who're you to control the way that everyone uses sessions? Session id in url can be good if you need a way that robots can crawl your site with session data attached. Of course, then you have to be sure you do work to prevent session fixation attacks. But, anyways, even with the assumption that the $_SESSION is using a cookie... the original point was about security and validation. Why build another spot that you need to keep an eye on the evil users when you don't have to? If you store the data in a $_SESSION the data is preserved on the server (well, barring some implementation which actually stores the data in a cookie... but then the fault is on whomever wrote such an evil implementation) which means it's unalterable by the end-user... and doesn't need to be validated as "user-input" data.

Lets say somebody uses PHP's sessions to just store a user ID once logged in. Ok, great - it works. What's the point in that when by default PHP's session system then has to read from a file system to load that user ID? Instead we can generate our own session identifier, mark this against a user in the database (ensuring the value is unique), store a cookie (for however long you wish), make sure the column is indexed and bob's your uncle.. a much better way of doing things. This doesn't fall victim to the problems PHP's session system has by default, such as having multiple web servers serving requests but session identifiers only being stored locally per web server.

Or... you could take 5 minutes to change session handling to store in the database. Which is a very common practice. lol All you are doing is creating your own implementation of the session handler only using your own functions... you're doing far more work for no additional benefit and at least one additional negative factor.

Your own session system > PHP's session system any day. Cookies are going to presumabely be used either way to store the relevant identifier.

Your own implmentation of PHP's session system > PHP's default session system > Your own session system. Again, I place your own implementation on the bottom because now you're obligated to educate future programmers on how to use your session system instead of using what's there out of the box.

For storing client side user preferences which don't really need to be maintained over different systems (for example the size of the chat bar for future reloads, set each time it's resized), I like to use HTML5's localstorage - storing this kind of thing server side is just a waste and storing it in cookies is just extra data being sent with every single request on that domain / path pointlessly. Surprisingly localstorage is even supported in IE8 That's enough for me (and for this type of thing, if the user's browser doesn't support localstorage.. it's no big deal, their chat area width is just not saved for future visits, for example).

This is something I'd pass to the JavaScript in the <head>. I'm not using HTML5 yet... It's still a Working Draft. Everyone is jumping on the HTML5 bandwagon way too early IMO. It's all just hype at this point and I, for one, will wait until they at least get it to Candidate Recommendation status. Working Draft is the lowest category there is! It's the equivalent of everyone working on pre-alpha software!

@codestryke: The lesson wasn't really for your benefit. As I pointed out, I was quite certain you were in full control of your environment. It was more for the benefit of people who aren't quite as savvy at this stage.

Really, a statement that you need to "validate any input received from the user" should cover all of the super-globals (even $_FILES). But, as a lesson for newer developers, they shouldn't really come to rely on those specific super-globals. $_REQUEST for the easy-to-miss precedence order, $_COOKIE because of the added security headache that is taken care of by $_SESSION and passing data relevant to the JS in the <head> of the (X)HTML.

Good practice is good practice regardless of whether it's for business purposes or games.

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[JGadrow]

Again, I meant the preservation of the user's preferences not the whole session itself. Losing my place in a multi-step form, not a big deal; losing the preferences I spent 20 minutes setting up, that's a heart-breaker.

Well it's a good job you won't ever be taking over any of my small projects with your "certified engineering", cause I won't ever feel the need to use PHP's session system (completely altered or not) just because it's there

That feels like a personal attack. I had a few impulse reactions that I thought about saying... but I will simply say that's very unprofessional. I have tried not to personally bash anyone and always kept my arguments logical and tried to respect the other person's position.

Suggestions that I make are always aimed at improving how you code. And sometimes after a logical debate I'm able to say, wow! Thanks Codestryke! Or Chris, or Harkins, or whomever. In this, though, you're just plain wrong: which is fine. I make a suggestion to improve how your system works (and it's one that would involve less work on your part and allows you to bring in new staff members should your game grow) but that's all that I can do. I can't force you to implement it. All I can do is give you my viewpoint and hope it settles in, or maybe sparks a thought for you.

This conversation helped me to write that req() function I made above. I'd never even thought of it before this conversation which is why I enjoy intellectual debates! Now I have a nice little piece of code to add to my arsenal which makes my projects come together just a little bit faster.

And, I concede the point on "sharing". By definition, "sharing" and "passing" are equivalent. The way I had read it (since codestryke implied they were separate) was that "passing" is giving back and forth and "sharing" allows for concurrent access. Kind of the difference between passing by value or passing by reference. A change in one place doesn't necessitate a change in the other.

As far as your comment about starting sessions... well, if you have a single entry point for your application (say, index.php) you start a session as your first action and then the rest of your application can assert that there is a session. You don't need to waste time even checking for it.

But, from your comment I can tell you're on the defensive and not even really letting anything I'm saying in at this point. I hope at some point in the future you come back and re-read this with an open mind. Growing as a programmer means fighting your ego. What you're doing has been done before, and it's been done better... I don't mean that statement to apply exclusively to this discussion. I state is as a rule for all programming. Nothing you ever do is the best way to do it. Just make that your default assumption because as soon as you think you know everything, someone will come along and make you look a fool.

I'm sure if you poke around, you'll see several times on this very form that someone has done it to me! lol I'm just an ordinary person. Sometimes I'm right, sometimes I'm wrong. But I'm always willing to admit when I'm wrong. And I always try my best to realize that behind these words on a screen is another living, breathing person; and I do my best to respect them.

*Edit - Minor grammar correction. See... I point out that I'm not perfect all the time! lol