TweezerMan

Welcome to the forums, Brooke!

Welcome to the forums, Dave!

Welcome to the forums, sas!

Welcome to the forums, Carl!

Welcome to the forums, lorph! I've used the MySQL Control Center before, but switched to the MySQL Query Browser because of this note on the MySQL web site: It looks like you can perform this task in MySQL Query Browser too: Click "File", "Open Script..." on the menu, open the .sql file, then click "Execute" on the toolbar. I never thought about doing a MySQL database import that way - pretty neat idea!

Welcome to the forums, WickedlyWise!

Welcome to the forums, jerME!

I did some reading about PHP file uploads in the PHP manual. I don't think it's necessary to use FTP in your PHP script. Your HTML form is fine. When you click the "Upload" button, the file is automatically uploaded via HTTP to the server's tmp directory, and given a temp file name. PHP keeps track of the original file name, and the temp file name, in the global $_FILES variable. The uploaded file just needs to be moved to the proper directory and renamed to its proper name. It appears that the $file variable in your script is accessing the temp file name of the file after it has been uploaded to the /tmp directory. I'm guessing this is due to the PHP option 'register_globals' being enabled, and things like this occur very easily when the PHP global variables for form data are not used. Taking the example from the PHP documentation, I used this script with your form to upload a file and move it into the proper directory with the proper name: ><?php $upload_dir = "/home/xxxxxx/public_html/images/"; $upload_file = $upload_dir . basename($_FILES['file']['name']); echo '<pre>'; if (move_uploaded_file($_FILES['file']['tmp_name'], $upload_file)) { echo "File is valid, and was successfully uploaded.\n"; } else { echo "Possible file upload attack!\n"; } echo 'Here is some more debugging info:'; print_r($_FILES); echo "</pre>"; ?> Since this file upload script will run as the user 'nobody' whatever directory you want the uploaded files to be moved into must have 0777 permissions. Hope this helps...

Using this filter: >|/usr/bin/php -q /home/mycpanelsusername/public_html/myfile.php ...should be the same as using this filter: >|/home/mycpanelsusername/public_html/myfile.php ...with the shebang line in line 1 of the script: >#!/usr/bin/php -q If you use the first filter above, I'd recommend removing the shebang line from the script - it's redundant, and php is likely to output it as plain text when the script runs.

Welcome to the forums, Max!

I don't have any password protect pages on my web site, and the "Other logins (and/or anonymous users)" section of my AWStats appears to show the total stats for all users who have viewed my site. I imagine it is the same for your site - the "Other logins (and/or anonymous users)" section is showing the stats for users who have viewed unprotected pages in your site. The stats details for those users should be viewable elsewhere on the AWStats page. If you wanted to verify that this was indeed the case, I imagine that you would need to download the server log (Raw Access Logs in CPanel) and examine it / analyze it.

The 'Internal Server Error' message is usually due to: 1) The permissions on the *.cgi files in the MT directory are not set to 0755, or 2) The MT files were not uploaded to the server in ASCII mode. Installation instructions are available on the Movable Type web site; there are also instructions available at the TCH Help web site.

So does that mean it's working or not working?

So, $file is a path too and not just a file name? Try this instead: >// upload the file $upload = ftp_put($conn_id, $destination_file . '/' . basename($file), '$file', FTP_BINARY);

Welcome to the forums, Jawa!

A "regular file" means that it is a file, as opposed to a directory. According to the PHP documentation for ftp_put(), the destination for the FTP transfer is supposed to be specified as a full path and file name, not just a directory path. Unless you want to use to save the file on the FTP server with a different file name, I'd suggest changing your code as follows: >// upload the file $upload = ftp_put($conn_id, "$destination_file/$file", '$file', FTP_BINARY);

One more tip: Your script should return a value of '0' when it ends to indicate that no error occurred. I'd suggest the following code for your script: >#!/usr/bin/php -q <?php $fp = fopen("blahblah.txt","w"); fwrite($fp,"Hello"); fclose($fp); return 0; ?> (and make sure the script has 0755 permissions.)

The script does not need to be in a specific directory. I set up an e-mail account, created a filter script, and added the script as an e-mail filter in CPanel. I tested various things, and the only thing I encountered that caused an error like what you're seeing to be e-mailed was for the script to not explicitly return a '0' at the end of the script (to indicate the script executed with no errors). This is essentially the script I tested that worked for me: >#!/usr/bin/php -q <?php mail("tweezerman@xxxxxxxxx.com","Working...","It worked!"); return 0; ?> From what I've read on Google, the "local delivery failed" text in your error message is an indication that 1) your script had an error when it was run, 2) it did not return '0' when it was finished, or 3) the script inadvertantly produced output on STDOUT or STDERR, which can be interpreted as an error even if the script exits with a return value of '0'. Hope this helps...

When logging in via FTP, the FTP server does not see the '/home/xxxxxxxx' part of the server path, so I think you'd need to remove that from your destination path: >$destination_file = "/www/images";

Take a look at this post and see if it solves your problem.

I've never used e-mail filters, but it seems to me that there may be at least two problems with your script, stemming from the fact that the filter script must run from the command line instead of being run by the web server: 1) The script must have a shebang line for the first line so the shell knows what interpreter to use to run the script: >#!/usr/bin/php -q 2) The script must have execute permissions - the script's permissions should be set to 0755. Without the shebang line, the script would fail with something like a "bad interpreter" error message, and if the script is not executable, the script would fail with something like a "no execute permissions" error message. I imagine you don't see any error messages because these errors would be reported back to the mail server process, since that is what is trying to call your script. Hope this helps...

You should understand that 'john.bigfirm.com' is a domain name, not an IP address. Yes, you can deny a domain name in your .htaccess file (note the 'from' again): >Deny from john.bigfirm.com When checking access by domain name, Apache (the web server) performs a double reverse DNS lookup on the remote IP address to match the hostname. Since you said that john.bigfirm.com "cannot be resolved to an IP address", I don't think Apache will block anything as a result. You can ban whomever you like, but it doesn't sound like this person is doing anything to your site other than reading it. Blocking specific people from reading your site by IP address tends to be a losing battle because they can always switch IP addresses or switch machines to ones that are not blocked.

I don't know what you mean by "running a propaganda against it", but if this user is abusing your site in some way, I'd suggest registering a complaint with this person's company and/or the company's hosting firm. Given that this user is within the company's network and does not appear to have a fixed IP address, I don't see how you would be able to block this user unless you were willing to block all of the IPs that the company uses (which you said you do not want to do). This won't work because 1) you can't enter a range of IPs like you have in the 'Deny' directive, and 2) the 'deny' and 'allow' directives are missing the mandatory term 'from'. Your above example would need to be set up like this: >Deny from 123.456 Allow from 123.456.123 Allow from 123.456.456 I have a feeling that the above would be *way* too broad - the above will block over 65,000 IP addresses contained within the 123.456.*.* IP address block, except for IP addresses in the 123.456.123.* and 123.456.456.* ranges (255 addresses each). This is really overkill to block just one person. There probably is a better way to block this person, but without knowing how you are able to identify this person or more details about what they are specifically doing to your site, it's impossible to say what way would be best.

Welcome to the forums, Monsoon!

Welcome to the forums, AussieFeral.com! As others have tried to point out, attempting to disable browser menu options or mouse right-click menus with javascript does not provide any real "protection" for images. It is more an annoyance than a deterrent. Scripts like this are why I have my Firefox browser configured to not allow javascripts to "Disable or replace context menus". I browsed to your page linked above and tried right-clicking on the page. An alert box with "Function Disabled!" appeared, then when I clicked OK, the normal right-click menu appears (just as it should).