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" />

Here are some popular user agent strings for mobile browsers. If "BlackBerry" is present in the client's user agent, you can assume it is a BlackBerry, and render your page accordingly. http://www.zytrax.com/tech/web/mobile_ids.html

HTML requires double quotes. Replace the single quotes (') with double quotes ("). You will have to escape them (\") as they will be appearing within a double quote enclosed string.

Add a "padding-right: x;" attribute to the image, either using its CSS class, or an inline style="xyz" attribute to the IMG tag.

How can it output the form again when you are having it die() if the email already exists? Also, addslashes() is depreciated, and you really shouldn't use it. You should be using mysql(i)_real_escape_string() instead.

Hi all, I am currently developing a rather intensive, non-local PHP application, and have reached the point at which localization issues must be addressed. I have never been faced with doing anything global before, so my experience with the concept of time in PHP has simply been operating everything (including DB-stored timestamps) as the local time(), and allowing users to offset an integral number of hours from that. This solution is not helpful to international visitors, and also not helpful to those living in the US who do not observe daylight savings time. I have committed to using UTC integer timestamps for all internal representation, and apply a localization filter to the output, based on stored profile settings. The problem comes in when daylight savings time is applied to the mix. What is the best way to apply DST rules (based on a user's chosen [international] location) to a UTC timestamp when processing localization logic? Does PHP provide a native functionality for doing this, or must I research DST in all of the world's locales? PEAR's DATE class is not an option. Even though this application will be running an a server supporting opcode caching, the PEAR library is horrendously bloated for such a simple task. I am not going to include 676KB of code just to process timezone and DST rules. Most of the code snippets I have found across the Internet include no mention of the conceptual basis for the code, and simply instruct the user to C&P x if they would like to accomplish y. Based on my testing, much of this code is self-contradictory. I can't rely on something which may break during a DST shift, or in a timezone the author never sees. From my experience, date/time errors are particularly insidious, hard to notice, and very difficult to correct. What is the best way to use PHP to convert from the application's internal UTC timekeeping to something localized for a user? I don't know that I can simply date_default_timezone_set(), as I will be operating on timestamps pulled from databases and subsequently manipulated by application logic? Knowing that everything internal is going to be UTC, how would I go about soliciting a user's offset, DST (not just American rules) preferences, and other applicable information, then applying that to the application's UTC for eventual output to the user? Does anyone have a good conceptual tutorial covering international date/time handling in PHP? Functional code snippets are great when you know they work, but I think that it is also to understand the "why" behind the logic, especially if the code hasn't gone through extensive, community-based QC.