ERROR when PHP script tries to connect to itself? Can I enable this somehow???

Hi guys,

I'm getting the following error due to (I assume) the server settings ISPConfig applies:

It seems as though ISPConfig WILL NOT allow the script to run and access itself. If I copy and paste the "could not open" URL directly into my browser I get the expected output but it seems that the ISPConfig settings are blocking the script from accessing itself???

Are there any APACHE Directives I could enable on a PER USER/SITE basis to allow the script to connect back to itself??? OR ideas as to a way round this? The script HAS to access that URL directly...

Many thanks

 

Error Log Results

Below are the messages from the error log. I know the problem is that the script can NOT connect to that URL - BUT If I plug that URL into my browser it works fine, so I was assuming ISPConfig doesn't let the script connect back to itself???


Users Error Log ( /var/www/web8/log/error.log ):

 

hey sierra

refer: http://simpleinvoices.org/forum/discussion/684/export-to-pdf-a-blank-pdf-document/#Comment_3527

not a solution - but something you can try

cheers

Justin kelly
- Simple Invoices

 

Thanks Justin,

I was posting over here as I was thinking that possibly the way I have ISPConfig and Apache setup - it may be blocking the connection back to itself... But I guess thats not the case.

 

Sorry Till I wasn't trying to argue or say that you were wrong, I guess I worded it wrong. I was just thinking that possibly the way I setup ISPConfig following the (centos 5 perfect server) that maybe I needed to add some apache directives to the website so that this would work.

I know I had to do something similar when I installed Drupal for a client.

Could it possilby be related to .htaccess? I saw that every site gets a .htpasswd file in the parent directory (i.e. the www/webX/.htpasswd)...

I was just hoping that I could figure this out...

 

Are there any errors in Apache's error log or the web site's error log?
What's in the .htaccess files?

 

Hey Falko,

Everythings been running smooth with my ISPConfig server until I couldn't get this application to work. ITS WORKING FOR EVERYONE over on the applications forums over at their homepage (www.simpleinvoices.org).

Here is what I get from the users error.log ( /var/www/web1/log/error.log ) - i edited out my IP and Domain Name:

I don't know a whole lot about .htaccess? I just noticed that in the root of EVERY users directory there is an .htpasswd file (i.e. /var/www/web1/.htpasswd ) The contents of this file look something like this:

Is it neccessary for me to add that .htpasswd username and password to the applications config file? I don't know if the site is using HTACCESS or not? I didn't have to add the .htpasswd UNW to any other web applications I have installed...

Thanks for any help Falko!

 

Is there an .htaccess file in the web site's document root or in the directory where you installed the web application?

 

Thanks again for trying to help me Falko!

Hey Falko,

YES, I do have an .htaccess file in my sites web root folder located at /var/www/web1/web/.htaccess . I think that DRUPAL put that file there. However, it does NOT have any UNW inside the file? Here is a view of the .htaccess file:

My main site lives at: http://www.mydomain.com/index.html and the local directory is /var/www/web1/web/index.html . THE NEW WEB APPLICATION I tried to install is located at http://www.mydomain.com/billing/index.html and the local directory is /var/www/web1/web/billing/index.html


Since that .htaccess file didn't have any UNW and the web application I am trying to install has a UNW section in the config.php file, I figured I needed to add a UNW and the only UNW I could find in a .htxxxxx file was the .htpasswd file in the PARENT directory of the web root folder /var/www/web1/.htpasswd.

I DO have a file called .htpasswd that lives in this folder though: /var/www/web1/.htpasswd .

I think I might be a little confused. Is .htaccess different from .htpasswd?

I thought .htaccess was the actual protection, and that possibly the .htpasswd was the UNW for the .htaccess file?

THANKS AGAIN FALKO!

 

Is there an .htaccess file in the billing/ directory?

You don't need something like UNW unless you want to password-protect a directory. The UNW line would then go into an .htpasswd file which is referenced from an .htaccess file.

 

Hiya:

For what it is worth I am having a similar issue with the pdf creation using simpleinvoices. Now, before Till reminds me that this isn't an ISPConfig issue, I too amd have this issue on ISPConfig and there does indeed seem to be something with the way ISPConfig writes its config files that seems to choke on simpleinvoices. The folks at simpleinvoices have offered numerous suggestions but I can't seem to make any of them work (see: http://simpleinvoices.org/forum/discussion/722/blank-pdfs/).

I am not sure if this helps, but log files are saying:

[Thu Jan 29 14:49:54 2009] [error] [client 192.168.1.201] Fetching: http://www.clickcreations.com/live/webdesign.html, referer: http://invoicing.venomcow.co.uk/simpleinvoices/library/pdf/
[Thu Jan 29 14:49:55 2009] [error] [client 192.168.1.201] Status code:200, referer: http://invoicing.venomcow.co.uk/simpleinvoices/library/pdf/
[Thu Jan 29 14:49:55 2009] [error] [client 192.168.1.201] Guessed: 'http://www.clickcreations.com/html/admin.css', referer: http://invoicing.venomcow.co.uk/simpleinvoices/library/pdf/

(note: http://invoicing.venomcow.co.uk is a local address and not accessible via the internet). I've tried clearing my cache, I've tried not using a subdomain. There is some mention of cURL not liking certificates but if I grep -lr "curl" * through the code I don't come up with any referecences to cURL being used in the code.

Cheers,


Ben.

 

Is there some .htaccess file that came with SimpleInvoices? If so, what's in it?

 

Only one and all it has in it is:

DirectoryIndex index.php

 

That cannot cause the problem. Not sure what it is then...

 

Oh well, thanks for trying! One of the Simple Invoices guy is going to see if her can re-write the pdf generation script so it doesn't call the whole URL ... hopefully that will fix it!