requinix

Right. So make sure the authentication doesn't apply to starter-manuals. <Directory starter-manuals> Order allow,deny Allow from all </Directory>

It's not just about files but the thing(s) represented by the URL. As Kevin said, if the page references a product that does not exist then send a 404. You should not redirect to the 404 page as that sends a 300-level response (original page -> 3xx -> error page -> 404), but you can rewrite to it (via mod_rewrite sans-[R] or ErrorDocument with a filename) and that's where the 404 should come in. So here it is: if I go to a page, what response do I get back? If it's a 404 then that's good. If it's a 3xx redirect to a 404 page then that's bad. If it's a 200 then that's bad. (Not meaning "harmful" bad, merely "not what it should be doing" bad.)

You can add the authentication back anytime - just make sure it doesn't apply to anything in /files/starter-manuals.

Actually I was hoping for more error messages, but okay. cURL could give you exact HTTP error codes and the response, if any, which may help. Sounds like it's still blocked. They should have access logs showing the failed connections...

I don't remember Apache's request lifecycle very well but it may be trying to authenticate before it does the redirect. What are you using to set permissions on that directory? Can you lift them temporarily while you check if the redirection works?

Your first Rule suggests that the URL you're matching against does not start with a slash. (They may or may not depending on your setup.) So try removing that from the new one. Easier would be to use the Redirect directive instead. Redirect permanent /files/starter-manuals /admin_files/PDF

Use your browser, or an extension if it's not native, to watch the HTTP request that gets sent with the AJAX. Then simulate that using PHP - probably cURL.

Of the HTTP 1.1 codes, 404 Not Found and 410 Gone are really the only ones related to resources going away (besides the 3xx redirections). The difference is that 410 is "this resource is gone for good and not accessible anywhere else we know of/can redirect you to" while 404 is merely "the resource isn't here right now". In fact, they specifically say to use 404 and not 410 if you don't know that the resource was permanently removed.

What happens if you try to use file_get_contents() or cURL to retrieve the XML?

How are you storing the time in the table? With a TIME? Or as a string? strtotime() works with dates only so don't use it for this. Besides, it would convert a HH:MM:SS string to a straight number and that doesn't really help here. Make sure they've inputted a valid HH:MM:SS value and use that right in the query.

Prepared statements are good for two situations: 1. Repeating the same basic query many times but with different data each time. Inserting data from a CSV file is a good example: the structure of the query is the same for every row, but the data varies. 2. When you don't want to deal with escaping values. It trades slightly less performance for a more-or-less guarantee that you won't be susceptible to SQL injection. You say there's one query? #1 won't help much but #2 may.

Fortunately you don't have to deal with namespaces. What have you tried? Seen SimpleXML yet?

Probably because you don't have anything that sets that particular variable. There's a get_field('thumbnail') function call but there's no $get_field variable.

get_field('thumbnail') returned an array. Apparently that's because the thumbnail is some sort of array "type". So that's the next place for you to start looking. Why is it an array? Have you considered outputting that value to see what it contains? Maybe it's supposed to be an array and you're supposed to get a specific value from it.

What's wrong is that $VUrl is an array and not the string you're expecting it to be. Start looking at whatever calls the CheckExistance function to see why that is and what you should do to fix it.

Yup. You can still do exact searches for string IP addresses, of course, but you lose out on the ability to do a range search (such as "everybody using the IP addresses 127.0.0.1 - 127.0.255.255"). But if you don't need to do that then there's no problem. [edit] Worth mentioning is that you can convert string number at any point in the future so what you choose now doesn't have to be set in stone.

You don't set ETag values for individual files. You enable it for a set of files, be that *.* or *.jpg or whatever, and tell the web server how to calculate the value. For example, Apache can calculate the value based on the file modification time and/or size and/or inode.

An email is a string so it gets a string type. An IP address... yeah. What are you going to do with it? As a string it gets stored as something you can easily read but it isn't suited very well for sophisticated searches; as a number ("127.0.0.1" is 2130706433) is great for exact or range searches but it needs formatting in code to get it into the normal A.B.C.D form useful for humans.

file_get_contents is the simplest. Just treat the URL like a file - PHP abstracts away those kinds of details. allow_url_fopen is the setting that allows you to do things like this. It's generally on, but if it's off then you'll have to find a non-PHP solution. [edit] For some reason I thought cURL (the alternat-- no wait, the alternative) needed that setting. It doesn't. However I still think file_get_contents() is fine because you should be validating user input anyways, especially if it has to do with file access, and IMO the benefits outweighs the risks. But yeah, cURL is fine too.

The two things they pointed out are important. Very important. But really, you shouldn't be doing this HTTP stuff yourself. Use cURL. Looks like $curl = curl_init("https://secure2.epdq.co.uk/cgi-bin/CcxBarclaysEpdqEncTool.e"); curl_setopt_array($curl, array( CURLOPT_POST => true, CURLOPT_POSTFIELDS => $params, CURLOPT_RETURNTRANSFER => true )); $output = curl_exec($curl); curl_close($curl);

Yes, that is still the case.

Using their receipts. That they made available to you, which you hopefully copied for yourself because an auditor won't accept an excuse of "but I can't access my receipt online anymore". Well yeah, if someone wanted hard copies of stuff which only happened digitally, somebody would have to do a lot of printing. Obviously. In general the IRS accepts electronic receipts. See procedure 97-22 (starts on page 9) for the legal details. Disclaimer: as with all legal advice given freely on the internet, you should take anything said with a grain of salt and contact a lawyer if it's that important.

In a database? I'm not sure what you're asking. Record the data, don't delete it, and present it to whomever you want however you want.

Lowercasing will only happen if you explicitly did something to make it happen. Whatever it is, it's in your code ("code" of some form or another).

They're looking for open proxies. It's normal, and as long as you're not vulnerable it's nothing to worry about. If you want to take the extra step to totally block access you can do RewriteEngine on RewriteCond %{REQUEST_URI} ^[^?]*:// RewriteRule ^ - [F,L]More powerful would be modsecurity, but the default install tends to block some legitimate requests so it may take some fine-tuning.