Pierwszym problemem z plikiem .env jest to... że jest plikiem. Pliki .env często zawierają wrażliwe wartości np. hasła czy sekrety. Istnieje kilka sposobów na omyłkowe upublicznienie tego pliku, takie jak dołączenie go do obrazu dockerowego czy przypadkowy commit do repozytorium. Ponadto, osoba uprawniona do odczytu pliku ma dostęp do wszystkich zmiennych w nim zawartych!
Drugim problemem z plikami .env jest... wbudowane wsparcie dla nich od Node.js 20.6.0. Dotychczas, jednym ze sposobów na pracę z plikami .env była paczka dotenv. Mimo dodania wsparcia w Node prawdopodobnie w wielu projektach ta paczka pozostanie... a jest to błąd! Dalsze wsparcie dla tej paczki, w kontekście ostatnich zmian w Node.js mija się z celem, przez co szansa na naprawianie błędów (w tym błędów bezpieczeństwa) maleje.
#programowanie #javascript #nodejs #bezpieczenstwo #cybersecurity #cybersecurity #itsecurity
Sprawdź linki, by dowiedzieć się więcej:
- https://dev.to/gregorygaines/stop-using-env-files-now-kp0
- https://nodejs.org/en/blog/release/v20.6.0
@elszczepano Czy ja dobrze zrozumiałem że jednym z argumentów przeciwko plikom dotenv jest ich natywne wsparcie przez nodejs? Świat JSa nigdy nie przestanie mnie zaskakiwać xD
Inne ekosystemy: Hej nasz framework dodał coś, do czego wcześniej używaliśmy zewnętrznej biblioteki, więc możemy z niej bezpiecznie zrezygnować.
JS: Hej nasz framework dodał coś, do czego wcześniej używaliśmy zewnętrznej biblioteki, WIĘC MUSIMY NATYCHMIAST CAŁE TO ROZWIĄZANIE WYWALIĆ Z PROJEKTU I WSADZIĆ COŚ NOWEGO I MODNEGO, NAJLEPIEJ POWSTAŁEGO W ZESZŁYM TYGODNIU
( ͡° ͜ʖ ͡°)
Natomiast co do pierwszego argumentu to też średnio się zgadzam :v nie dość że zazwyczaj konfig tam jest związany mocno z lokalnym środowiskiem (no, może ewentualnie jakieś api keye do stagingu sie pojawią), to jeszcze przecież nikt tego ręcznie nie "odznacza" ani z commita ani z dockera tylko zajmują się tym odpowiednie configi których wystarczy nie ruszać. Ktoś chyba celowo by musiał regułę z gitignore wywalić?
I to nie tak że się całkiem z tezą nie zgadzam, ot podnoszę dialog xD
@Barcol jak myslisz, goscie od node.js nie ogarniaja czy moze jakis randomowy ziomek co prowadzi bloga jest w bledzie? Gosc prowadzi bloga i promuje sie tutaj. I niby spoko, ale jak sam pisze kodowanie profesjonalne zaczal w polowie 2018. Ja nie mialbym tyle odwagi zeby po tak krotkim czasie kreowac sie na eksperta.
.env jest spoko, to jest standard w js, koncepcja jest zrozumiala dla kazdego. Wystarczy tego nie wkomitowac na git'a i jest ok.
@666 Pięknie przedstawione pytanie: 3 tysiącę technicznych kontrybutorów, czy jeden random. Tylko że na community nodejs nie składa się jeden sam autor bloga, tylko rzesza ludzi o wiele większa niż gromada jego twórców, i w której to grupie ogrom jest osób, które jak sam zauważyłeś, są pewnie w błędzie. A to właśnie oni ustalają trend, jako grupa. Oni podejmują wybory, które w perspektywie czasu doprowadzają do upadku lub rozrostu danych rozwiązań. Humorystyczna wstawka jaką umieściłem z capslockiem ma za zadanie podkreślić, że akurat w świecie JSa (pewnie przez jego popularność) takie dziwne uciekanie od przestarzałych (czyli starszych niż rok) rozwiązań, na rzecz tych z zeszłęgo tygodnia/miesiąca, jest standardem. IMO doskonale oddaje to satyryczny artykuł (prehistoryczny, ma 7 lat i dwa tygodnie) dostępny tutaj: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Żeby nie było że gadam bzdury bez poparcia: Jest taki nowy framework JSowy o nazwie Bun. W zasadzie to runtime, menadżer paczek, i wiele innych w jednym. Bun w pierwszej stabilnej wersji ma dopiero miesiąc. Już od paru osób słyszałem, że koniecznie muszą przepisać na niego swój projekt xD A dodatkowo już zdążył trafić np. do Railsów w wersji 7.1 XD
Co do konkluzji to sam używam chętnie dotenva i nie mam zamiaru go porzucać, natomiast nie mogę odmówić autorowi posta, że faktycznie dobrze jest go nie commitować xD A niewspierane paczki z lukami bezpieczeństwa - porzucać.
Zaloguj się aby komentować
