Biztonság

Biztonság

A fejezet a rendszer 1.1.0 verziójának forráskódban dokumentált működését ismerteti.

Forrás szerinti műszaki részletek

**Hol:** szerződés-form → „Digitális aláírás" kártya (`contract/esign.block`), vagy a lista `fa-signature` „Aláírásra küldés".

Beállítás: `contract/esign.settings` (jog: `settings`).

17.1 Menet

1. **Dokumentum választása:** a szerződéshez kötött PDF-ek közül (a jegyzőkönyv nem); a dokumentum fajtája a doc-center

szerepéből, az aláírási mód a forrás-sablonból (ennek híján: felmondás és teljesítésigazolás egyoldalú, minden más kétoldalú).

2. **Aláírók:** csak a felek személyei közül, a személyhez feloldott e-mail címmel (a POST-ban küldött címet nem fogadja el). A

terv ellenőrzi: kétoldalúnál minden kötelező fél kapjon aláírót; egyoldalúnál csak a nyilatkozó fél; ismeretlen nyilatkozónál

pontosan egy fél.

3. **Módszer aláírónként:** `click` (kattintásos elfogadás), `email_otp` (+ 6 jegyű egyszer használatos kód e-mailben),

`sms_otp` (**nem elérhető** — az SMS-modulnak nincs éles küldési útja), `dap` (DÁP eAláírás — **adapter kész, integráció

nincs**, `available = false`). **Munkaszerződésnél és a beállításban megjelölt típusoknál csak `dap` választható** — ezért

ezek ma nem küldhetők ki.

4. **Befagyasztás:** a PDF bájtjainak SHA-256 ujjlenyomata (`doc_sha256`) a kiküldéskor rögzül.

5. **Meghívó levél** a központi levelező úton (`esign_invite`), a client nevében, az aláíró nyelvén; egyedi link

(`…contract/esign&t=<64 hex>`), lejárat 1–90 nap (alap 14).

6. **Aláíró oldal [portál]:** a link megnyitásakor lejárat-ellenőrzés; ha a PDF hash-e eltér → megtagadás (`doc_changed`); a PDF

beágyazva; az elfogadó **záradék** (megnevezi az aláírót, a szerződésszámot, a dokumentum nevét és SHA-256-ját); kötelező

jelölő „Elfogadom és aláírom"; e-mailes kódnál „Kód kérése" → kód (10 percig érvényes, kódonként 5 próba, aláírásonként

legfeljebb 5 kód, kettő között legalább 60 mp). Elutasítás indoklással. Fejlécek: `noindex`, `no-store`, `no-referrer`; POST-ok

munkamenet-tokennel (CSRF).

7. **Aláírás után:** állapot `signed`, IP, böngésző, az elfogadott záradék SHA-256-ja; **aláírási jegyzőkönyv PDF** a doc

centerbe (`signature_evidence`, a szerződéshez kötve): aláíró, e-mail, módszer, dokumentum + hash, kiküldés / megtekintés /

aláírás ideje, IP, böngésző, a záradék és hash-e, az eseménynapló. Ha a tárhely-szabály hiányzik, az aláírás érvényes marad,

a hiány naplózódik, a jegyzőkönyv utólag előállítható (`contract/esign.evidence`).

8. **Összesítés:** a szerződés `esign_status` (`''`, `pending`, `partial`, `signed`, `declined`) és `esign_date`; ha a FŐ

szerződés-dokumentum (szerep `contract`) minden aláírója aláírt, a szerződés `date_signed`-je az utolsó aláírás napját kapja —

csak ha üres.

Állapotok: `pending`, `sent`, `viewed`, `signed`, `declined`, `expired`, `cancelled`. Újraküldés: **új token** (a régi link

érvénytelen). Visszavonás: `cancel`. Lejárat: lusta (a link megnyitásakor és az admin blokk betöltésekor).

17.2 Biztonság

A link tokenje (256 bit) és a kód **csak SHA-256 hash-ként** tárolódik (a kód az aláírás azonosítójával sózva); az eseménynapló

`data` mezőjébe, listába, naplóba nyers érték nem kerül. Eseménykódok: `created`, `sent`, `resent`, `viewed`, `reopened`,

`otp_sent`, `otp_failed`, `signed`, `declined`, `expired`, `cancelled`, `doc_mismatch`, `mail_failed`, `evidence`,

`evidence_failed`.

17.3 Beállítás (`{ext}_tenant_esign`, telepítés-saját JSON)

Minősített aláírást igénylő típusok (fő- vagy altípus kódok), alapértelmezett lejárat (nap), DÁP: engedélyezve, kliens-azonosító,

tanúsítvány-útvonal, környezet (`test` / `prod`), kliens-titok (a felület csak azt mutatja, hogy meg van-e adva).

17.4 Jogi keret (a kódban rögzített állítások)

A kód és a felületi súgó a Ptk. 6:7. § (3) bekezdésére hivatkozik (változatlan tartalom, a nyilatkozó személye, az időpont

azonosíthatósága), a (3a) szerinti különös területeket kizárja az egyszerű módszerből, munkaszerződésnél a minősített (DÁP)

aláírást írja elő, a DÁP-ra a 2023. évi CIII. törvényt (Dáptv.) hivatkozza. A `{esign_clause}` záradék szerint a fél elfogadja

az elektronikus formát. *(Jogi ellenőrzés a dokumentáció írásakor szükséges.)*

18.1 Architektúra

• Külön **áruház (store / aldomain)**, saját adatszoba-témával; a mappák és dokumentumok áruházhoz rendelhetők

(`oc4023_doc_share_to_store`, `oc4023_doc_to_store`), a portál csak a saját áruháza tartalmát mutatja.

• Portál-controller **[portál]** `document/document` (+ a téma kliens-oldali felülete); a jogkulcsok a `document/dataroom`

route-on élnek.

• Szolgáltatások: adatszoba-jog (3 réteg egy döntési pontban), adatszoba-hozzáférés (jogképzés, levelek), szerződés-az-adatszobában

(állapot, felmondási kérelem), vízjel, vízjeles kiadás (csomag), dokumentumtár.

18.2 Belépés, fiók, jelszó

• Belépés a keretrendszer felhasználó-törzsével (`oc4023_user`: felhasználónév + jelszó, aktív user). „Maradjak bejelentkezve":

30 napos tartós token (hash a `oc4023_doc_portal_token`-ben; süti `secure`, `httponly`, `SameSite=Lax`). Kilépéskor a token

törlődik. Próbálkozás-korlát nincs.

• **Aktiváló / meghívó link:** egyszer használatos, 7 napig érvényes (`oc4023_user_invite`, SHA-256 hash); saját jelszó

(legalább 8 karakter, megerősítéssel), utána automatikus belépés. Az adatszoba-áruházban a téma saját jelszó-oldalára fordítja.

• **Elfelejtett jelszó:** felhasználónév vagy e-mail → 2 órás, egyszer használatos link.

• Minden kérésnél újraellenőrzi, hogy a user aktív-e.

18.3 Felhasználási feltételek elfogadása (consent)

• A téma beállítása (Megjelenés → Témák → adatszoba-téma: „Jogi és kapcsolati oldalak", „Feltételek elfogadása kötelező") a

konfigurációba teszi: a feltétel forrása (`information:ID` vagy `cms:ID`), a szöveg **összes nyelvének hash-e** (változat), az

elfogadó oldal címe.

• Bekapcsolva belépés után a szoba helyett az elfogadó oldal jön; kiírja, **ki nyilatkozik** (a belépett user neve,

felhasználóneve, e-mail címe — csak a saját adata). **Elfogadás nélkül egyetlen szoba-végpont sem ad adatot.**

• Rögzítés: `oc4023_doc_room_consent` (user, áruház, forrás, hash, nyelv, IP, böngésző, időpont). A szöveg módosulása új

változat → újra el kell fogadni. Az admin a User formon „Újra el kell fogadnia" gombbal visszavonhatja (jog: `user/user` +

`consentreset`): a sor nem törlődik, `revoked_at` / `revoked_by` kerül rá.

• Az első vízjeles letöltés / megosztás előtt (munkamenetenként egyszer) figyelmeztetés: csak vízjeles példány tölthető le, a

letöltés naplózott, a továbbadásért a user felel.

18.4 Három rétegű jog

1. **Fiók és mappa:** aktív user, élő mappa (`status = 1`, a mappa tól–ig ablaka), a user mappa-hozzárendelésének ablaka

(`oc4023_doc_share_user.date_start` / `date_expire`), áruház-egyezés.

2. **Funkció:** a `document/dataroom` route kulcsai a userre kiosztva (`oc4023_user_feature`, a saját tól–ig ablakkal; User →

Permission, előfizetés vagy szerződés). **A funkciót a USER kapja, nem a mappa**; a `doc_share_user.functions` oszlop megmaradt,

de nem olvasott.

3. **Tartalom:** a dokumentum a mappa tagja (vagy almappájáé), aktív, és a user cég-hatókörébe esik.

`view` nélkül semmi (a többi funkció sem érvényes). A „letölthető" jelzők az adatszobában nem zárnak — a letöltés a user funkciója,

mindig vízjellel. Kivétel: online Drive-szerkesztés (táblázat / szöveg) továbbra is a jelzőkhöz kötött.

**Adatszoba-funkciók:**

Kulcs · Jelentés

`view` · dokumentumok megtekintése (vízjeles nézet)

`download` · vízjeles letöltés

`share` · megosztás a készülékről (vízjeles fájlok a készülék megosztó menüjébe)

`upload` · fájl feltöltése mappába

`folder` · almappa létrehozása

`rename` · mappa / fájl átnevezése

`delete` · fájl eltávolítása a mappából

`broker` · közvetítői hozzáférés (szerződésből kapott)

`terminate` · saját közvetítői szerződés felmondásának kezdeményezése (szerződés-szintű, nem mappa-szintű)

Hozzáférés-ellenőrzés időszakosan is: Bővítmények → a bővítmény → Dokumentumok: „Adatszoba hozzáférés-ellenőrzés" (ki / 1 / 5 /

10 / 15 / 30 perc, alap 5); a nyitott mappa lejártakor üzenet és visszalépés a kezdőlapra. A szerveroldali kapu ettől függetlenül

minden kérésnél dönt.

18.5 Mappa-hozzáférés forrásai (`oc4023_doc_share_user.source`)

Forrás · Ki írja · `source_ref`

`manual` · Mappák (Folders) képernyő vagy User form → „Megosztott mappák" (`user/user.shareadd`, jog: `shares`) · 0

`contract` · közvetítői szerződés szinkronja (5.4) · `contract_property_id`

`registration` · érdeklődő hozzáférése (6.3) · regisztrációs sor azonosító

20.1 A három réteg

1. **Core route-jog** (a keretrendszer `access` / `modify` joga a route-ra). Az új modul route-ját a telepítő a super admin

csoportnak a lemezről felderítve adja meg.

2. **Funkciójog** (`canAction(route, kulcs)`, a modell hívása ELŐTT): a funkció-törzs (`oc4023_feature`) és az egyetlen

hozzárendelés (`oc4023_user_feature`, forrás: `manual`, `subscription`, `order`, `role`). A létrehozás és a módosítás két külön

jog (`canSave(route, id)`: 0 → `add`, > 0 → `edit`). Megjelenítés: csak a kiosztott funkció látszik; `visible` mód = előfizetési

ajánló, `usable` = használható. Super admin mindig.

3. **Tartalmi scope:** a cég-hatókör (`getAllowedScopeValues('company', 'company_id')`, null = korlátlan). A szerződés a

`company_client_id`-ra szűr (`contractInScope`, `ownerInScope`); a számla-befogadás a Megbízóra is; a regisztráció

hozzáférése a sor szerződésének clientjére; a sablonok, okok, jogcímek, tevékenységek közös törzsek (nincs scope); az adatszoba

a mappa-hozzárendelésre + áruházra + dokumentum-cégre; a „Szerződéseim" a közvetítő-személyre.

20.2 Funkciókulcsok route-onként

Route · Kulcsok (besorolás)

`contract/contract` · `list`, `add`, `edit`, `delete`, `debug`, `fxrecalc` (régiek); `grantaccess` adatszoba-jog képzése (BASE); `generate` szerződés generálása (BASE); `amend` (BASE); `terminate` (BASE); `certificate` (BASE); `invoicereceive` számla befogadása (BASE, + core modify); `statusdelete` (BASE, katalógusban; a controller nem ellenőrzi)

`contract/contracttemplate` · `list`, `add`, `edit`, `statusdelete`, `delete`, `debug` (BASE)

`contract/contractaction` · `list`, `add`, `edit`, `statusdelete`, `delete`, `accept`, `reject`, `generate`, `debug`, `offeraccept`, `offerreject`, `offerwithdraw`, `roomaccess` (BASE). A módosítás / felmondás / igazolás a `contract/contract` saját kulcsát kéri; a regisztráció, melléklet, ajánlat a saját `generate`-jét.

`contract/termreason` · `list`, `add`, `edit`, `statusdelete`, `delete`, `debug` (BASE)

`contract/rejectreason` · ugyanez (BASE)

`contract/brokeractivity` · ugyanez (BASE)

`contract/esign` · `list` (állapot), `send` (kiküldés, újraküldés, jegyzőkönyv), `cancel`, `settings` (BASE)

`document/dataroom` · `view`, `download`, `share`, `upload`, `folder`, `rename`, `delete`, `broker`, `terminate` (BASE)

`document/issuelog` · `list`, `debug` (SYSTEM)

`document/folders` · `issue` vízjeles csomag kiadása mappa-usernek (SYSTEM), `download` (SYSTEM), + a modul saját kulcsai

`report/roomactivity` · `list`, `debug` (SYSTEM)

`user/user` · `shares` megosztott mappák a user formon (BASE), `consentreset` feltételek újra-elfogadtatása (BASE)

`masterdata/property` · `brokerend` kivétel a közvetítésből (BASE), `map`, `export` (SYSTEM)

`realestate/advert` · `list`, `add`, `edit`, `statusdelete`, `delete`, `debug` (BASE)

`masterdata/roomtype` · `list`, `add`, `edit`, `statusdelete`, `delete`, `debug` (BASE)

A kulcsok a migrációkban `INSERT IGNORE`-ral kerülnek a funkció-törzsbe és a jog-katalógusba (ismételve hatástalan).