-
-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make FpdfOutput work with allow_url_fopen=0 #192
Comments
I could reproduce the problem and got this message:
I agree it's good practice to have allow_url_fopen disabled. Not sure yet how to deal with it. How do other projects using FPDF do it? |
Maybe it's not that comfortable, but the file could be temoprarily saved (to a tmp folder), passed to fpdf to generate the Pdf File and deleteded afterwards. This is the solution i realized (see example above). |
Can you check wether script45 Memory Image Support works with |
Yes, i’ll check on Monday |
With the proposed script it will work.
|
Hi @kasoft Can you test this code please: private function addSwissQrCodeImage(): void
{
$qrCode = $this->getQrCode();
$yPosQrCode = 209.5 + $this->offsetY;
$xPosQrCode = 67 + $this->offsetX;
// vvv start of changes vvv
if (ini_get('allow_url_fopen') === "1") {
$this->fpdf->Image($qrCode->getDataUri($this->getQrCodeImageFormat()), $xPosQrCode, $yPosQrCode, 46, 46, 'png');
}
elseif (method_exists($this->fpdf, 'MemImage')) {
$qr = $qrCode->getAsString($this->getQrCodeImageFormat());
$this->fpdf->MemImage($qr, $xPosQrCode, $yPosQrCode, 46, 46);
} else {
throw new \RuntimeException('If directive "allow_url_fopen" is disabled, FPDF "Memory Image Support" is required');
}
/// ^^^ end of changes ^^^
} @sprain what do you think? I always prefer implicit before explicit. So the two conditons added here may hit the performance a little, but at least it's configured implicitely rather than having to configure some temp paths by the user. |
Thanks for all the work here! The code looks fine to me. I just wonder whether Also: we'll need to check whether TcPDF might have the same issue. |
FPDF misses a major feature by not supporting images from memory or as strings natively. But there's nothing we can do about that. Using temporary files seems terrible for me. Because it also comes with the necessity to manage files (writable directories, unique file names, delete image after generation, generally bad performance, ...). I predict, that this is hard to maintain during evolution of our code, and can also create big issues for users when the temporary files are not managed properly. So not necessary less support cases. IMO, it's the best to include a DomPDF-output to this library, which is a reasonable dependency for users that require to make PDFs right in PHP. So for less expirienced users, the support case would be closed by recommending to switch to DomPDF, which is a simple |
Thanks for the solution. I can confirm that it worked. Only the Line about the Position and the Size of the QR Code had to be adjusted.
|
FYI: This is now solved in v4.7. |
For security reasons, my Php Settings do not allow to directly pass the Qr Code from Qr Bill to FPDF as a base64 encoded String (allow_url_fopen=0). As the Class FpdF is final, there is no way to solve this by extending the Class. I would suggest to implement an option where you can define a path or tempfile. If this is set, the Qr Code could be saved there. I can try to figure something out. What so you think?
The text was updated successfully, but these errors were encountered: