Убедитесь, что небезопасный код не используется случайно

Функция f()использует eval()(или что-то столь же опасное) с данными, которые я создал и сохранил local_fileна компьютере, на котором запущена моя программа:

import local_file

def f(str_to_eval):
    # code....
    # .... 
    eval(str_to_eval)    
    # ....
    # ....    
    return None


a = f(local_file.some_str)

f() безопасен для запуска, так как строки, которые я ему предоставляю, мои.

Однако, если я когда-нибудь решу использовать его для чего-то небезопасного (например, пользовательского ввода), все может пойти ужасно неправильно . Кроме того, если local_fileперестанет быть локальным, это создаст уязвимость, так как мне нужно будет доверять машине, которая также предоставляет этот файл.

Как я должен убедиться, что я никогда не «забуду», что эта функция небезопасна в использовании (если не соблюдены определенные критерии)?

_{Примечание: eval()опасно и обычно может быть заменено чем-то безопасным.}

Определите тип для украшения «безопасных» входов. В вашей функции f()утверждайте, что аргумент имеет этот тип, или выведите ошибку. Будьте достаточно умны, чтобы никогда не определять ярлык def g(x): return f(SafeInput(x)).

Пример:

class SafeInput(object):
  def __init__(self, value):
    self._value = value

  def value(self):
    return self._value

def f(safe_string_to_eval):
  assert type(safe_string_to_eval) is SafeInput, "safe_string_to_eval must have type SafeInput, but was {}".format(type(safe_string_to_eval))
  ...
  eval(safe_string_to_eval.value())
  ...

a = f(SafeInput(local_file.some_str))

Несмотря на то, что это легко обойти, это усложняет случайность. Люди могут критиковать такую ​​драконовскую проверку типа, но они упустят момент. Поскольку SafeInputтип - это просто тип данных, а не объектно-ориентированный класс, который можно разделить на подклассы, проверка на идентичность типа с type(x) is SafeInputболее безопасна, чем проверка на совместимость с типом isinstance(x, SafeInput). Так как мы хотим применить определенный тип, игнорирование явного типа и просто неявная типизация утки здесь также не являются удовлетворительными. В Python есть система типов, поэтому давайте использовать ее для выявления возможных ошибок!

Как однажды заметил Джоэл, заставьте неправильный код выглядеть неправильно (прокрутите вниз до раздела «Реальное решение», или, что еще лучше, прочитайте его полностью; оно того стоит, даже если оно обращается к переменной вместо имен функций). Поэтому я скромно предлагаю переименовать вашу функцию в нечто вроде f_unsafe_for_external_use()- вы, скорее всего, сами придумаете какую-нибудь схему аббревиатур.

Редактировать: я думаю, что предложение Амона является очень хорошим, основанным на ОО вариантом на ту же тему :-)

В дополнение к предложению @amon, вы также можете подумать о комбинировании здесь шаблона стратегии и шаблона объекта метода.

class AbstractFoobarizer(object):
    def handle_cond(self, foo, bar):
        """
        Handle the event or something.
        """
        raise NotImplementedError

    def run(self):
        # do some magic
        pass

И тогда «нормальная» реализация

class PrintingFoobarizer(AbstractFoobarizer):
    def handle_cond(self, foo, bar):
        print("Something went very well regarding {} and {}".format(foo, bar))

И реализация admin-input-eval

class AdminControllableFoobarizer(AbstractFoobarizer):
    def handle_cond(self, foo, bar):
        # Look up code in database/config file/...
        code = get_code_from_settings()
        eval(code)

(Примечание: на примере реального мира я мог бы привести лучший пример).