Titkok kezelése

[Endyl]

Bár szerintem előnyös, ha a projekt java részét nyilvános helyen kezeljük, de elkerülhetetlenül vannak olyan érzékeny információk, amik nem tartoznak egy publikus repóba (éles szerver db hozzáférés, stb). Ezeknek a kezelésére kellene valamit kitalálni, amihez a megfelelő emberek és a deploy megoldás (#9) is hozzáfér.

Van valakinek tapasztalata ilyesmivel, vagy van ötlete, hogyan lehetne megoldani?

[Pepita73]

Jelenlegi cégemnél van egy .env.php a projekt gyökérben (természetesen nem publikus könyvtár a webről), ez nincs verziókövetve. Helyette van (mellette) egy .env.php.dist, ami kvázi ugyanúgy néz ki, csak vannak benne kommentek (mi micsoda), és nincsenek benne valós adatok. Ez alapján nálunk a rendszerüzemeltetés csinálja meg a tesztre és élesre is a .env.php-t -- és még én sem tudom, hogy az hogy kerül ki a megfelelő helyére és hogy mi van benne. :) Ha a mi esetünkben ez csak a settings.php, akkor abból kell egy élesre jó példány ott, ahonnan a deploy fut. Ha ez valamelyikünk saját gépe, az is jó. @inf3rno a deploy-ba be tudja építeni, hogy ez le legyen cserélve, a repóban pedig lehet a dev verzió.

[Pepita73]

Van is src/.env.example, azt hiszem ezt felhasználva megcsinálom a devet, ez szerintem mehet a repóba, a deploy pedig ezt a fájlt kell majd külön kezelje.

UPDATE: #2 kapcsán fog kiderülni, mi lett vele.

[ghost]

Én személy szerint arra szavazok, hogy env változókkal oldjuk meg mindezt. A dockefile-ba be lehet tenni őket valahogy így: https://stackoverflow.com/questions/30494050/how-do-i-pass-environment-variables-to-docker-containers A production env-nél meg külön beállítjuk majd őket. Ha máshogy csináljuk, akkor lesz egy if(dev/production)-else a kódban, amire nem lehet majd tesztet írni, vagy csak nagy erőfeszítésekkel, azért elkerülném az ilyen fájl betöltést. Esetleg egy köztes megoldás, hogy env változóban legyen az útvonal a config fájlhoz, amit betöltünk. Egy harmadik kicsit rondább megoldás, hogy env változóban legyen az, hogy "dev=1", így ha nem férünk hozzá a shared hosting-on esetleg az env változókhoz, akkor ez alapján megmondható, hogy milyen útvonalról töltsük be a config fájlt, ami nekünk kell, de itt már megjelenik az említett if-else.

Az elsővel így gyorsan átfutva a Drupal default config fájlját két környezeti változó kellene. Az egyik a db access a másik meg a hash salt. A db access-nél használhatnánk a Doctrine URL formáját, az elég tömör, pl: 'mysql://user:secret@localhost/mydb', a kódolás utf-8, a collation meg gondolom valami utf-8 hungarian vagy ilyesmi minden esetben. Ezekben ugye megegyezhetünk, és nem kell kivinni config-ba őket?

[Pepita73]

Miért tegyük Dockerfile-ba, ha van kész megoldás rá? https://github.com/Pepita73/webproghu_dev/blob/b_2_db_host/src/config/.env.dev Épp ezen vagyok, hogy dev-en így menjen. prod-on meg nekem tökmindegy, hogy honnan set-eljük be, lehet ugyanilyen fájlból is szerintem, csak azt nyilván nem tartjuk a repóban. :) (composer install után ez bemásolódik src könyvtárba.)

[ghost]

@Pepita73 Jól értem, hogy ebből a dev fájlból a Drupal automatikusan beteszi majd setenv-el env változóba? Ha igen, akkor ez így király. A prod-nál akár htaccess-el is beállíthatjuk. http://httpd.apache.org/docs/current/mod/mod_env.html Vagy gondolom van valami control panel is, amin be lehet állítani, és akkor nem lesz fájlban.

[Pepita73]

@inf3rno nem követtem le, hogy a drush vagy a drupal nyalja fel, de megeszi. És igen, erre írtam - csak már nem tudom, hol -, hogy ezeket a környezeti változókat deploy során úgy seteled, ahogy akarod. Tőlem könyvből is felolvashatod neki. :-D

htaccess-el nem biztos, hogy fog menni, mert mintha azt is magának hozná létre az első telepítéskor. Ezt nem tudom biztosan.

[Pepita73]

Itt írtam korábban

[Pepita73]

A hash salt ugyanígy megoldható, mint a db, .env.dev és settingsben ez a sor kell hozzá:

$settings['hash_salt'] = getenv('MARHA_TITKOS_HASH_NEVE');

[ghost]

Ami még eszembe jutott ezzel kapcsolatban, hogyha env változóban van valami, akkor azt listázza a phpinfo. Nem lehet valahogy hardenelni a szervert, hogy ne lehessen phpinfo-t használni? Bár lehet, hogy túlaggódom, de összefutottam már a neten phpinfo kimenettel egy párszor.

Egyébként ha ez nem szempont, akkor azt hiszem ezt lezárhatjuk, és majd #9 -nál benne lesz a scriptben.

[Pepita73]

ne lehessen phpinfo-t használni?

De, lehet. Viszont egy shared hostingon nem biztos, hogy tudunk php.ini-t írni (Dotrollnál lehet), és ha valaki tud php kódot futtatni nálunk, ugyanannyi erővel átírja ezt is és / vagy kinézi htacces-ből, vagy ahonnan seteljük. Szerintem túlaggódod. Arra kell figyelni (CR), hogy a mi kódunkban ne legyen phpinfo. Ha kívülről kódot tudnak nálunk elhelyezni, akkor azt már megette a fene, pillanatok alatt viszik a db-t is.

Ha elegendő ennyi válasz, akkor zárd le plz.

[ghost]

Ohh, azt hiszem ezt Endyl-nek kellett volna lezárni. Na mindegy.