Informacje, którymi nie warto się dzielić

Tworząc oprogramowanie prędzej czy później dotrzemy do momentu, że gdzieś w repozytorium pojawią się nam dane, którymi nie chcielibyśmy się dzielić z całym światem: connection string do bazy danych, nasz klucz prywatny do zewnętrznego api. W idealnym świecie takie informacje nie powinny leżeć nigdzie na repo z kodzikiem. Połączenie z bazą danych powinno być załatwione przez serwer CI (konfigurację możemy trzymać na INNYM - niepublicznym - repozytorium), na pewno znajdzie się też sposób na wstrzyknięcie innych ustawień. Jednak co zrobić w przypadku, gdy nasze repozytorium leży na githubie, stawianie CI mija się z celem, bo projekt jest na tyle mały, że nakład pracy włożony w postawienie kolejnej instancji TeamCity zwróci się po długim czasie, a kodzik musi leżeć w publicznym miejscu?

Wtedy warto ukryć wrażliwe dane przed światem - najlepiej na maszynie developerskiej i nie chwalić się nimi na lewo i prawo. Dotychczas w Domowej Bibliotece connection string i klucz prywatny do Books api leżały sobie w repozytorium, co było bardzo nieodpowiedzialne z mojej strony. Klucz dezaktywowałem, teraz czas zabezpieczyć się przed podobnymi wpadkami w przyszłości.

connectionStrings.config

W świecie .NETa możemy śmiało wyodrębniać poszczególne składowe app i web configów do osobnych plików. Jedyne, co musimy zrobić, to wskazać, gdzie znajduje się właściwa konfiguracja, kodzikiem mówiąc:

zamieniamy na

a we wskazanym pliku umieszczamy nasze connection stringi. Proste! Tak samo można postąpić z pozostałymi częściami web/app configa (np. wydzielając appSettings). Skoro już mowa o connectionStringach. Może się zdarzyć, że będziemy chcieli posiadać informację o sposobie łączenia do bazy danych w wielu miejscach. Problem? Skądże znowu! W każdym projekcie wymagającym połączenia do bazy wstawiamy connectionStringa, a jak się zmieni… Problem, bo trzeba zmieniać w wielu miejscach. Rozwiązanie? Umieść plik connectionStrings.config w katalogu Configuration, a w miejscach, gdzie plik musi się znajdować wewnątrz projektu (np. w przypdaku web site’ów) dodaj go do tego projektu JAKO LINK - (PPM -> Add Existing Item):

apiKeys.config

Sprawa się nieco komplikuje w momencie, gdy chcemy zrobić coś niestandardowego - np. swój własny typ konfiguracyjny. Klucze do api mógłbym trzymać w sekcji appSettings, ale wtedy musiałbym ukryć cały ten plik przed potencjalnymi kontrybutorami, a tego nie chcę robić. Dlatego też klucze do api będą posiadać swoją własną sekcję w konfiguracji, którą to sekcję będzie można wyodrębnić do osobnego pliku. Chcąc stworzyć nową sekcję, musimy stworzyć klasę dziedziczącą po ConfigurationSection, a w niej umieszczamy logikę odpowiedzialną za pobieranie danych z naszej sekcji.

Następnie rejestrujemy sekcję w pliku konfiguracyjnym i posiadając wszystkie wymagane glejty możemy śmiało wpisywać nasze tajne informacje do kolejnego xml’a - apiKeys.config i obowiązkowo dopisać go do .gitignore.

Btw, zastanawialiście się kiedyś, jak stworzyć plik .gitignore w eksploratorze windows? “Nie, bo zawsze kopiowałem z innego projektu… lol” - eksplorator nie pozwoli nam utworzyć pliku o nazwie “.gitignore”, bo brakuje mu rozszerzenia, z chęcią natomiast utworzy plik o nazwie “.gitignore.” - logiczne ;)!

By nie zostawić potencjalnych towarzyszy od kodu w niekomfortowej sytuacji, w której musieliby zgadywać, co powinno się znaleźć w nieobecnych plikach konfiguracyjnych, możemy dodać przykładowe pliki z konfiguracją (apiKeys.sample.config) i wrzucić je na repo.

Moje klucze są bezpieczne na mojej maszynie, a w repo leżą przykładowe pliki. I co najważniejsze - pobierając źródła na inną maszynę VS nie krzyczy o brakujące pliki.