literat /
srazvs
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 App\Presenters; |
||
| 4 | |||
| 5 | use App\Models\SettingsModel; |
||
| 6 | use App\Services\Emailer; |
||
| 7 | use Tracy\Debugger; |
||
| 8 | |||
| 9 | class SettingsPresenter extends BasePresenter |
||
| 10 | { |
||
| 11 | |||
| 12 | /** |
||
| 13 | * @var Emailer |
||
| 14 | */ |
||
| 15 | private $emailer; |
||
| 16 | |||
| 17 | /** |
||
| 18 | * @param SettingsModel $settingsModel |
||
| 19 | * @param Emailer $emailer |
||
| 20 | */ |
||
| 21 | public function __construct(SettingsModel $settingsModel, Emailer $emailer) |
||
| 22 | { |
||
| 23 | $this->setModel($settingsModel); |
||
|
0 ignored issues
–
show
|
|||
| 24 | $this->setEmailer($emailer); |
||
| 25 | } |
||
| 26 | |||
| 27 | /** |
||
| 28 | * @param string $id |
||
| 29 | * @return void |
||
| 30 | */ |
||
| 31 | public function actionUpdate($id) |
||
| 32 | { |
||
| 33 | try { |
||
| 34 | $data = $this->getHttpRequest()->getPost(); |
||
| 35 | $this->getModel()->modifyMailJSON($id, $data['subject'], $data['message']); |
||
| 36 | |||
| 37 | Debugger::log('Settings: mail type ' . $id . ' update succesfull.', Debugger::INFO); |
||
| 38 | $this->flashMessage('Settings: mail type ' . $id . ' update succesfull.', 'ok'); |
||
| 39 | } catch(Exception $e) { |
||
|
0 ignored issues
–
show
The class
App\Presenters\Exception does not exist. Did you forget a USE statement, or did you not list all dependencies?
Scrutinizer analyzes your It seems like the listed class was neither found in your dependencies, nor was it found in the analyzed files in your repository. If you are using some other form of dependency management, you might want to disable this analysis. Loading history...
|
|||
| 40 | Debugger::log('Settings: mail type ' . $id . ' update failed, result: ' . $e->getMessage(), Debugger::ERROR); |
||
| 41 | $this->flashMessage('Settings: mail type ' . $id . ' update failed, result: ' . $e->getMessage(), 'error'); |
||
| 42 | } |
||
| 43 | |||
| 44 | $this->redirect('Settings:listing'); |
||
| 45 | } |
||
| 46 | |||
| 47 | /** |
||
| 48 | * @return void |
||
| 49 | */ |
||
| 50 | public function actionDebug() |
||
| 51 | { |
||
| 52 | try { |
||
| 53 | $activate = false; |
||
| 54 | $data = $this->getHttpRequest()->getPost(); |
||
| 55 | |||
| 56 | if(array_key_exists('debug', $data)) { |
||
| 57 | $activate = true; |
||
| 58 | } |
||
| 59 | |||
| 60 | $this->getModel()->updateDebugRegime($activate); |
||
| 61 | |||
| 62 | Debugger::log('Settings: debug regime update succesfull.', Debugger::INFO); |
||
| 63 | $this->flashMessage('Settings: debug regime update succesfull.', 'ok'); |
||
| 64 | } catch(Exception $e) { |
||
|
0 ignored issues
–
show
The class
App\Presenters\Exception does not exist. Did you forget a USE statement, or did you not list all dependencies?
Scrutinizer analyzes your It seems like the listed class was neither found in your dependencies, nor was it found in the analyzed files in your repository. If you are using some other form of dependency management, you might want to disable this analysis. Loading history...
|
|||
| 65 | Debugger::log('Settings: debug update update failed, result: ' . $e->getMessage(), Debugger::ERROR); |
||
| 66 | $this->flashMessage('Settings: debug regime update failed, result: ' . $e->getMessage(), 'error'); |
||
| 67 | } |
||
| 68 | |||
| 69 | $this->redirect('Settings:listing'); |
||
| 70 | } |
||
| 71 | |||
| 72 | /** |
||
| 73 | * @param string $id |
||
| 74 | * @return void |
||
| 75 | */ |
||
| 76 | public function actionMail($id) |
||
| 77 | { |
||
| 78 | try { |
||
| 79 | $recipient = $this->getHttpRequest()->getPost()['test-mail']; |
||
| 80 | $jsonMail = $this->getModel()->getMailJSON($id); |
||
| 81 | |||
| 82 | $this->getEmailer() |
||
| 83 | ->sendMail( |
||
| 84 | [$recipient => ''], |
||
| 85 | $jsonMail->subject, |
||
| 86 | html_entity_decode($jsonMail->message) |
||
| 87 | ); |
||
| 88 | |||
| 89 | Debugger::log('Settings: mail type ' . $id . ' succesfully send to recipient ' . $recipient, Debugger::INFO); |
||
| 90 | $this->flashMessage('Settings: mail type ' . $id . ' succesfully send.', 'ok'); |
||
| 91 | } catch (Exception $e) { |
||
|
0 ignored issues
–
show
The class
App\Presenters\Exception does not exist. Did you forget a USE statement, or did you not list all dependencies?
Scrutinizer analyzes your It seems like the listed class was neither found in your dependencies, nor was it found in the analyzed files in your repository. If you are using some other form of dependency management, you might want to disable this analysis. Loading history...
|
|||
| 92 | Debugger::log('Settings: mail type ' . $id . ' send to recipient ' . $recipient . ' failed, result: ' . $e->getMessage(), Debugger::ERROR); |
||
| 93 | $this->flashMessage('Settings: mail type ' . $id . ' send to recipient failed, result: ' . $e->getMessage(), 'error'); |
||
| 94 | } |
||
| 95 | |||
| 96 | $this->redirect('Settings:listing'); |
||
| 97 | } |
||
| 98 | |||
| 99 | /** |
||
| 100 | * @return void |
||
| 101 | */ |
||
| 102 | public function renderListing() |
||
| 103 | { |
||
| 104 | $settingsModel = $this->getModel(); |
||
| 105 | $template = $this->getTemplate(); |
||
| 106 | $error = ''; |
||
|
0 ignored issues
–
show
$error is not used, you could remove the assignment.
This check looks for variable assignements that are either overwritten by other assignments or where the variable is not used subsequently. $myVar = 'Value';
$higher = false;
if (rand(1, 6) > 3) {
$higher = true;
} else {
$higher = false;
}
Both the Loading history...
|
|||
| 107 | |||
| 108 | $template->payment_subject = $settingsModel->getMailJSON('cost')->subject; |
||
|
0 ignored issues
–
show
Accessing
payment_subject on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 109 | $template->payment_message = $settingsModel->getMailJSON('cost')->message; |
||
|
0 ignored issues
–
show
Accessing
payment_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 110 | $template->payment_html_message = html_entity_decode($settingsModel->getMailJSON('cost')->message); |
||
|
0 ignored issues
–
show
Accessing
payment_html_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 111 | $template->advance_subject = $settingsModel->getMailJSON('advance')->subject; |
||
|
0 ignored issues
–
show
Accessing
advance_subject on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 112 | $template->advance_message = $settingsModel->getMailJSON('advance')->message; |
||
|
0 ignored issues
–
show
Accessing
advance_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 113 | $template->advance_html_message = html_entity_decode($settingsModel->getMailJSON('advance')->message); |
||
|
0 ignored issues
–
show
Accessing
advance_html_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 114 | $template->tutor_subject = $settingsModel->getMailJSON('tutor')->subject; |
||
|
0 ignored issues
–
show
Accessing
tutor_subject on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 115 | $template->tutor_message = $settingsModel->getMailJSON('tutor')->message; |
||
|
0 ignored issues
–
show
Accessing
tutor_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 116 | $template->tutor_html_message = html_entity_decode($settingsModel->getMailJSON('tutor')->message); |
||
|
0 ignored issues
–
show
Accessing
tutor_html_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 117 | $template->reg_subject = $settingsModel->getMailJSON('post_reg')->subject; |
||
|
0 ignored issues
–
show
Accessing
reg_subject on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 118 | $template->reg_message = $settingsModel->getMailJSON('post_reg')->message; |
||
|
0 ignored issues
–
show
Accessing
reg_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 119 | $template->reg_html_message = html_entity_decode($settingsModel->getMailJSON('post_reg')->message); |
||
|
0 ignored issues
–
show
Accessing
reg_html_message on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 120 | $template->debugRegime = $settingsModel->findDebugRegime(); |
||
|
0 ignored issues
–
show
Accessing
debugRegime on the interface Nette\Application\UI\ITemplate suggest that you code against a concrete implementation. How about adding an instanceof check?
If you access a property on an interface, you most likely code against a concrete implementation of the interface. Available Fixes
Loading history...
|
|||
| 121 | } |
||
| 122 | |||
| 123 | /** |
||
| 124 | * @return Emailer |
||
| 125 | */ |
||
| 126 | protected function getEmailer() |
||
| 127 | { |
||
| 128 | return $this->emailer; |
||
| 129 | } |
||
| 130 | |||
| 131 | /** |
||
| 132 | * @param Emailer $emailer |
||
| 133 | * @return $this |
||
| 134 | */ |
||
| 135 | protected function setEmailer(Emailer $emailer) |
||
| 136 | { |
||
| 137 | $this->emailer = $emailer; |
||
| 138 | return $this; |
||
| 139 | } |
||
| 140 | |||
| 141 | } |
||
| 142 |
It seems like the type of the argument is not accepted by the function/method which you are calling.
In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.
We suggest to add an explicit type cast like in the following example: