This project does not seem to handle request data directly as such no vulnerable execution paths were found.
include
, or for example
via PHP's auto-loading mechanism.
These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more
1 | <?php |
||
2 | |||
3 | namespace Messenger\Mail; |
||
4 | |||
5 | use Cronario\AbstractJob; |
||
6 | use Cronario\AbstractWorker; |
||
7 | |||
8 | class Worker extends AbstractWorker |
||
9 | { |
||
10 | |||
11 | protected static $config |
||
12 | = [ |
||
13 | 'client' => [ |
||
14 | // "Mailer" => 'smtp', // Set mailer to use SMTP |
||
0 ignored issues
–
show
|
|||
15 | // "Host" => 'smtp1.example.com;smtp2.example.com', // Specify main and backup SMTP servers |
||
16 | // "SMTPAuth" => true, // Enable SMTP authentication |
||
17 | // "Username" => '[email protected]', // SMTP username |
||
18 | // "Password" => 'secret', // SMTP password |
||
19 | // "SMTPSecure" => 'tls', // Enable TLS encryption, `ssl` also accepted |
||
20 | // "Port" => 587, // TCP port to connect to |
||
21 | ] |
||
22 | ]; |
||
23 | |||
24 | // region VALIDATE ******************************************************** |
||
25 | |||
26 | /** |
||
27 | * @param Job $job |
||
28 | * |
||
29 | * @throws ResultException |
||
30 | */ |
||
31 | 2 | protected function validateJobParams(Job $job) |
|
32 | { |
||
33 | 2 | if (empty($job->getFromMail())) { |
|
34 | 1 | throw new ResultException(ResultException::ERROR_PARAM_FROM_MAIL); |
|
35 | } |
||
36 | |||
37 | 2 | if (empty($job->getFromName())) { |
|
38 | 1 | throw new ResultException(ResultException::ERROR_PARAM_FROM_NAME); |
|
39 | } |
||
40 | |||
41 | 2 | if (empty($job->getToMail())) { |
|
42 | 1 | throw new ResultException(ResultException::ERROR_PARAM_TO_MAIL); |
|
43 | } |
||
44 | |||
45 | 2 | if (empty($job->getSubject())) { |
|
46 | 1 | throw new ResultException(ResultException::ERROR_PARAM_SUBJECT); |
|
47 | } |
||
48 | |||
49 | 2 | if (empty($job->getBody())) { |
|
50 | 1 | throw new ResultException(ResultException::ERROR_PARAM_BODY); |
|
51 | } |
||
52 | |||
53 | 1 | } |
|
54 | |||
55 | // endregion ************************************************************* |
||
56 | |||
57 | /** |
||
58 | * @return \PHPMailer |
||
59 | */ |
||
60 | public function getMail() |
||
61 | { |
||
62 | $mail = new \PHPMailer(); |
||
63 | |||
64 | $clientConfig = static::getConfig('client'); |
||
65 | if(is_array($clientConfig) && count($clientConfig) > 0){ |
||
66 | foreach($clientConfig as $key => $value){ |
||
67 | $mail->{$key} = $value; |
||
68 | } |
||
69 | } |
||
70 | |||
71 | return $mail; |
||
72 | } |
||
73 | |||
74 | /** |
||
75 | * @param Job $job |
||
76 | * |
||
77 | * @return array |
||
78 | */ |
||
79 | 1 | protected function sendMail(Job $job) |
|
80 | { |
||
81 | |||
82 | 1 | $mail = $this->getMail(); |
|
83 | |||
84 | 1 | $mail->isHTML(true); |
|
85 | 1 | $mail->setFrom($job->getFromMail(), $job->getFromName()); |
|
86 | 1 | $mail->addAddress($job->getToMail()); |
|
87 | |||
88 | 1 | $mail->Subject = $job->getSubject(); |
|
0 ignored issues
–
show
It seems like
$job->getSubject() can also be of type integer . However, the property $Subject is declared as type string . Maybe add an additional type check?
Our type inference engine has found a suspicous assignment of a value to a property. This check raises an issue when a value that can be of a mixed type is assigned to a property that is type hinted more strictly. For example, imagine you have a variable Either this assignment is in error or a type check should be added for that assignment. class Id
{
public $id;
public function __construct($id)
{
$this->id = $id;
}
}
class Account
{
/** @var Id $id */
public $id;
}
$account_id = false;
if (starsAreRight()) {
$account_id = new Id(42);
}
$account = new Account();
if ($account instanceof Id)
{
$account->id = $account_id;
}
![]() |
|||
89 | 1 | $mail->Body = $job->getBody(); |
|
0 ignored issues
–
show
It seems like
$job->getBody() can also be of type integer . However, the property $Body is declared as type string . Maybe add an additional type check?
Our type inference engine has found a suspicous assignment of a value to a property. This check raises an issue when a value that can be of a mixed type is assigned to a property that is type hinted more strictly. For example, imagine you have a variable Either this assignment is in error or a type check should be added for that assignment. class Id
{
public $id;
public function __construct($id)
{
$this->id = $id;
}
}
class Account
{
/** @var Id $id */
public $id;
}
$account_id = false;
if (starsAreRight()) {
$account_id = new Id(42);
}
$account = new Account();
if ($account instanceof Id)
{
$account->id = $account_id;
}
![]() |
|||
90 | 1 | $mail->AltBody = strip_tags($job->getBody()); |
|
91 | |||
92 | 1 | $attachments = $job->getAttachment(); |
|
93 | 1 | if (!empty($attachments) && is_array($attachments) && count($attachments) > 0) { |
|
94 | 1 | foreach ($attachments as $key => $attach) { |
|
95 | 1 | if(isset($attach[Job::P_PARAM_ATTACHMENT__NAME])){ |
|
96 | 1 | $mail->addAttachment($attach[Job::P_PARAM_ATTACHMENT__PATH] , $attach[Job::P_PARAM_ATTACHMENT__NAME]); |
|
97 | 1 | } else { |
|
98 | $mail->addAttachment($attach[Job::P_PARAM_ATTACHMENT__PATH]); |
||
99 | } |
||
100 | 1 | } |
|
101 | 1 | } |
|
102 | |||
103 | 1 | $isSend = $mail->send(); |
|
104 | |||
105 | return [ |
||
106 | 'success' => $isSend |
||
107 | 1 | ]; |
|
108 | } |
||
109 | |||
110 | /** |
||
111 | * @param AbstractJob|Job $job |
||
112 | * |
||
113 | * @throws ResultException |
||
114 | */ |
||
115 | 2 | protected function doJob(AbstractJob $job) |
|
116 | { |
||
117 | 2 | $this->validateJobParams($job); |
|
0 ignored issues
–
show
$job of type object<Cronario\AbstractJob> is not a sub-type of object<Messenger\Mail\Job> . It seems like you assume a child class of the class Cronario\AbstractJob to be always present.
This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass. Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type. ![]() |
|||
118 | |||
119 | try { |
||
120 | |||
121 | 1 | $response = $this->sendMail($job); |
|
0 ignored issues
–
show
$job of type object<Cronario\AbstractJob> is not a sub-type of object<Messenger\Mail\Job> . It seems like you assume a child class of the class Cronario\AbstractJob to be always present.
This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass. Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type. ![]() |
|||
122 | 1 | $resultData['response'] = $response; |
|
0 ignored issues
–
show
Coding Style
Comprehensibility
introduced
by
$resultData was never initialized. Although not strictly required by PHP, it is generally a good practice to add $resultData = array(); before regardless.
Adding an explicit array definition is generally preferable to implicit array definition as it guarantees a stable state of the code. Let’s take a look at an example: foreach ($collection as $item) {
$myArray['foo'] = $item->getFoo();
if ($item->hasBar()) {
$myArray['bar'] = $item->getBar();
}
// do something with $myArray
}
As you can see in this example, the array This might or might not be intended. To make your intention clear, your code more readible and to avoid accidental bugs, we recommend to add an explicit initialization $myArray = array() either outside or inside the foreach loop. ![]() |
|||
123 | |||
124 | 1 | } catch (\Exception $ex) { |
|
125 | throw new ResultException(ResultException::RETRY_TRANSPORT_ERROR); |
||
126 | } |
||
127 | |||
128 | 1 | if(!$resultData['response']['success']){ |
|
129 | throw new ResultException(ResultException::R_FAILURE, $resultData); |
||
130 | } |
||
131 | |||
132 | 1 | throw new ResultException(ResultException::R_SUCCESS, $resultData); |
|
133 | } |
||
134 | } |
||
135 |
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.
The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.
This check looks for comments that seem to be mostly valid code and reports them.