- This topic has 12 replies, 3 voices, and was last updated 13 years ago by
.
-
Posts
-
I’m trying to manually stamp your file pdf-stamper-sample-ebook.pdf, and get this error:
Fatal error: The encoded file [path reference removed] requires a license file
I already tried deactivate/remove/upload/activate of the pdf stapler plugin. It activates ok, but I still get the same error. Any ideas?
1) Some unusual things I noticed during my install were:
a) I couldn’t install wp plugins via zip upload; something about a permission error when writing to directory 2011/11; I always end up using ftp to upload new plugin files.
b) when I first activated pdf stamper, there was an error I couldn’t recall. I retried activation, but failed because your software detected that the key I had was already in use. I reloaded the plugins management page, which showed pdf stamper already installed and activated.
c) when adding products to eStore, the your form-based upload function also fails. Instead, I have to ftp to upload my product files.
2) The problem occurs in [path reference removed]
3) Manually stamp a file to duplicate the error
4) I installed wp v3.2.1; I just purchased 4 days ago and installed current versions of estore, affiliate platform, pdf stamper, and eMember.
5) I don’t think short codes are the issue. I’m just trying to manually stamp your sample pdf file.
6) I use fireFTP+Firefox to upload files.
I did deactivate/remove again. When I try to upload the zip file through wordpress’ upload facility, I get this error:
The uploaded file could not be moved to [path reference removed].
That directory has 777 permission.
Works now, but I had to give 777 permission to the [path reference removed] directory. Anything less and pdf stamping failed. I’m alone on my server, but I can’t say I’m very happy with the security risk.
Using 777 permission on PHP files is definitely not a good idea. Obviously the permission settings on your server is misconfigured so contact your hosting provider to fix the root issue. All WordPress plugin should be able to execute with a file permission of “644”.
I’m assuming that in this subanon had to 777 the destination directory for stamped files. If so I’m having a similar issue, as long as Other/Public permissions are set to rwx then pdf files are stamped ok (manually or via my implementation) but anything less than 7 for Other/Public and I get an error (in $value variable of the provided php post integration script) ‘SetaPDF_Error Object’.
Could admin elaborate a little on this comment, i.e. is there a common mistake that you have in mind:
“Obviously the permission settings on your server is misconfigured so contact your hosting provider to fix the root issue.”
I’ll talk to my host about this but I find that the more I can tell them the quicker they act
The issue can vary based on the server configuration but essentially the plugin is not running as the root user. All the plugins in WordPress environment should run as root user but in your case the plugin is running as “other” user and since the “other” user doesn’t have permission to modify file the stamping process fails.
Usually this happens when your server is using “DSO” as the php handler. Using “DSO” as the php handler is not good for security also. Most servers user “SUPHP” or “FastCGI” as the php handler.
Great thanks that helped me to find out some more info… I got this back from my hosting provider:
“If your account is on Unix, and you are using PHP you need to change the directory mode to 777 if you wish to add or remove files in the directory. To be able to write to files, you need to chmod the files to 666.”
Obviously I’ve now asked them why this is the case and if they can’t change this I’ll find a better host
In case this is of any use to others. My host will not run php as a CGI or SUPHP. So they recommend that I create a .htaccess file that allows only pdf’s to be read written or executed…
Deny from all
<FilesMatch “.(pdf)$”>
Allow from all
</FilesMatch>
Seems like an ok fallback solution to me but to be honest I might shop around for a different host.
Yeah, using the .htaccess is an okay solution but as I mentioned to you earlier I prefer to use a more secure solution. I won’t go into a blame game with web hosting companies… I have had my fare share of bad experiences with some of them:
- You must be logged in to reply to this topic.