Pepita73 / webproghu_dev

Webprog.hu apache-php7.2, Drupal 8.5.5
1 stars 1 forks source link

User 1 #18

Closed Endyl closed 6 years ago

Endyl commented 6 years ago

Hogyan lesz kezelve a user 1 account?

Az világos, hogy midnenkinek lesz személyre szóló loginja, ami majd megfelelő jogosultságokat kap. Akinek viszont hozzáférése van a user 1 accounthoz, az teljhatalommal bír az oldalon.

Szóval ennek az accountnak a létezése, menedzselése hogyan fér össze a szavazásos főszerkesztő és egyéb szerepváltással (vagy hogyan valósítható meg általa)? Vagy itt jön képbe a bizalmi alap, hogy mindenkinek, vagy egy adott embernek van hozzáférése, és bízunk abban, hogy nem él vissza vele?

Esetleg a wl-es összefoglaló alapján:

Főszerkesztő: a főszerkesztő tejhatalommal rendelkezik, szerkesztői plusz azonnali döntések meghozatala, például ha valaki a szerkesztői gárdából valami nagyon nagy disznóságot csinál, megvonhat tőle minden jogosultságot. Emellett ismeri a technikai hozzáféréshez szükséges jelszavakat.

Az aktuális főszerkesztő mindig megváltoztatja csak általa ismertre a vonatkozó jelszavakat? De ez hogyan működik mondjuk a tárhely hozzáféréseknél?

Pepita73 commented 6 years ago

Nagyon jogos kérdések, emiatt is jeleztem Gg n és WL en,  hogy már most kellene github ra is a teljes szerkesztő csapat.  De sok más kérdés miatt is kellene. 

Kéne tudni, hogy a Drupal mit hogy logol / mi kerül history ba. Ha kb minden, és nem törölhető, akkor user 1 lehet mindig az aktuális főszerkesztő.  Ha lehet törölni, akkor bajban leszünk ezzel szerintem. 

Üdvözlettel: Horváth Péter

(Mobilról)

Endyl commented 6 years ago

User 1 simán tud logot törölni :) Meg mondjuk az is, akinek adatbázis hozzáférése van.

ghost commented 6 years ago

Szerintem elég ha ti ketten tudjátok a jelszót ahhoz az acchoz. Ha egyikőtöket elüti a busz, akkor meg választunk új tartalékot. Én úgy sejtem, hogy itt két szerepkörről beszélünk. Az egyik a fejlesző, akinek szüksége lehet a user 1 acc-ra (bármit is csináljon az), a másik a szerkesztő, akinek meg gondolom nem, mert ő csak cikk gyártással vagy moderálással foglalkozik, amihez nem kell akkora hatalom, jelszavak, stb.. Esetleg küldhet be ide issue-ban feature request-et és becsatlakozhat segíteni, ha akar, de nem kötelező. Release szempontjából is szerintem így lenne a jó, hogy csak 2 ember tudja a jelszavakat a szerverhez, és ne tudja bárki átírni az éles szerveren futó kódot vagy turkálni az adatbázisban. Csak hogy tovább bonyolítsam, főszerkesztő nem feltétlen kell, lehet úgy is csinálni, hogy a szerkesztők megszavazzák, hogy kitesznek valakit, aztán írnak a fejlesztőknek, hogy a user 1 acc-al vonják meg a jogot az illetőtől. Szerintem. :D

Pepita73 commented 6 years ago

@Endyl , a törlés majdnem tréfa volt. :) Igazából annyi, hogy ha db-hez nincs hozzáférése és felületről nem lehet törölni, akkor mind1 lenne, hogy ki az.

@inf3rno szerintem megtalálta az optimumot.

Szerintem elég ha ti ketten tudjátok a jelszót ahhoz az acchoz.

OK, de legyen is kimondva, hogy ki(k) az elsődleges tartalék, és a "build master" (= @inf3rno) legyen közte.

Én úgy sejtem, hogy itt két szerepkörről beszélünk.

Igen, de ha @Endyl -re és rám gondoltál, egyelőre mindketten fejlesztünk.

Release szempontjából is szerintem így lenne a jó, hogy csak 2 ember tudja a jelszavakat a szerverhez

Egyetértek. Mivel Te csinálod a deploy-t, szeretném, hogy az első számú Te legyél, a másik szintén csak tartalék.

Csak hogy tovább bonyolítsam...

Ezzel is egyetértek, csak az a gáz, hogy nincs itt mindenki. Ne legyen a későbbiekben az, hogy "de jól megegyeztetek, mi meg nem is láttuk". Mondjuk GG-n és WL-en is jeleztem, hogy szükség lenne mindenki szemére / véleményére.

ghost commented 6 years ago

@Pepita73 Nekem úgy is jó, ha mi hárman tudjuk. A build master sem fontos, hogy legyen, szerintem mindhármunk meg tudja ítélni, hogy mikor jó a kód release-re, illetve én ha lehet szeretnék a PHP/Drupal írás alól kimaradni, a bash scripteket, e2e tesztelést, ilyesmit el tudom vállalni.

Mindenkinek megvolt a lehetősége, hogy beszálljon a fejlesztésbe, vagy legalább a hosting kifizetésébe. Egyelőre nem éltek vele. Gyanítom, hogy az lesz a vége, hogy hárman maradunk, aztán amikor elkészül az oldal, akkor majd megjelenik a "tömeg" magának követelve minden jogkört. Valahogy nem tetszik ez a forgatókönyv...

Pepita73 commented 6 years ago

@inf3rno , rendben, legyen így, ha @Endyl is rá bólint. Ebben a kérdésben elengedhetetlen a teljes egyetértés.

Az a bizonyos forgatókönyv nekem se tetszene, de tekintve, hogy nincs túl sok szabadidőm, nem szeretném, ha mások lustasága / "Pató Pál úr" miatt megállna a fejlesztés. A "későn jövőkre" majd kitalálunk valamit, amikor jelentkeznek.

Endyl commented 6 years ago

Ez gondolom attól is függ, hogy végül Dávidéknál lesz-e hostolva, vagy csak átadja a domaint, vagy másikat választunk, vagy mi lesz. Én nem ragaszkodom hozzá, hogy ismerjem a "titkokat", de ha tudom, az se baj. Bennetek meg egyelőre megbízom :D


Kicsit elvadult ötlet, de User 1-nek lehetne generálni egy random jelszót (amit senki se ismer) miután létrehoztunk egy csoportot, ami normálisan létre tudja hozni, be tudja állítani az új felhasználókat, és van legalább egy tagja. Utána lehet mondjuk csoportos emailt küldeni, ha valaki mégis belép vele :D Mondjuk jobban belegondolva ezt is biztos simán ki lehetne játszani akár db hozzáférés nélkül is, és sok hűhó lenne semmiért.

Pepita73 commented 6 years ago

@Endyl elvben teljesen egyetértenék az elvadult ötlettel, de egyrészt nem ismerem annyira a Drupal "lelkét", hogy ki merjem dobni User 1 -et a kukába, másrészt nincs azért kedvem kódot túrni + db-t kézzel matatni, hogy valahogy visszaszerezzük, ha mégis kéne.

Szerintem ha ebben megegyeztünk, akkor ez zárható is.

ghost commented 6 years ago

@Endyl A random jelszó az szerintem alapból fog kelleni neki, hogy ne lehessen dictionary attack-el vagy ilyesmivel feltörni, és szerintem min. 12 karakter kelleni fog. A hash-elést lenne még érdemes megnézni, hogy mivel csinálja alapból a Drupal, és ha kell tákolni rajta. Gondolom konfigurálható. Ez mehetne akár külön issue-ba is.

Endyl commented 6 years ago

Akkor itt arra a konklúzióra jutottunk, hogy a (jelenlegi?) fejlesztőknek kell ismerni a super hozzáféréseket, a többieknek meg bízniuk kell bennük?

Mindenesetre lezárom; legfeljebb előjön valami konkrétabb kérdés egy új issueban.

ghost commented 6 years ago

@Endyl Ja, nagyjából ez a konklúzió. A dokumentációba esetleg be lehet emelni, hogy most ez a helyzet a jogkörökkel, feltéve ha mindent dokumentálni akarunk.