PDF creation process cannot load images after adding security check (cookies fail?)
I recently added a security check in the Routes.php file to ensure that these images are only accessible to those who should have access to the images.
It works as expected for user interaction, but now when I create PDFs it seems that the process that receives the image is not allowed and therefore the image cannot be loaded into PDF.
This is how an image is rendered in a Blade PDF file:
<img src="{{ URL::to('image/person/signature',$person->person_token) }} ">
I access it via Facade ( URL
), but for some reason the session cookie doesn't seem to be passed in this request, so that's why it didn't pass the security check.
Here's a security check:
Route::get('image/person/signature/{authToken}',function($authToken){
// This permission checking should actually probably be in the filters file
$loggedUser = Auth::user();
$person = Person::getByAuthToken($authToken);
if ($person instanceOf Person){
// PDF is getting shut out here
if($loggedUser->company_id == $person->company_id || $loggedUser->isAdmin()) {
// Processing goes here
} else{
die('You are not authorized to perform this function. Your IP address has been logged.');
}
} else {
die('You are not authorized to perform this function. Your IP address has been logged.');
}
});
I also tried adding the following security check conditions to allow access to the process, which didn't work:
-
$loggedUser instanceOf PDF
-
$loggedUser instanceOf ServiceProvider
-
Auth::check()
The fact that Auth::check()
did not work is suspicious and indicates that no cookie / session information is being sent.
I somehow doubt that changing the settings in the DOMPDF will help with this, since it is simply blocked by the security check. Here is the actual tool I am using for DOMPDF / Laravel integration . DomPDF is registered as a service provider in my application under the facade PDF
.
Remember, this is of course not a path issue, because it was working before I did this security check. All the questions related to this on SO seem to stem from this.
How can I let the PDF process access the image without crazy workarounds?
source to share
Probably the easiest way is to skip HTTP entirely and access the file through the file system.
<img src="{{ public_path() . '/image/person/signature }} ">
(I'm not too familiar with Laravel, so maybe someone can clean up this.)
This assumes that the image is available in the public path of the local filesystem. If it is a generated file, something not directly accessible, or maybe too much work (for example, you reuse the same template for web and PDF creation), then you have to think a little about something more complicated.
So, something a little more complex ... create a custom thread context from a custom request and pass it to dompdf. If you are using authentication cookies for example, you can try something like this:
$cookie_data = implode(
"; ", array_map(
function($k, $v) {
return "$k=$v";
},
array_keys($_COOKIE),
array_values($_COOKIE)
)
);
$opts = array(
'http'=>array(
'method'=>'GET',
'header'=>'Cookie: ' . $cookie_data
)
);
$context = stream_context_create($opts);
$dompdf = new DOMPDF;
$dompdf->set_http_context($context);
...
I'm just taking a hit in the dark here (I don't need to check this?). This assumes that your user is triggering the PDF rendering (it looks like it is) and that the AuthN engine is one that can be accessed and added to the user's thread context. You may need to adjust the context to get the exact configuration required to authenticate.
Context code is stripped from PHP file_get_contents () and headers and cookie munger from Sending cookies stored in global $ _COOKIE PHP curl .
source to share