lisa71283

mysql(i)_real_escape_string() should be called on any user-supplied or modifiable content that will be passed to a query, otherwise you will be setting yourself up for a SQL injection attack.

Uncomment the mysql_error() call and let us know what it returns. Are you getting something other than false from the mysql_query() call?

If you fetch the page with cURL, you can use curl_getinfo to retrieve the pertinent details of the document, as supplied by the webserver. cURL will eliminate a lot of the trouble of manually parsing an HTTP response retrieved through a socket.

http://us3.php.net/manual/en/function.fputcsv.php

Why not create a SQL table keyed by the SESSSIONID that contains the necessary information? Each hit would load the information as required.

The easiest way to accomplish this is to create a SQL table containing the parameters of emails that need to go out, and when the specified action occurs, simply INSERT the necessary row(s) into this table for later processing by a different script. The logic which creates and sends the email would be contained within a script called, for example, every minute by CRON. If that script is taking a long time to run, it won't affect the browsing experience of a user. Using such a method also eliminates the problem of a script being aborted either by the user or a network disruption in the middle of processing - for example, if you had the upload script sending the mail, and the user aborted or experienced a network problem after the image was uploaded, but before all of the mail was sent, you would have a situation where only some of the people receive the notification message. In general, you should always keep any heavy lifting not needed on an immediate basis confined to scripts called by CRON to operate on SQL queues. User-initiated scripts should never perform large background tasks.

set_time_limit(0) may not be available to you if you are on shared hosting. Additionally, when you are using PHP to perform large tasks on a manual basis, you should always ignore_user_abort(true) to prevent a network problem from killing your script halfway through execution.

You need to carefully check the input string, otherwise that script will open up any file within your account's reach for download. Consider a link such as: http://www.example.net/download.php?fileName=../config/config.inc.php Depending on how your server is configured, somebody might get away with: http://www.example.net/download.php?fileName=/usr/local/apache/conf/httpd.conf If someone wanted to turn that script into an http(s)/ftp proxy, they could do so by passing a URL to the fileName parameter like this: http://www.example.net/download.php?fileName=http://www.hackersite.com/ This would not be good. Such a link could read the un-parsed contents of your configuration file, which could potentially reveal MySQL passwords or other sensitive data. Slashes do not belong in the fileName string, so strip them out. This prevents both directory traversal attacks, and inadvertent proxying by your download script. Furthermore, you should ensure that you are using an absolute path pointing to the file directory, and that the only extension(s) allowed are those that you specify. A quick if (strpos($fileName, '/') >= 0) { die; } will close the hole.

We cannot modify your code, as the snippet posted does not produce the output. The snippet posted calls image_display(), which either generates the HTML itself, or passes the arguments to another function. You will need to look at the source for image_display() and let us know if it is creating the HTML <IMG> tag. Once we find the code that is actually producing the HTML, then we can modify it as necessary.

You may want to reconsider how effective that script can actually be. There are so many proxies these days that do not forward the originating address, or even give any indication that the request is being proxified. These are the proxies you have to be worried about, and they are everywhere. That being said, I would still recommend that your proposal be implemented. In each user entry (and, preferably, a login history table) include both REMOTE_ADDR and HTTP_X_FORWARDED_FOR. When a new user account is created, is the HTTP_X_FORWARDED_FOR is present and anything but a null, quad zero, or private network address, then execute a quick comparison to see what other accounts match that address, both based on your user table, and your access history log. If a match is found, you can have the script send a quick email alert to admins/mods to keep an eye on the new account for potential abusive behavior. Also, password comparison should not be possible, because you should be using salted hashes - right?

Cast the result as an integer.

If the application supports a non-fsockopen() method, then switch to that. Otherwise, there is no way of getting around it that wouldn't violate your host's TOS. Hostgator is a large operation, and they have disabled fsockopen() for a very good reason.

Yes, they do.

When you say "subject", are you referring to the subject of the email? HTML code should not be in the subject of an email, only the body.

<img src="whatever.png" style="padding-right: 15px;" alt="description" />