Fejlesztések

Felhasználói hierarchia a rendszerben: 


level  3 - super admin (server admin, super cow)
level  2 - main admin (registered account)
level  1 - admin (organizational admin, coder)
level  0 - normal (normal user, web app user, chicken)
level -1 - shared (unprivileged user of shared data)

Felhasználók létrehozhatnak kisebb szintű felhasználót, törölhetnek kisebb szintű kódot és módosíthatnak kisebb szintű adatot. Más kódját nem lehet módosítani megtévesztés lehetősége miatt, csak törölni.

​

Changelog:

  • change feature: allow users to delete codes of other users with lower privileges
  • change feature: allow non-admin users to manage codes but see theirs only
  • change feature: refactor inline styles to make restyling easier
  • add feature: allow multiple file uploads in data manager
  • add feature: hide mouse pointer automatically in code editor when idle

​

Az egér eltüntetés hiányzott régóta. Az adatkezelő felületén nem volt igényem tömeges feltöltésre, de most megírtam, a web app-okhoz használt apit használtam vissza.

Eddig nem engedtem sima usert kódot létrehozni, de kell a következő miatt: admin userek látják egymás kódját. Ez a logikus, ugyanis amúgy is hozzáférnek mindenhez, az adatokhoz is. Viszont ha központilag akarunk menedzselni több kódert úgy, hogy ne lássák egymás kódját és kis privilégium szintjük legyen, akkor jól jön.

Eddig nem engedtem törölni idegen kódot adminoknak mert csak adminok tudtak kódot létrehozni. Viszont mivel már a normál userek is tudnak, ezért az eggyel kisebb privilégium szintű user kódját engedem törölni. Nyilván előfordulhat ilyen igény, meg az admin az admin.

( NagyZ v | 2018. 03. 04., v – 08:43 )

de nagyon ronda, hogy ennyire ossze-vissza van a szint (-1-tol indul felfele, WTF?) illetve miert kell elnevezni oket ("chicken", "coder")? eleg rohejes lesz ettol kifele nezve, nem? (hiaba lehet akar prima munka is)

A szint onnét jön, hogy a normál usert mindenképpen 0-ásnak akartam, de viszont ehhez képest kellett egy sokkal jobban csökkentett user a megosztáshoz. Míg a normál user hozzáfér a tábláihoz és kódjaihoz (törlés joga nincs csak módosítás, beállításokhoz sem fér), egy megosztott táblával keletkezik egy átmeneti share user aki viszont csak a megosztott táblához fér.

A szintek értékei sehol nem látszódnak, ez nekem belső infó.

Az adminok pedig azok, akiket a fő admin kezelhet. Super admin meg csak egy van, aki a rendszert futtató szerverhez fér hozzá. Ő minden fiókot kezelhet, a regisztrációnál létrejövő fő admint is.

A kódban lévő logikával felfelé építkeztem. Több funkcióhoz több jog kell:

if u_isadmin > 0 then admin

Viszont ha u_isadmin < 0 akkor sandbox szintű jog.

Az elnevezések zárójelben lévő részei megjegyzések, csak itt szerepelnek.

Szerintem a bovithetoseg miatt erdemes tizessevel megadni a jogokat. Persze nem ismerem a szitut, de nekem nem jott be az ilyen tipusu jogok kezelese. Kb 20 eve csinaltuk igy meg egy cms motort. Azota:
- elemi reszekre bontom a funkciokat
- negy fele jogot adok meg bool (list, modify, new, del)

Ez mar 15 eve megy es bevalt. Mindent meg tudtam oldani igy, ha ez keves volt akkor masik modulba szerveztem egyes funkciokat.

Azt külön szabályozom finoman egyéb jogosultsági beállításokkal. Ez konkrétan a táblák szabály szekciójában van (user rules). Bármilyen felhasználó bármilyen feltétel alapján láthat vagy módosíthat adatot. Például értékesítők által kezelt adatokban mindenki csak a saját megyéjét lássa, és hasonlók.

Ha már beszélünk róla, adok egy példát (mindegy hogy vessző vagy newline a parancsok elválasztása):

A táblához csak a szabályban szereplő felhasználók (login nevek) férnek hozzá és alább még oszlop szűréssel is szűkítek (login column filter): 


andi, zoli, regina
péter megye budapest
tamás megye zalaegerszeg

Ez szerver oldalon kényszerít ki jogokat. Arra jó hogy ne lehessen kliens oldalról saját kódot beinjektálva több dologhoz hozzáférni mint ami megengedett. De lehet tovább szabályozni kliens oldalon is az adat szűrésekben igény szerint.

A nagyobb baj inkabb, hogy nincs "integer space" az esetlegesen kesobb megjeleno provilegium szintekhez.

Pl.

100 - Super Admin
90 - Dev Level Admin
80 - Newcomer Admin

Es ha valakinek kell egy uj szint ami tudja a 80-ast meg 3 masik dolgot a 90-esbol definial egy 85-ost es

if (admin.level >= ADMIN::NEWCOMER_ADMIN) // >= 80

Ahogy írtam, mindenképpen megpróbálom beletenni valamelyik csoportba. Muszáj egyszerűen tartani a struktúrát hogy hosszú távon is kezelhető maradjon mind a fejlesztő és mind a felhasználó részéről. Ugyanis ha tetszik, ha nem, csak akkor használható megfelelő hatékonysággal egy megoldás, ha átlátható (nem túl magas a komplexitási szintje). És csak ekkor jelenhet meg a hajlandóság is a használatra.

Ez kritikus. Főleg azért, mert a fejlesztések természetes tulajdonsága (és egyébként minden dolognak) a bonyolódás (káosz felé mozdulás). Azt nehéz megtenni minden fejlesztésnél, hogy úgy adjál hozzá plusz értéket, hogy minél kevésbé nőjön az addigi komplexitási szint.

Szerk.: Megjegyzem, főleg ezt tartom értéknek egyébként a fejlesztésemben, hogy sok figyelmet szánok annak, hogy kisimítsam a fejlesztés során a működésben helyet foglaló logikai összefüggések hibáit, felülről építve a lényeget.

Vagyis jelenleg majdnem elég annyit tudni a rendszeremről egy webfejlesztőnek, hogy belépés után beleszór kódot és klikk futtatás, illetve hogy az adatokat is tudja kezelni a felületen. Kész. Minden másnak fontos ebből logikailag következnie.

Nyilván nehéz végtelen kombinációjú halmazban véges időn belül véges minőségből a legjobbat produkálni (gyorsan elrobbannak a kombinációs lehetőségek), de elég jól lehet rá törekedni. Itt nyilván megint bejön az ízlés kérdése, de ha nagyban szorítkozunk a funkcionalitás bonyolultságának lent tartására, akkor már jó kimenetet kaphatunk.

Érdekes elképzelni, hogy ha behelyezel egy logikát egy térbe, akkor az ott lesz. Mindenképpen helyet fog elfoglalni és kombinációs teret teremteni. Ezért fontos, hogy mindenből (logika, objektum, vizuál) minél kevesebbet tegyünk HA lehet.

Nem tudom nincs-e félreértés. Nálam mindegyik szinten bármennyi user lehet. Tehát van egy fő admin, akinek az ún. általános (normál) adminok felett is van joga.

Ezen kívül vannak normál adminok, meg normál userek. Ennyi. Ezek között nem látom értelmét a további árnyalásnak.

Saját tulaj vagyok egyéni vállalkozóként és van pár fizetős céges felhasználóm. Tervezek megkeresni cégeket belső fejlesztéseikhez támogatást és akár képzést nyújtani, illetve privát oktatási terület lehet még jó (igény szerint kihelyezve hozzájuk a kódot saját infrastruktúrájukra természetesen).

Folyamatosan próbálok kapcsolódni szakmabeliekkel is, szívesen együttműködök egymást támogatva vagy kiegészítve. Úgy gondolom hogy baromi nagy a piac és sok helyre elkél és kell a jól végzett munka (mindegy milyen szinten) és mivel mindenkinek gyorsan megy az idő, a legnagyobb értéknek az egymásnak való idő spórolást tartom.

Ha valakit érdekel akár itt egyéb felhasználás vagy éppen hazai vagy nemzetközi vonalon együttműködés (relatíve sokat tárgyalok folyamatosan a nemzetközi piacon), abszolút nyitott vagyok rá.

( saxus | 2018. 03. 04., v – 23:19 )

Hányan és hányszor akarták már feltalálni ezt a szintezéses baromságot jogosultságkezelésre, pedig hülyeség.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Lattam rosszabbat, ami bizonyos szempontbol jobb volt: 6 relacios tabla egyenkent 5-50 sorral SQL-ben, hogy kinek mihez van joga, mihez nincs. Mindez egy rosszul implementalt ORM-mel egyesevel lequery-zve, mikor admin usert instantiate-elnek. Frontenden legalabb konnyen be lehet loni, hogy "olyan jogai legyenek mint X usernek" es az kesobb is valtozik konzisztensen mindkettonel, megis tulzas minden egyes kb statikus switch case helyett SQL minitablakat ily modon toltogetni.

Arra en is kivancsi vagyok tovabbra is.

Amugy Oregonra reagalva: "modify, list, new, del a.k.a. CRUD (create, read, update, delete*)" - minden rendszert ugy csinalok, hogy fejlesztheto legyen ebbe az iranyba konnyen igeny szerint a jogosultsagkezeles. De ennel altalaban egyszerubb marad.

Az isAllowed() meg igy is ugy is egy olyan fuggveny lesz elobb utobb, ami szeret meghizni. Mindenhol. Jobb esetben nem a kivetelektol (nem instanceof Exception, hanem uzleti kivetel)

*delete - "delete" -> UPDATE table SET status = STATUS_HIDDEN + log entry hogy melyik admin/user volt. Mindig. Igazi delete esetleg erosen indokolt esetben fejleszto lehet egy terminalbol

Szerencsére, mire idáig fejlődött a tudomány, már nem programoztam, úgyhogy ilyesmit élesben nem kellett csinálnom. Pár éve jött egy rohamom, hogy php és saját blogmotor, de akkor valami olyanban gondolkodtam, ahol nincs ilyen hierarchia, csak mindenféle jogosultságok konkrét funkciókhoz, funkciócsoportokhoz. Aztán az elemi jogokból talán lehetett volna ilyen jellegű csoportokat szervezni.
De az álmodozások korán nem jutottam túl. :)

Igen, nos amit mondani akartam:

-sokszor overkill CRUD-ra bontani a jogosultsagokat

-plane overkill mindezt SQL-ben letarolni, mikor egy 10 soros switch case is eleg, es azt az SQL-t migralgatni dev, test es live szerverek kozott tobb relacios foreign key-es tablaban userid-hoz kapcsolva

-de mivel van eselye, hogy a CRUD lesz a jo megkozelites a business bonyolodasaval, erdemes mar az isAllowed() fuggvenyt/fuggvenyeket is ugy tervezni, hogy kesobb erre konnyen extendelheto lehessen

-valamikor viszont tenyleg eleg evtizedekig a user.type IN (10, 50, 90, 100) jogosultsagkezelesre

-nehez predictalni, hogy ez mikor lesz eleg, lasd pl az 1970 korul kitalalt POSIX 777 vs "mindenki olvashassa a file-t, kiveve aki a "spectator" group-ban van" Unix-on kerdeskort, ezert meg ha egyszerusit is az ember, fontos, hogy ne vesse kobe az egyszeru megoldast

Mert nem jól szabályozható, nem írja le jól azt, hogy kinek mihez kell hozzáférni és olyan téves feltevésekre épül, hogy egy adminnak mindenhez hozzá kell férnie. Példa: egy rendszergazdának kell tudnia backupolnia egy DB-t, de mégis mi szükség van arra, hogy bele tudjon nézni az adatokba, neadjisten, módosítani rajta? Semmi. Az ilyen szintezéses izéknél meg valahogy mindig ez a vége. Másrészt úgy is lesznek előbb-utóbb kivételek, hogy valaki(k)nek valamihez több vagy kevesebb jog kell.

Magam részéről jobb szeretem, ha csoportok vannak, amelyekhez vannak jogosultságok engedélyezve tiltva vagy nem definiálva és az userek vannak csoportokba rendezve, majd az user számára használható jogok a sum(engedélyezett) - sum(tiltott), ami nem definiált, az meg alapból tiltott és igény esetén rendesen lebontva CRUD lépésekhez. Szükség esetén hierarchiát bevezetve, pl. egy tartalomkezelő rendszeren.

Implementációs oldalról meg lehetőleg megtoldva mindezt lehetőleg megtoldva valamilyen capability alapú megoldással nem if (user.permissions.have("foobar")) megoldással.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egyetlen kerdesem maradt:

Eleted soran hany darab projekt jogosultsagkezeleset kellett

-megirnod
VAGY
-atirnod az implementaciojat (pl. meglevonek)

Tehat

SELECT COUNT(DISTINCT CASE WHEN created_by = {saxus_userid} OR modified_by = {saxus_userid} THEN project_id ELSE NULL END)
FROM {$kurvasokTablaJoinja}
WHERE commit_code LIKE '%isAllowed%';

Koszi

Csak mert en 20 korul tartok (abbol 3 nott nagyra)

Ebbol 18-ban (koztuk ketto nagyban) megfelelt az integer space-es szintezes + <30 sor isAllowed(). 19.-ben is eleg volt egy admintype text column-t hozzaadni a db-hez, amit egy isAllowed fuggveny elrendezett. Illetve van meg egy extra blacklist user_setting tablaban, az ott nem szep, igeny eseten atszervezzuk majd. Altalad javasolt komplexitast viszont 20-bol csak 1 projekt igenyelt meg. Csak azzal ertek egyet, hogy ugy kell szervezni a jogosultsagkezelest, hogy ne legyen nehez odaig eljutni, amit felvazolsz igeny eseten. De szerintem nem gaz egyszerubb jogosultsagkezelessel kezdeni.

A példád rossz ugyan, de amit írsz, azzal nagyjából egyetértek. (egy rendszergazdának _lehet_ szüksége arra, hogy bele tudjon olvasni az adatbázisba, pl. ha valami megsérül és próbálja menteni a menthetőt, netán index megsérül, ami gondolom, ma sem elképzelhetetlen - amiről te beszélsz, azt mifelénk operátornak nevezték régen)

Egy reindexhez nem szükséges, hogy hozzáférjen a rendszergazda a cég összes számlájához, ügyfeléhez, rendeléséhez, beszállítójához, stb.

Konkrétan tudok egy hatmilliós sikkasztásról, ami abból eredt, hogy az egyik ilyen kedves informatikusnak volt lehetősége buzerálni az adatokat. De hozhatnám példának azt is, mikor valamelyik Google mérnök turkált bele gmail fiókokba, mert volt rá lehetősége. (Talán Hiena blogolt róla pár éve, most nincs időm/kedvem előkeresni.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Majd az RDBMS olvassa az adatokat, nem a rendszergazda. Az egy maintenance folyamat, semmi köze a táblában tárolt adatokhoz. Még akár DDL műveleteket is végrehajthatsz anélkül, hogy lenne SELECT jogod.

"N+1 dolog lehet, ami miatt kell valaki, aki bele tud túrni az adatokba is."

Mondj akár egyetlen egyet, ami miatt egy rendszerüzemeltetőnek tudnia kell olvasnia egy általa üzemeltetett cég számláit, partnereit, vevőit. Nincs semmi racionális érv és egészen pontosan 0 köze van hozzá.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hm... és honnan lesz joga megkérni az rdbms-t, hogy indexeljen? De még mindig ott tartunk, hogy ez egy kiragadott példa.

----
Amiről te beszélsz, az még mindig az operátor kategória.
Konkrétabban: ha pl. oracle adatbázison nincs SYSDBA jogom, akkor addig vállalom az "üzemeltetést", hogy elindul, ment, leállít. Bármi hiba van, felteszem a kezem és dolgozzon vele... ja, pardon, a megbízónál nincs senki aki ért hozzá, a fejlesztőnek meg még kevesebb köze van az adatokhoz, mint az üzemeltetőnek.

Egyébként adatlopás: ha van jogom backupot készíteni és tesztrendszerre visszatölteni, attól kezdve hogy akadályozod meg, hogy egy a törvényeket leszaró üzemeltető ellopja az adatokat? Ha mezőn belül titkosítasz, akkor hogy indexelsz? Ha azon kívül, akkor ugyanott tartunk, hogy az üzemeltetőnek hozzá kell férnie.
Sajnos az van, hogy vagy megbízol az üzemeltetést végzőben, legyen az külső vagy belső vagy feldughatod magadnak a dbaseIII-nál komolyabb adatbázisodat.

N+1: írtam: helyreállítás, adatmentés egy x ok miatt sérült adatbázisból. (mint +1 példa)

De mi az anyámért kellene egy kurva CREATE INDEX-hez SELECT jog? Melyik az a szerencsétlen RDBMS, amihez ez kell? Áruld már el kérlek? PostgreSQL-ben CREATE jog kell hozzá, nem SELECT. MySQL és Oracle esetén INDEX privilégium kell. SQL Serverre most nem találtam meg 10 mp alatt, hogy mi kell, de kizárt dolognak tartom, hogy SELECT kellene. Szóval hol kell olvasnia a rendszergazdának az adatot egy index létrehozásához? Kézzel írja meg az admin az indexet vagy mi a szösz?

Amúgy igen, kiragadott példa. Sokkal valóságosabb példa volt, amit fenntebb írtam: miért kell tudnia pl. egy adminnak számlát kiállítani? Belső felhasználásra kiírni dolgokat? Látnia mások fizetését? Vagy módosítani rajta? Miért kezdeményezhet raktári mozgást? Miért kezelhet rendeléseket? Ha adatbázisba bejárása van, ismeri-e egyáltalán a rendszert annyira, hogy ott egy módosítást kellően megbízhatóan elvégezzen? Tud egyáltalán releváns módon segíteni egy sérült adatbázison?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Vetted az adást? Fogom a backupot, visszatöltöm a saját gépemre, adok rajta magamnak olyan jogot, amilyet akarok és viszem az adatbázisból a kódolatlan adatokat.

Mondom, hogy ne az operátori kategóriában gondolkodj, hanem DBA-ban. Oracle esetében legutóbb még ALTER ANY INDEX kellett, ha idegen indexeket akartál piszkálni és ANY nélkül, ha olyat, amire közvetlenül kaptál jogot.
De önmagában az index kreálás/reindex jog értelmetlen, ha nem valami automatizmusról van szó. Amikor arról van szó, hogy probléma esetén legyen aki be tud avatkozni (és erre hoztam kiragadott példának az indexelést, amin azóta is rugózol), ahhoz kicsivel tágabb hozzáférés kell.

100 programozo/rgazda/dba-bol szerinted hany tudja, hogy ezeket a jogosultsagokat hogy kell ugy kikapcsolni/elrejteni, hogy hiba eseten ne legyen nehezebb restore-olni az adatbazist? Es a meetingen mindig annak a kevesnek adnak igazat aki tenyleg jol tudja?

Mert ezek a statisztikak nagyobb kockazatot rejtenek, mint maga a lopas ami nalatok megtortent, de legtobb esetben meg sem probalnak.

Ha nem tudja, akkor minek nyúl adatbázishoz? Ha nem ismeri egy RDBMS jogosultság-beállításait, akkor milyen eséllyel várható el tőle az, hogy releváns javításokat tudjon végezni egy megroggyant adatbázison?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Alkalmazottkent en is csak idaig lattam. Meg is ertelek. Minden honapban elutaljak ugyanazt a penzt, es kozben ezt javaslom, hogy minel kevesbe rugjanak seggbe kesobb, mert "nem szoltam a veszelyekrol".

De enyem a business. Es van, akiben meg tudok bizni, de meg benne sem bizok teljesen: van olyan backup amit en setuppoltam fel es o jo esellyel nem is tud rola, ha megis, akkor meg azert nem merne atverni. Miert bizok benne? Mert egyreszt ezt a db fixalast meg jobban tudja mint en, masreszt anelkul is hogy emeltem volna a fizetesen, elegge volt par custom igenye, amiben rugalmasabb voltam mint barki korabban neki (szeret keso este dolgozni, szerencsere en is), harmadreszt ha megis megkarositana en meg feljelentem, fizet a business insurance. Inkabb legyen root joga mindenhez kiveve a sajat masik virt gepen levo backupjaimat letorolni/modositani, mint hogy alljon a szamlazas 3 napig, mert nem volt jogosultsaga hozzanyulni. Raadasul o vetette fel hogy szeretne korlatozni a sajat hzozafereset is. Nem engedtem. Tudtam mirol beszel. A tobbieke korlatozva van. Rabiztam hogyan, de nagyjabol tudom. Ettol meg a kodban maskepp neznek ki a privilegiumszintek, de ami kodbol tortenik a db-ben (create, read, update) az ugyis logolva van alkalmazas szinten mindig. Ha megsem, latom git logbol miert nem.

Pár dolog:

A fenti listámban a legfelsőt kivéve (ami nem kerül ügyfélhez) mind olyan admin, aki csak user interface-hez fér hozzá. Tehát különbséget kell tenni az informatikus admin (aki a szerverhez és szolgáltatásokhoz hozzáfér) és a szoftver jogai szempontjából magasabb hatáskörrel rendelkező között.

Az logikus és érthető, hogy minden tulajdonos törekedik a jogok minimalizálására. De ez nem mindig vihető végbe a vágyaik mértékében. Másrészt pedig sok dolgot nem technológiával kell kezelni, hanem rá lehet bízni a jogi következmények súlyára. Sokkal kevesebb logikai akadályt kell állítani így mindenki elé a mindennapok munkavégzésében. Általában mindig kompromisszumok között kell dönteni ami végül arra vezet hogy biztonság vagy hatékonyság.

Másrészt az adatok értékét is néha sokan túlbecsülik. Természetesen kell védeni és maximális biztonsággal kezelni, de azért abba néha jó belegondolni, hogy milyen értékszerzést tud elkövetni egy KKV-nál alkalmazott a forgalmi vagy egyéb adatokat látva ráadásul úgy, hogy a törvény súlya ott van a másik oldalon.

Aki konkurens céget csinál, az sincs nagyban kisegítve, ugyanúgy végig kell mennie az akadály pályán felépítve az egészet és végül mindig sok munka.

Érdemes árnyalni szerintem a szükséges lépéseket az adott konkrét esetek fényében. Illetve tartom amit feljebb írtam, hogy nem egyszerű úgy növelni a tudását egy terméknek, hogy nem növeled a bonyolultságát nagyban.