Upewnij się, że niebezpieczny kod nie zostanie przypadkowo użyty

Funkcja f()wykorzystuje eval()(lub coś równie niebezpiecznego) z danymi, które utworzyłem i zapisałem local_filena komputerze z uruchomionym programem:

import local_file

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


a = f(local_file.some_str)

f() jest bezpieczny do uruchomienia, ponieważ ciągi, które mu dostarczam, są moje.

Jeśli jednak kiedykolwiek zdecyduję się użyć go do czegoś niebezpiecznego (np. Dane wprowadzone przez użytkownika), sprawy mogą się potoczyć bardzo źle . Ponadto, jeśli local_fileprzestanie być lokalny, stworzy to lukę, ponieważ musiałbym zaufać maszynie, która również udostępnia ten plik.

Jak mam się upewnić, że nigdy nie „zapomnę”, że korzystanie z tej funkcji jest niebezpieczne (chyba że zostaną spełnione określone kryteria)?

_{Uwaga: eval()jest niebezpieczny i zwykle można go zastąpić czymś bezpiecznym.}

Zdefiniuj typ ozdabiania „bezpiecznych” wejść. W swojej funkcji sprawdź f(), czy argument ma ten typ, lub wyrzuć błąd. Bądź wystarczająco inteligentny, aby nigdy nie definiować skrótu def g(x): return f(SafeInput(x)).

Przykład:

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))

Chociaż można to łatwo obejść, utrudnia to przypadkowo. Ludzie mogą krytykować taką drakońską kontrolę typu, ale nie rozumieją o co chodzi. Ponieważ SafeInputtyp jest tylko typem danych, a nie klasą obiektową, którą można podklasować, sprawdzanie tożsamości typu za pomocą type(x) is SafeInputjest bezpieczniejsze niż sprawdzanie zgodności z typem isinstance(x, SafeInput). Ponieważ chcemy wymusić określony typ, ignorowanie typu jawnego i samo pisanie niejawnego kaczego tekstu również tutaj nie jest satysfakcjonujące. Python ma system typów, więc użyjmy go, aby wyłapać ewentualne błędy!

Jak kiedyś zauważył Joel, spraw, aby zły kod wyglądał źle (przewiń w dół do sekcji „Prawdziwe rozwiązanie” lub lepiej przeczytaj go całkowicie; warto, nawet jeśli adresuje zmienną zamiast nazw funkcji). Dlatego pokornie sugeruję zmienić nazwę funkcji na coś w stylu f_unsafe_for_external_use()- najprawdopodobniej sam wymyślisz jakiś schemat skrótów.

Edycja: Myślę, że sugestia Amona jest bardzo dobrą, opartą na OO odmianą tego samego tematu :-)

Uzupełniając sugestię @amon, możesz również pomyśleć o połączeniu wzorca strategii tutaj, a także wzorca obiektu metody.

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

    def run(self):
        # do some magic
        pass

A potem „normalna” implementacja

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

I implementacja 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)

(Uwaga: na przykładzie z prawdziwego świata mógłbym dać lepszy przykład).