Adatokhoz való hozzáférés korlátozása

Fontos

This tutorial is an extension of the Server framework 101 tutorial. Make sure you have completed it and use the estate module you have built as a base for the exercises in this tutorial.

Eddig főként a hasznos funkciók megvalósításával foglalkoztunk. Azonban a legtöbb üzleti helyzetben a biztonság gyorsan aggodalomra ad okot: jelenleg,

• Bármely alkalmazott (amelyet a group_user képvisel) létrehozhat, olvashat, frissíthet vagy törölhet ingatlanokat, ingatlantípusokat vagy ingatlan címkéket.

• If estate_account is installed then only agents allowed to interact with invoicing can confirm sales as that’s necessary to create an invoice.

Azonban:

• Nem akarjuk, hogy harmadik felek közvetlenül hozzáférhessenek az ingatlanokhoz.

• Nem minden alkalmazottunk lehet ingatlanügynök (pl. adminisztratív személyzet, ingatlanmenedzserek, …), nem akarjuk, hogy a nem ügynökök lássák az elérhető ingatlanokat.

• Az ingatlanügynököknek nincs szükségük arra, hogy eldöntsék, milyen ingatlantípusok vagy címkék állnak rendelkezésre.

• Az ingatlanügynököknek lehetnek exkluzív ingatlanaik, nem szeretnénk, ha egy ügynök kezelhetné egy másik ügynök exkluzív ingatlanjait.

• Minden ingatlanügynöknek képesnek kell lennie megerősíteni egy általuk kezelt ingatlan eladását, de nem szeretnénk, ha bármilyen számlát érvényesíthetnének vagy fizetettként jelölhetnének a rendszerben.

Megjegyzés

Lehet, hogy valójában rendben van néhány vagy a legtöbb ezek közül egy kisvállalkozás esetében.

Mivel a felhasználóknak könnyebb letiltani a szükségtelen biztonsági szabályokat, mint a semmiből létrehozni őket, jobb az óvatosság oldalán tévedni és korlátozni a hozzáférést: a felhasználók szükség vagy kényelem esetén enyhíthetik ezt a hozzáférést.

Csoportok

Lásd még

A témához kapcsolódó dokumentáció megtalálható a biztonsági referencia.

Kódolási irányelvek dokumentálja a törzsadatok formátumát és helyét.

Cél

A szakasz végén,

• Az alkalmazottakat ingatlanügynökökké vagy ingatlanmenedzserekké tehetjük.

• Az admin felhasználó egy ingatlanmenedzser.

• Van egy új ingatlanügynök alkalmazottunk, akinek nincs hozzáférése a számlázáshoz vagy az adminisztrációhoz.

Nem lenne praktikus minden változtatáskor egyedi biztonsági szabályokat csatolni az alkalmazottakhoz, ezért a csoportok kapcsolják össze a biztonsági szabályokat és a felhasználókat. Ezek megfelelnek azoknak a szerepköröknek, amelyeket az alkalmazottakhoz lehet rendelni.

A legtöbb Odoo alkalmazás 1 esetében egy jó alap az, ha van felhasználó és menedzser (vagy adminisztrátor) szerepkör: a menedzser megváltoztathatja az alkalmazás konfigurációját és felügyelheti annak teljes használatát, míg a felhasználó használhatja az alkalmazást 2.

Ez az alap elegendőnek tűnik számunkra:

• Az ingatlanmenedzserek konfigurálhatják a rendszert (kezelhetik az elérhető típusokat és címkéket), valamint felügyelhetik az összes ingatlant a folyamatban.

• Az ingatlanügynökök kezelhetik az általuk gondozott ingatlanokat, vagy azokat az ingatlanokat, amelyek nincsenek kifejezetten egy ügynök gondozásában.

Az Odoo adatvezérelt jellegének megfelelően egy csoport nem más, mint a res.groups modell egy rekordja. Ezek általában egy modul törzsadatai részei, amelyeket a modul egyik adatfájljában határoznak meg.

Egy egyszerű példa itt található.

Exercise

1. Hozza létre a security.xml fájlt a megfelelő mappában, és adja hozzá a __manifest__.py fájlhoz.

2. Ha még nincs, adjon hozzá egy 'category' mezőt a __manifest__.py fájlhoz, értéke legyen Real Estate/Brokerage.

3. Add a record creating a group with the id estate_group_user, the name „Agent” and the category base.module_category_real_estate_brokerage.

4. Below that, add a record creating a group with the id estate_group_manager, the name „Manager” and the category base.module_category_real_estate_brokerage. The estate_group_manager group needs to imply estate_group_user.

Megjegyzés

Honnan származik ez a kategória? Ez egy modulkategória. Itt a base.module_category_real_estate_brokerage kategória azonosítót használtuk, amelyet az Odoo automatikusan generált a modul __manifest__.py fájljában beállított category alapján. Itt található az Odoo által biztosított alapértelmezett modulkategóriák listája is.

Javaslat

Mivel módosítottuk az adatfájlokat, ne felejtse el újraindítani az Odoo-t, és frissíteni a modult a -u estate használatával.

If you go to Settings ‣ Manage Users and open the admin user („Mitchell Admin”), you should see a new section:

Állítsa be az adminisztrátori felhasználót Ingatlan menedzser szerepkörre.

Exercise

Via the web interface, create a new user with only the „real estate agent” access. The user should not have any Invoicing or Administration access.

Használjon privát lapot vagy ablakot az új felhasználóval való bejelentkezéshez (ne felejtse el beállítani a jelszót), mivel ingatlanügynökként csak az ingatlan alkalmazást, és esetleg a Discuss (chat) alkalmazást kell látnia:

Hozzáférési jogok

Lásd még

A témával kapcsolatos dokumentáció megtalálható itt: Hozzáférési jogok.

Cél

A szakasz végén,

• Azok az alkalmazottak, akik nem legalább ingatlanügynökök, nem fogják látni az ingatlan alkalmazást.

• Az ingatlanügynökök nem tudják frissíteni az ingatlantípusokat vagy címkéket.

Access rights were first introduced in Chapter 4: Security - A Brief Introduction.

A hozzáférési jogok lehetővé teszik a felhasználók számára a modellekhez való hozzáférést csoportokon keresztül: társítson egy hozzáférési jogot egy csoporthoz, majd minden felhasználó, aki tagja ennek a csoportnak, megkapja a hozzáférést.

For instance we don’t want real-estate agents to be able to modify what property types are available, so we would not link that access to the „user” group.

A hozzáférési jogok csak hozzáférést adhatnak, elvenni nem tudnak: amikor a hozzáférést ellenőrizzük, a rendszer megvizsgálja, hogy bármely a felhasználóhoz társított hozzáférési jog (bármely csoporton keresztül) biztosítja-e azt a hozzáférést.

csoport	létrehoz	olvasás	frissítés	törlés
Egy	X	X
B		X
C			X

Az A és C csoportokkal rendelkező felhasználó mindent megtehet, kivéve az objektum törlését, míg a B és C csoportokkal rendelkező felhasználó olvashatja és frissítheti azt, de nem hozhat létre vagy törölheti azt.

Megjegyzés

• Egy hozzáférési jog csoportja elhagyható, ez azt jelenti, hogy az ACL minden felhasználóra vonatkozik, ami hasznos, de kockázatos visszaesés, mivel a telepített alkalmazásoktól függően akár nem felhasználóknak is hozzáférést biztosíthat a modellhez.

• Ha egy felhasználóra nem vonatkozik hozzáférési jog, akkor nem kap hozzáférést (alapértelmezett elutasítás).

• Ha egy menüpont egy olyan modellre mutat, amelyhez a felhasználónak nincs hozzáférése, és nincsenek olyan almenük, amelyeket a felhasználó láthat, akkor a menü nem jelenik meg.

Exercise

Frissítse a hozzáférési jogok fájlt a következőre:

• Adjon teljes hozzáférést minden objektumhoz az Ingatlan Menedzser csoportjának.

• Adjon az ügynököknek (ingatlan felhasználóknak) csak olvasási hozzáférést a típusokhoz és címkékhez.

• Senki ne kapjon jogot az ingatlanok törlésére.

• Ellenőrizze, hogy az ügynök felhasználója nem tudja módosítani a típusokat vagy címkéket, illetve törölni az ingatlanokat, de egyébként létrehozhat vagy frissíthet ingatlanokat.

Figyelem

Ne felejtse el különböző xid-eket adni az ir.model.access rekordjainak, különben felülírják egymást.

Since the „demo” user was not made a real-estate agent or manager, they should not even be able to see the real-estate application. Use a private tab or window to check for this (the „demo” user has the password „demo”).

Rekordszabályok

Lásd még

A témához kapcsolódó dokumentáció megtalálható a Rekordszabályok címen.

Cél

Ennek a szakasznak a végén az ügynökök nem fogják látni a kollégáik számára kizárólagos tulajdonságokat; de a vezetők továbbra is mindent láthatnak.

A hozzáférési jogok hozzáférést biztosíthatnak egy teljes modellhez, de gyakran ennél specifikusabbnak kell lennünk: míg egy ügynök általánosságban kezelheti a tulajdonságokat, lehet, hogy nem akarjuk, hogy frissítsék vagy akár lássák a kollégáik által kezelt tulajdonságokat.

A rekord szabályok biztosítják ezt a precizitást: hozzáférést adhatnak vagy megtagadhatják az egyes rekordokhoz való hozzáférést:

<record id="rule_id" model="ir.rule">
    <field name="name">A description of the rule's role</field>
    <field name="model_id" ref="model_to_manage"/>
    <field name="perm_read" eval="False"/>
    <field name="groups" eval="[Command.link(ref('base.group_user'))]"/>
    <field name="domain_force">[
        '|', ('user_id', '=', user.id),
             ('user_id', '=', False)
    ]</field>
</record>

A Keresési tartományok az, ahogyan a hozzáférés kezelve van: ha a rekord megfelel, akkor a hozzáférés engedélyezett, ellenkező esetben a hozzáférés megtagadott.

Javaslat

Mivel a szabályok általában meglehetősen összetettek és nem tömegesen készülnek, általában XML-ben készülnek, nem pedig a hozzáférési jogokhoz használt CSV-ben.

A fenti szabály:

• Only applies to the „create”, „update” (write) and „delete” (unlink) operations: here we want every employee to be able to see other users» records but only the author / assignee can update a record.

• Nem globális, így biztosíthatunk egy további szabályt például a vezetők számára.

• Engedélyezi a műveletet, ha az aktuális felhasználó (user.id) be van állítva (pl. létrehozva, vagy hozzárendelve) a rekordhoz, vagy ha a rekordhoz egyáltalán nincs társított felhasználó.

Megjegyzés

Ha nincs szabály meghatározva vagy alkalmazva egy modellre és műveletre, akkor a művelet engedélyezett (alapértelmezett-engedélyezés), ez furcsa hatásokat okozhat, ha a hozzáférési jogok nincsenek megfelelően beállítva (túl engedékenyek).

Exercise

Határozzon meg egy szabályt, amely korlátozza az ügynököket, hogy csak azokat a tulajdonságokat láthassák vagy módosíthassák, amelyeknek nincs értékesítője, vagy amelyeknél ők az értékesítők.

Érdemes lehet létrehozni egy második ingatlanügynök felhasználót, vagy létrehozni néhány ingatlant, amelyeknél az értékesítő menedzser vagy valamilyen más felhasználó.

Ellenőrizze, hogy az ingatlanmenedzsere(i) továbbra is láthatják-e az összes ingatlant. Ha nem, miért nem? Ne feledje:

Az estate_group_manager csoportnak magában kell foglalnia az estate_group_user csoportot.

Biztonsági felülírás

Biztonság megkerülése

Cél

Ennek a szakasznak a végére az ügynököknek képesnek kell lenniük az ingatlanértékesítések megerősítésére anélkül, hogy számlázási hozzáférésre lenne szükségük.

If you try to mark a property as „sold” as the real estate agent, you should get an access error:

Ez azért történik, mert az estate_account megpróbál számlát létrehozni a folyamat során, de a számla létrehozása megköveteli a teljes számlakezelési jogot.

Azt szeretnénk, hogy az ügynökök képesek legyenek megerősíteni egy eladást anélkül, hogy teljes számlázási hozzáféréssel rendelkeznének, ami azt jelenti, hogy meg kell kerülnünk az Odoo normál biztonsági ellenőrzéseit annak érdekében, hogy számlát hozzunk létre annak ellenére, hogy a jelenlegi felhasználónak nincs joga ezt megtenni.

Két fő módja van annak, hogy megkerüljük a meglévő biztonsági ellenőrzéseket az Odoo-ban, akár szándékosan, akár mellékhatásként:

• The sudo() method will create a new recordset in „sudo mode”, this ignores all access rights and record rules (although hard-coded group and user checks may still apply).

• A nyers SQL lekérdezések végrehajtása megkerüli a hozzáférési jogokat és a rekordszabályokat, mivel az ORM megkerülésének mellékhatása.

Exercise

Frissítse az estate_account modult, hogy megkerülje a hozzáférési jogokat és szabályokat a számla létrehozásakor.

Veszély

Ezeket a funkciókat általában kerülni kell, és csak rendkívüli óvatossággal szabad használni, miután ellenőriztük, hogy a jelenlegi felhasználó és művelet képes-e megkerülni a normál hozzáférési jogok érvényesítését.

Az ilyen módokban végzett műveleteknek a lehető legkevesebbet kell támaszkodniuk a felhasználói bemenetre, és a lehető legnagyobb mértékben érvényesíteniük kell azt.

Biztonság programozott ellenőrzése

Cél

Ennek a szakasznak a végére a számla létrehozásának ellenállónak kell lennie a biztonsági problémákkal szemben, függetlenül az estate változásaitól.

Az Odoo-ban a hozzáférési jogokat és rekordszabályokat csak akkor ellenőrzik, amikor az ORM-en keresztül történik az adathozzáférés, például rekord létrehozása, olvasása, keresése, írása vagy törlése ORM metódusokkal. Más metódusok nem feltétlenül ellenőrzik semmilyen hozzáférési jogot.

Az előző szakaszban megkerültük a rekordszabályokat a számla létrehozásakor az action_sold metódusban. Ez a megkerülés bármely felhasználó által elérhető anélkül, hogy bármilyen hozzáférési jogot ellenőriznének:

• Adjon hozzá egy nyomtatást az action_sold metódushoz az estate_account modulban a számla létrehozása előtt (mivel a számla létrehozása hozzáfér a tulajdonhoz, ezért kivált egy ACL ellenőrzést), például:

  print(" reached ".center(100, '='))
  

Az Odoo naplójában látnia kell a reached üzenetet, amelyet egy hozzáférési hiba követ.

Veszély

Csak azért, mert már a Python kódban van, nem jelenti azt, hogy bármilyen hozzáférési jogot vagy szabályt ellenőriztek vagy ellenőrizni fognak.

Currently the accesses are implicitly checked by accessing data on self as well as calling super() (which does the same and updates self), triggering access errors and cancelling the transaction „uncreating” our invoice.

Azonban ha ez a jövőben megváltozik, vagy mellékhatásokat adunk a metódushoz (pl. az eladás jelentése egy kormányzati ügynökségnek), vagy hibák kerülnek be az estate-be, … lehetséges lenne, hogy nem ügynökök olyan műveleteket indítsanak el, amelyekhez nem kellene hozzáférésük legyen.

Ezért, amikor nem-CRUD műveleteket hajtunk végre, vagy jogosan megkerüljük az ORM-et vagy a biztonságot, vagy amikor más mellékhatásokat váltunk ki, rendkívül fontos, hogy kifejezett biztonsági ellenőrzéseket végezzünk.

Kifejezett biztonsági ellenőrzések elvégezhetők:

• Annak ellenőrzése, hogy ki a jelenlegi felhasználó (self.env.user), és összevetése specifikus modellekkel vagy rekordokkal.

• Annak ellenőrzése, hogy a jelenlegi felhasználó rendelkezik-e olyan csoportokkal, amelyek kódoltan engedélyezik vagy megtagadják a műveletet (self.env.user.has_group).

• Calling check_access(operations) on a recordset, this verifies that the current user is allowed to perform the operation on every record of the set. As a special case, when the recordset is empty, it verifies that the current user has some access rights to perform the operation on the model in general.

Exercise

Before creating the invoice, use check_access to ensure that the current user can update the property the invoice is for.

Futtassa újra a megkerülő szkriptet, ellenőrizze, hogy a hiba a nyomtatás előtt jelentkezik-e.

Többvállalati biztonság

Lásd még

Több vállalat irányelvei a többvállalati lehetőségek általános áttekintéséhez, és multi-company security rules különösen a biztonsági szabályokhoz.

A szabályok általános dokumentációja ismét megtalálható itt: Rekordszabályok.

Cél

Ennek a szakasznak a végén az ügynököknek csak a saját ügynökségük (vagy ügynökségeik) tulajdonságaihoz kell hozzáférniük.

Egy vagy más okból szükség lehet arra, hogy az ingatlanüzletünket több vállalatként kezeljük, például lehetnek nagyrészt autonóm ügynökségeink, franchise rendszerünk, vagy több márkánk (esetleg más ingatlanvállalkozások felvásárlása miatt), amelyek jogilag vagy pénzügyileg elkülönülnek egymástól.

Az Odoo használható több vállalat kezelésére ugyanazon a rendszeren belül, azonban a tényleges kezelés az egyes modulokra van bízva: maga az Odoo biztosítja az eszközöket a vállalatfüggő mezők és a többvállalati szabályok kezelésére, amivel foglalkozni fogunk.

We want different agencies to be „siloed” from one another, with properties belonging to a given agency and users (whether agents or managers) only able to see properties linked to their agency.

Mint korábban, mivel ez nem triviális rekordokon alapul, a felhasználónak könnyebb lazítani a szabályokon, mint szigorítani azokat, ezért érdemes egy viszonylag erősebb biztonsági modellt alapértelmezettként beállítani.

A többvállalati szabályok egyszerűen rekordszabályok, amelyek a company_ids vagy company_id mezőkön alapulnak:

• A company_ids az összes vállalat, amelyhez a jelenlegi felhasználónak hozzáférése van

• A company_id a jelenleg aktív vállalat (amelyikben a felhasználó jelenleg dolgozik / amelyikért dolgozik).

A többvállalatos szabályok általában az előbbit használják, azaz ellenőrzik, hogy a rekord társítva van-e a felhasználó által elérhető egyik vállalathoz:

<record model="ir.rule" id="hr_appraisal_plan_comp_rule">
    <field name="name">Appraisal Plan multi-company</field>
    <field name="model_id" ref="model_hr_appraisal_plan"/>
    <field name="domain_force">[
        '|', ('company_id', '=', False),
             ('company_id', 'in', company_ids)
    ]</field>
</record>

Veszély

A többvállalatos szabályok általában globálisak, ellenkező esetben nagy a kockázata annak, hogy további szabályok lehetővé tennék a többvállalatos szabályok megkerülését.

Exercise

• Adjon hozzá egy company_id mezőt az estate.property-hez, kötelezőnek kell lennie (nem akarunk ügynökség nélküli ingatlanokat), és alapértelmezés szerint a jelenlegi felhasználó aktuális vállalatára kell állnia.

• Hozzon létre egy új vállalatot, egy új ingatlanügynökkel abban a vállalatban.

• A menedzsernek mindkét vállalat tagjának kell lennie.

• A régi ügynöknek csak a régi vállalat tagjának kell lennie.

• Hozzon létre néhány ingatlant mindkét vállalatnál (vagy használja a vállalatválasztót menedzserként, vagy használja az ügynököket). Állítsa vissza az alapértelmezett értékesítőt, hogy elkerülje az szabály aktiválását.

• Minden ügynök láthatja az összes vállalatot, ami nem kívánatos, adjon hozzá egy rekord szabályt, amely korlátozza ezt a viselkedést.

Figyelem

ne felejtse el --update-elni a modulját, amikor megváltoztatja annak modelljét vagy adatait

Láthatóság != biztonság

Cél

Ennek a szakasznak a végére az ingatlanügynököknek nem szabad látniuk az ingatlan alkalmazás Beállítások menüjét, de továbbra is képesnek kell lenniük beállítani az ingatlan típusát vagy címkéit.

Bizonyos Odoo modellek közvetlenül társíthatók csoportokkal (vagy vállalatokkal, vagy felhasználókkal). Fontos meghatározni, hogy ez a társítás biztonsági vagy láthatósági funkció-e, mielőtt használnánk:

• A láthatósági funkciók azt jelentik, hogy a felhasználó továbbra is hozzáférhet a modellhez vagy rekordhoz más módon, akár az interfész más részén keresztül, akár távoli műveletek végrehajtásával RPC használatával, a dolgok csak nem biztos, hogy láthatók a webes felületen bizonyos kontextusokban.

• A biztonsági funkciók azt jelentik, hogy a felhasználó nem férhet hozzá rekordokhoz, mezőkhöz vagy műveletekhez.

Íme néhány példa:

• A modell mezőkön (Pythonban) lévő csoportok biztonsági funkciók, a csoporton kívüli felhasználók nem tudják lekérni a mezőt, vagy akár tudni, hogy létezik.

  Példa: a szerver műveletekben csak a rendszergazdák láthatják vagy frissíthetik a Python kódot.

• A nézeti elemek (XML-ben) lévő csoportok láthatósági funkciók, a csoporton kívüli felhasználók nem fogják látni az elemet vagy annak tartalmát az űrlapon, de egyébként képesek lesznek interakcióba lépni az objektummal (beleértve azt a mezőt is).

  Példa: csak a vezetőknek van azonnali szűrőjük, hogy lássák a csapataik szabadságait.

• A menükön és műveleteken lévő csoportok láthatósági funkciók, a menü vagy művelet nem jelenik meg az interfészen, de ez nem akadályozza meg a közvetlen interakciót az alapul szolgáló objektummal.

  Példa: csak a rendszergazdák láthatják az e-learning beállítások menüjét.

Exercise

Az ingatlanügynökök nem adhatnak hozzá ingatlantípusokat vagy címkéket, de láthatják azok lehetőségeit az Ingatlan űrlap nézetből, amikor létrehozzák azt.

A Beállítások menü csak zajt ad az interfészükhöz, tegye csak a vezetők számára láthatóvá.

Annak ellenére, hogy már nem férnek hozzá az Ingatlantípusok és Ingatlancímkék menükhöz, az ügynökök továbbra is hozzáférhetnek az alapul szolgáló objektumokhoz, mivel továbbra is választhatnak címkéket vagy típust az ingatlanjaikhoz.

1

Egy Odoo Alkalmazás egy üzleti területet vagy mezőt lefedő kapcsolódó modulok csoportja, amely általában egy alapmodulból és annak bővítményeiből áll, hogy opcionális vagy specifikus funkciókat adjon hozzá, vagy más üzleti területekhez kapcsolódjon.

2

For applications which would be used by most or every employees, the „application user” role might be done away with and its abilities granted to all employees directly e.g. generally all employees can submit expenses or take time off.