|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: FudAPI Examples [message #35934 is a reply to message #19431] |
Wed, 21 February 2007 00:40 |
dardhal
Messages: 9 Registered: November 2006 Location: Spain
Karma: 0
|
Junior Member |
|
|
Sorry if the following is too naive, or has been somewhat been replied before elsewhere, but didn't find an answer.
The fact is I am doing some kind of thread and message automation: a cron job downloads a document (PDF), checks some data inside it, and then creates a new reply under an already existing thread with a simple body text and the ZIPped PDF document attached.
The horrible but simple PHP code I have created is the following. It is run from the command line through a PHP 5.2.0 Debian binary:
#!/usr/bin/php -q
<?php
require_once("/srv/www/www.site.es/fudforum-2.7.6-nobrowse/include/GLOBALS.php");
require_once("/srv/www/www.site.es/fudforum-2.7.6-nobrowse/scripts/fudapi.inc.php");
$subject = "Message subject";
$body = "Simple, concise, message body";
$attachments = array("/tmp/compressed_pdf.zip");
fud_new_reply($subject, $body, 0, "username", 1080, null, $attachments, null);
?>
Except for a couple of warnings I consider irrelevant to the problem, it seems to run OK, and in fact a new message is created under the message with ID 1080. Even the attachment information gets added, the linkable icon and that. Size reported for the attached file is OK, however, it downloads a zero-length file.
Checking the FUDforum logs shows the problem. The PHP script runs, but leaves the following in the logs:
[Error] unable to move uploaded file
[Message Sent to User]
From: srv/www/www.site.es/fudforum-2.7.6-nobrowse/tmp/fuda_eqxSg9
To: /srv/www/www.site.es/fudforum-2.7.6-nobrowse/files/190.atch
[User IP] 0.0.0.0
[Requested URL] http://
And the same problem happens running the PHP script (remember, from the command line) as user root or as the webserver user (www-data). Both users have enough permissions on both directories, and the original file "/tmp/compressed_pdf.zip" is also accessible and with proper permissions.
Any clue about this? Maybe I am oversimplifying the script, but my PHP skills are null, and fudAPI knowledge is still quite low.
|
|
|
|
|
|
Re: FudAPI Examples [message #36091 is a reply to message #35953] |
Sat, 03 March 2007 20:18 |
dardhal
Messages: 9 Registered: November 2006 Location: Spain
Karma: 0
|
Junior Member |
|
|
Ilia wrote on Fri, 23 February 2007 02:42 | You need permissions to be 777 not 755
|
Sorry for the delay. Even after chmod'ing both tmp/ and files/ directories to 777, the script doesn't work with the same error "unable to move uploaded file". From the command line and running the PHP script as root.
I have had some free time to investigate, and I think I have found the place where it fails. function _fud_message_post calls attach_add, and inside this function safe_attachment_copy gets called, both are implemented in include/theme/default/attach.inc
Inside function safe_attachment_copy there is this little piece of code:
<?php if (!$ext && !move_uploaded_file($source, $loc)) {
error_dialog('unable to move uploaded file', 'From: '.$source.' To: '.$loc, 'ATCH');
} else if ($ext && !copy($source, $loc)) {
error_dialog('unable to handle file attachment', 'From: '.$source.' To: '.$loc, 'ATCH');
} ?>
And as the error message is an "unable to move uploaded file", and $ext contains zero from the caller, it seems PHP's move_uploaded_file is failing. From the PHP documentation:
Quote: | This function checks to ensure that the file designated by filename is a valid upload file (meaning that it was uploaded via PHP's HTTP POST upload mechanism). If the file is valid, it will be moved to the filename given by destination
See also is_uploaded_file(), and the section Handling file uploads for a simple usage example.
|
So I have inserted a test just before the move_uploaded_file call, just to see if from PHP point of view the attachment was uploaded or not:
<?php if ( is_uploaded_file($source) ) {
error_dialog('The file WAS uploaded', 'OK');
}
else {
error_dialog('The file was NOT uploaded','KO');
} ?>
And I get, as expected, the following error:
So it seems the fix is to make PHP believe the attachment was uploaded, even if it was not. Don't know if this is possible, and if it requires modification of my crappy PHP script, some kind of FUDapi initialization, etc.
-
Attachment: error.jpg
(Size: 9.82KB, Downloaded 1709 times)
|
|
|
|
Re: FudAPI Examples [message #36103 is a reply to message #36100] |
Sun, 04 March 2007 18:50 |
dardhal
Messages: 9 Registered: November 2006 Location: Spain
Karma: 0
|
Junior Member |
|
|
I think the above patch doesn't fully fix the bug. If I use the fix above, there is no complain message, but the attachment is not even created, in fact it is not shown in the message.
I think this is a problem with function attach_add, which is defined as:
function attach_add($at, $owner, $attach_opt=0, $ext=0)
The patch above makes FUDapi call the function with attach_opt set to 1, and while I don't know the meaning of this parameter, I think what the patch tried to set is ext, not attach_opt.
In fact, I remade the patch to the following:
- $val = attach_add($at, $msg->poster_id);
+ $val = attach_add($at, $msg->poster_id, 0, 1);
Tried again, and now it works (but when the script is run as root, the browser is unable to download the attachment, due to permissions, the script run as www-data is ok). So I think my theory is right, or at least points in the right direction.
Hope it helps.
|
|
|
Re: FudAPI Examples [message #36122 is a reply to message #36103] |
Tue, 06 March 2007 00:08 |
Ilia
Messages: 13241 Registered: January 2002
Karma: 0
|
Senior Member Administrator Core Developer |
|
|
Thanks for poiting out the problem it is now fixed in CVS. As far as permissions go, you may want to unlock the forum files. In this case new files are created with a world-read permission, allowing you to run the script as root.
FUDforum Core Developer
|
|
|