Валидация / санация и ООП - PullRequest
Новая
       9

Валидация / санация и ООП

0 голосов
/ 09 января 2019

Не уверен, что название достаточно информативное, тесто. Мне интересно, каков наилучший и лучший шаблон проектирования при создании объектно-ориентированной библиотеки - должен ли «клиент» отвечать за очистку данных, отправляемых этому «черному» box "или библиотека должна предоставлять набор инструментов для защиты от вредоносных действий.

Я приведу пример: Давайте предположим, что мы создаем библиотеку с открытым исходным кодом, которая обеспечивает интеграцию с вымышленным сервисом под названием fooCompany, который предоставляет REST API. Теперь наша библиотека должна отправлять запросы к этим API и предоставлять ей некоторые данные, например, для нашего примера возьмем токен аутентификации.

Самый простой код, вероятно, будет выглядеть примерно так: 

class fooCompany {
  private $apiToken;

  public function __construct($apiToken) {
    $this->apiToken = $apiToken;
  }

  public function send() {
    $ch = curl_init('https://fooCompany.xx/api/send');
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'Content-Type: application/json',
        'Authorization: Bearer ' . $this->apiToken
    ));

    $data = curl_exec($ch);
    curl_close($ch);
  }
}

Мы можем видеть, что если клиентское приложение, которое использует нашу библиотеку, не будет достаточно хорошо защищать apiToken, его приложение теперь будет уязвимо для атаки с внедрением заголовка.

Спасибо.

1 Ответ

0 голосов
/ 09 января 2019

Полагаю, простого решения такой проблемы не существует. По сути, вы описываете функцию, которую вы можете - или не можете - добавить в свой «продукт». Насколько я понимаю, это вообще не связано с охой. Это скорее стратегическое решение, которое вы должны принять. И это - конечно - зависит :

Как автор библиотеки, вы всегда должны спрашивать себя, где, когда, почему и кем будет использоваться ваша библиотека.

В целом, люди думают о библиотеках с определенными ожиданиями, и, безусловно, они будут лааааазыми.

Аккуратный, надежный, документированный , предотвращающий ошибки интерфейс с базовым ядром почти всегда будет высоко оценен. Код клиента автоматически приобретает качество и его легче поддерживать. Всем это нравится. Вы, как автор библиотеки, всегда будете лучше разбираться в «вымышленном сервисе под названием fooCompany», чем большинство пользователей библиотеки. Вы можете решить все за считанные минуты. Другим могут понадобиться дни.

Очевидно, что от вас требуется много работы ...

(Также) очевидно, что вопросы, связанные с безопасностью, не представляют никакой сложности: если вы уже ожидаете, что что-то произойдет, вы, конечно, должны приложить некоторые усилия здесь.

Принцип устойчивости гласит: Будьте консервативны в том, что вы делаете, будьте либеральными в том, что вы ожидаете от других.

Вы спрашивали о шаблонах проектирования: четко определите части вашей библиотеки, которые клиентский код должен явно использовать / вызывать. Это публичный API . Все остальное считается внутренним или ядром . В идеале, внутренние вещи вообще не должны подвергаться воздействию клиентов (если это возможно).

Разделяя вещи, вы можете сосредоточиться на разных целях. Внутренняя часть очень техническая и, как ожидается, будет часто меняться. Он делает тяжелую работу, если хотите. Публичный API имеет другие приоритеты. Это должно быть удобно, легко понять и иметь в виду (обратную) совместимость. Таким образом, вы сможете внести определенные изменения, которые вообще не потребуют прикосновения к клиентскому коду.

Кроме того, если вы когда-либо выпускаете и поддерживаете что-то, следуйте правилам семантического управления версиями . Людям это понравится.

...