Sane defaults

Tytuł można przetłumaczyć jako "rozsądna konfiguracja domyślna", ale to sformułowanie nie brzmi niestety tak dobrze jak angielski oryginał. O co chodzi? O to, że spora część programistów nie zdaje sobie sprawy jak ważne jest, by zaraz po instalacji oprogramowanie działało poprawnie i bezpiecznie. Spora część użytkowników nie będzie w ogóle zaglądać w rozbudowane opcje konfiguracyjne. A jeśli to nawet zrobi, to dopiero po dłuższym korzystaniu z programu. Dlatego ważne jest, aby świeżo zainstalowany software nie tworzył luk w bezpieczeństwie systemu. Przykłady zdecydowanie złych pomysłów domyślnej konfiguracji (głównie z projektów, w których uczestniczyłem, ale nie tylko):

• użytkownik bazy danych: root, brak hasła


• zapisywanie danych w / lub d:/ lub dowolnej innej absolutnej lokacji (za wyjątkiem /tmp albo %TMP%, zależnie od systemu)


• kasowanie wszystkich danych z takiej lokacji (czyszczenie dysku twardego uszczęśliwia mało którego użytkownika)


• zapis do /tmp albo %TMP% przez aplikację wieloplatformową


• zakładanie, że aplikacja będzie uruchamiana z uprawnieniami administratora / roota


• używanie / lub \ w zapisie ścieżek do podkatalogów

Rozsądne alternatywy:

• użytkownik kojarzący się z nazwą programu, hasło najlepiej generowane losowo w trakcie instalacji


• zapis w podkatalogu %APPDATA% lub ~ (nie dotyczy demonów / usług, zazwyczaj nie posiadających katalogu domowego)


• kasowanie tylko plików utworzonych przez aplikację


• korzystanie z File.createTempFile lub Path.GetTempFileName


• zakładanie, że program zazwyczaj nie ma praw zapisu do katalogu, w którym jest zainstalowany


• korzystanie z File.separator lub Path.DirectorySeparatorChar

Zdaję sobie sprawę, że nie ma szans, by użytkownicy windowsów przestali wykorzystywać konto administratora do normalnej pracy (próba częściowego wymuszenia tego przez Vistę jest chyba głównym źródłem problemów z uruchamianymi na niej programami). Ale programista powinien pamiętać, że usługi / demony uruchamiane są zazwyczaj z kont stworzonych dla nich osobnych użytkowników o okrojonych uprawnieniach. A jedynym elementem aplikacji, który próbuje cokolwiek zapisywać do jej katalogu instalacyjnego powinien być updater.

Jeszcze jedna ważna uwaga: pliki konfiguracyjne nie powinny być wersjonowane. Zamiast tego, do kontroli wersji najlepiej dodać plik z rozszerzeniem w rodzaju .example, zawierający przykładową konfigurację wraz z komentarzem, a właściwy plik konfiguracyjny oznaczyć jako ignorowany. W ten sposób programiści nie ryzykują przypadkowego wysłania do repozytorium swoich indywidualnych plików z ustawieniami. Oczywiście, przy takim podejściu aplikacja musi sobie radzić z brakiem pliku konfiguracyjnego - informując, że należy go stworzyć na podstawie przykładu lub robiąc to automagicznie. Fallback do wbudowanej konfiguracji jest często spotykanym złym pomysłem - użytkownik nie ma wtedy możliwości modyfikacji opcji, musi albo stworzyć konfigurację od zera albo zaakceptować ją w całości.