1c rls raport privind drepturile de acces. Cinci pași de configurare - acces la directoare la nivel de înregistrare

Platforma 1C:Enterprise 8 are un mecanism încorporat pentru restricționarea accesului la date la nivel de înregistrare. Puteți citi informații generale despre el aici. Pe scurt, RLS vă va permite să restricționați accesul la date pe baza anumitor condiții privind valorile câmpului. De exemplu, puteți restricționa accesul utilizatorilor la documente în funcție de valoarea atributului „Organizație”. Unii utilizatori vor lucra cu documente pentru organizația „Management Company”, iar alții cu organizația „Dairy Plant”. Ca exemplu.

Pregătirea

Vom implementa exemplul în configurația demo a SCP 1.3. Să creăm un utilizator „Storekeeper” și să îi adăugăm rolul cu același nume „Storekeeper”.

Acum să trecem direct la configurarea drepturilor de acces la nivel de înregistrare. Să trecem la interfața „Administrare utilizatori”. În meniul principal, selectați „Acces la nivel de înregistrare -> Opțiuni”. Aici, bifați caseta de lângă „Restricționați accesul la nivel de înregistrare în funcție de tipul de obiect” și selectați „Organizații” din lista de obiecte.

Astfel, am activat utilizarea RLS. Acum trebuie să-l configurați.

Controlul accesului la nivel de înregistrare nu este configurat separat pentru fiecare utilizator sau profil de permisiune. RLS este configurat pentru grupuri de utilizatori. Să adăugăm un nou grup de utilizatori, numim „Magazieri”

Compoziția grupului din partea dreaptă a formularului arată o listă de utilizatori care aparțin acestui grup. Să adăugăm în listă utilizatorul creat anterior. În stânga este un tabel cu restricții de acces. În configurarea RLS, am ales ca accesul să fie limitat doar de organizație, așa că vedem un singur tip de obiect de acces. Faceți clic pe butonul „Setări de acces”. Se va deschide procesarea setării drepturilor de acces pentru grupul curent.

Să adăugăm organizația „IPE „Antreprenor” la lista de obiecte de acces pentru grup. Tipul de moștenire a drepturilor va rămâne neschimbat. Vom seta dreptul la obiectul de acces să citească și să scrie. Faceți clic pe „OK”, setările sunt gata. Tocmai am configurat RLS la nivel de organizație.

Ce vede utilizatorul

Să lansăm programul sub utilizatorul creat anterior și să deschidem directorul „Organizații”. Iată cum va arăta lista pentru utilizatorul nostru și pentru un utilizator cu drepturi depline:

După cum putem vedea, utilizatorul depozitar vede o singură organizație pentru care am acordat acces de citire. Același lucru se aplică documentelor, de exemplu, primirea de bunuri și servicii.

Astfel, utilizatorul nu numai că nu va vedea organizații pentru care accesul nu este setat pentru el, dar nici nu va putea citi/scrie documente și alte obiecte în baza de informații pentru care sunt setate drepturi în rolul „Organizației” atribut.

Ne-am uitat la cel mai simplu exemplu de configurare a RLS. În articolul următor vom vorbi despre implementarea mecanismului RLS în configurația „Manufacturing Enterprise Management” versiunea 1.3.

Obiectul de configurare „rol” oferă un set de drepturi la operațiuni (acțiuni) asupra obiectelor de configurare.

Rolul „Drepturi depline”.

Acesta este doar un rol (nepredefinit) în care sunt verificate toate tipurile de drepturi pentru toate obiectele de configurare.

Ceea ce îl deosebește de alte roluri este prezența dreptului de „Administrare”.

Dacă este creat cel puțin un utilizator, sistemul începe să verifice prezența dreptului „Administrare” - cel puțin un utilizator trebuie să îl aibă.

Restricții de acces la nivel de înregistrare

Row Level Security (RLS) – restricție la nivel de înregistrare.

Mecanismul de restricții de acces la date vă permite să gestionați drepturile de acces nu numai la nivelul obiectelor metadate, ci și la nivelul obiectelor bazei de date. Următoarele obiecte pot fi utilizate pentru a restricționa accesul la date:

• roluri,
• parametrii de sesiune,
• opțiuni funcționale,
• module privilegiate partajate,
• cuvântul cheie PERMIS în limbajul de interogare.

Mecanismul este conceput pentru a restricționa accesul la înregistrările tabelelor obiect metadate pe baza unor condiții arbitrare impuse valorilor câmpurilor de rând ale acestor tabele. De exemplu, pentru a vedea înregistrările numai pentru contrapărțile „dvs.”, organizații etc.

Implementarea tehnică a restricțiilor de acces în 1C

1C generează o solicitare către SGBD. Clusterul de server adaugă la cerere o secțiune WHERE, care conține textul condiției de restricționare a accesului prin RLS, apoi această solicitare este trimisă la DBMS, datele extrase sunt returnate clientului 1C.

Acest mecanism va funcționa pentru orice solicitare din partea clientului:

• în rapoarte,
• în liste dinamice și în forme de listă obișnuite
• în interogări personalizate.

O astfel de implementare a mecanismului afectează foarte mult performanța.

Modalități de a ocoli restricțiile de acces.

În operațiunile mari consumatoare de resurse (procesarea repostării documentelor, de exemplu), o parte a codului poate fi mutată în module privilegiate.

A) Modul privilegiat este un modul comun cu indicatorul „Privilegiat” în proprietăți.

Particularitatea sa este că codul din acesta este executat fără niciun control al drepturilor de acces, inclusiv RLS.

B) De asemenea privilegiat modul poate fi activat pentru modulele obiect document. Acest lucru se face în proprietățile documentului, flag

• Tratament privilegiat la conducere
• Mod privilegiat la anularea unei tranzacții

B) Metoda SetPrivilegedMode()

Comanda de sistem vă permite să faceți parte din codul oricărui modul privilegiat.

Din următoarea linie de cod va funcționa modul de execuție privilegiat.

Acesta va funcționa până la linia de dezactivare a acestui mod sau până la sfârșitul procedurii/funcției

(Adevărat);

// orice cod aici va fi executat fără controlul drepturilor și RLS

SetPrivilegedMode(Minciună ); // sau sfârșitul procedurii / funcției

Numărul de ori când este activat modul privilegiat trebuie să corespundă cu numărul de ori când este dezactivat. Cu toate acestea, dacă într-o procedură sau funcție modul privilegiat a fost activat (o dată sau de mai multe ori), dar nu a fost dezactivat, atunci sistemul se va opri automat de câte ori au fost porniri incomplete în procedura sau funcția rămasă.

Dacă într-o procedură sau funcție apelează o metodă SetPrivilegedMode(False) a făcut mai mult decât apeluri de metodă SetPrivilegedMode(Adevărat), atunci va fi aruncată o excepție

Funcţie Mod privilegiat() returnează True dacă modul privilegiat este încă activat și False dacă este complet dezactivat. Aceasta nu analizează numărul de setări ale modului privilegiat într-o anumită funcție.

Toate procedurile și funcțiile apelate vor fi, de asemenea, executate în modul privilegiat.

De asemenea, este posibil să începeți o sesiune privilegiată. Aceasta este o sesiune în care modul privilegiat este stabilit de la începutul sistemului. Mai mult, în timpul funcționării metoda Mod privilegiat() va returna întotdeauna True, iar capacitatea de a dezactiva modul privilegiat nu este acceptată. Doar un utilizator care are drepturi de administrare (drept de administrare) poate începe o sesiune privilegiată. Sesiunea poate fi pornită utilizând comutatorul de linie de comandă de lansare a aplicației client UsePrivilegedMode sau parametrul șir de conexiune la baza de informații prmod .

Întrebarea apare în mod firesc: de ce atunci se stabilesc restricții de acces, dacă pot fi ocolite atât de ușor?

Modul sigur.

Da, puteți scrie procesări externe cu un mod de execuție privilegiat și puteți descărca/corupt date. Pentru a preveni acest lucru, sistemul are o metodă de context global

SetSafeMode().

Modul sigur, printre altele, ignoră modul privilegiat.

Trebuie să fie instalat înainte de a apela programatic procesoare externe sau de a exporta proceduri și funcții din modulele acestora.

Când se efectuează operațiuni interzise, ​​se aruncă o excepție în timpul execuției.

În plus, la nivel de setări de rol, puteți dezactiva posibilitatea utilizatorilor de a lansa în mod interactiv rapoarte și procesare externe.

Configurarea restricțiilor de acces

RLS poate fi configurat numai pentru drepturi:

• citește (selectează)
• adăugarea (inserarea)
• schimbare (actualizare)
• șterge

Pentru operații de citireși ștergere, un obiect care se află în baza de date trebuie să respecte restricțiile de acces la date.

Pentru operația de adăugare Restricția de acces la date trebuie să corespundă obiectului care este planificat să fie scris în baza de date.

Pentru operațiunea de schimbare restricția de acces la date trebuie să respecte obiectul atât înainte de modificare (pentru ca obiectul să fie citit), cât și după modificare (pentru ca obiectul să fie scris).

Pentru toate celelalte drepturi nu există o astfel de opțiune.

Să adăugăm o nouă restricție pentru dreptul de „citire” al directorului „Nomenclatură”. Se va deschide o listă de câmpuri pentru care puteți configura restricția adăugată.

Aceasta înseamnă că dacă încercați să accesați câmpurile bifate, restricția va fi declanșată, dar dacă încercați să accesați câmpurile nebifate, restricția nu va funcționa.

Dacă selectați steagul " Alte domenii", restricția va fi configurată pentru toate câmpurile de tabel, cu excepția câmpurilor pentru care restricțiile sunt setate în mod explicit.

* Caracteristică: pentru drepturi de adăugare, modificare, ștergere:

• Restricția poate fi configurată numai pentru toate câmpurile.
• Nu poate exista decât o singură restricție.

Pentru dreptul „Citește”, puteți configura mai multe condiții; acestea vor fi combinate cu operatorul logic „ȘI”.

Nu toate câmpurile obiectului de date de constrângere principal pot fi utilizate în restricții asupra următoarelor tipuri de obiecte de bază de date:

• în registrele de acumulare, restricțiile de acces pot conține doar măsurători ale obiectului principal al restricției;
• în registrele contabile, restricțiile pot utiliza numai măsurători de bilanț ale obiectului principal al restricției

Daca in conditii de acces limitat la datele registrului de acumulare circulant se folosesc masuratori care nu sunt incluse in totaluri, atunci la accesarea tabelului virtual de rotatii nu se folosesc totalurile stocate si solicitarea se realizeaza in totalitate conform masa de mișcare.

Mecanism de impunere a restricțiilor de acces.

Orice operațiune asupra datelor stocate într-o bază de date în 1C:Enterprise duce în cele din urmă la un apel către baza de date cu o solicitare de citire sau modificare a datelor. În procesul de executare a interogărilor la baza de date, mecanismele interne ale 1C:Enterprise impun restricții de acces. în care:

• Se generează o listă de drepturi(citiți, adăugați, modificați, ștergeți), o listă de tabele de baze de date și o listă de câmpuri utilizate de această interogare.
• Din toate rolurile utilizatorului actual restricțiile de acces sunt selectate la date pentru toate drepturile, tabelele și câmpurile implicate în cerere. Mai mult, dacă un rol nu conține restricții privind accesul la datele unui tabel sau câmp, aceasta înseamnă că valorile câmpurilor solicitate din orice înregistrare sunt disponibile în acest tabel. Cu alte cuvinte, absența unei restricții de acces la date înseamnă prezența unei restricții UNDE ESTE ADEVĂRAT.
• Preia valorile curente ale tuturor parametrilor de sesiune și opțiunile funcționale participarea la restricțiile selectate.

Pentru a obține valoarea unui parametru de sesiune sau a unei opțiuni de caracteristică, utilizatorul actual nu trebuie să aibă permisiunea pentru a obține acea valoare. Cu toate acestea, dacă valoarea unui parametru de sesiune nu a fost setată, va apărea o eroare și interogarea bazei de date nu va fi executată.

Constrângerile derivate dintr-un rol sunt combinate folosind operația AND.

Constrângerile derivate din diferite roluri sunt combinate folosind operația OR.

Condițiile construite sunt adăugate la interogările SQL cu care 1C: Enterprise accesează SGBD. La accesarea datelor din condiții de restricție de acces, verificarea drepturilor nu este efectuată (nici pentru obiectele metadate și nici pentru obiectele bazei de date). Mai mult, mecanismul de adăugare a condițiilor depinde de metoda selectată de funcționare a restricțiilor „toate” sau „permise”.

* Caracteristică: Dacă un utilizator are acces la mai multe roluri cu restricții configurate la nivel de înregistrare pentru un obiect, atunci în acest caz condițiile restricțiilor sunt adăugate folosind operația logică „SAU”. Cu alte cuvinte, puterile utilizatorului sunt cumulate.

Aceasta duce la următoarea concluzie: nu permiteți să se intersecteze condițiile de restricționare a accesului la un obiect cu roluri diferite, deoarece în acest caz textul solicitării va fi foarte complicat și acest lucru va afecta performanța.

Metoda „Totul”.

Atunci când se impun restricții folosind metoda „toate”, condiții și câmpuri sunt adăugate la interogările SQL, astfel încât 1C:Enterprise să poată obține informații despre dacă, în timpul executării unei interogări de bază de date, au fost utilizate sau nu date care erau interzise pentru un anumit utilizator. Dacă au fost utilizate date interzise, ​​cererea se va bloca din cauza unei încălcări a accesului.

Impunerea restricțiilor de acces folosind metoda „toate” este prezentată schematic în figură:

Metoda „permisă”.

Când se aplică restricții folosind metoda „permisă”, condițiile sunt adăugate la interogările SQL, astfel încât înregistrările care sunt interzise pentru utilizatorul curent să nu afecteze rezultatul interogării. Cu alte cuvinte, atunci când restricțiile sunt impuse în modul „permis”, înregistrările interzise pentru un anumit utilizator sunt considerate lipsă și nu afectează rezultatul operațiunii, care este prezentat schematic în figură:

Restricțiile de acces la date sunt impuse obiectelor bazei de date în momentul în care 1C:Enterprise accesează baza de date.

În versiunea client-server a 1C:Enterprise, restricțiile sunt aplicate pe serverul 1C:Enterprise.

Totuși, această opțiune (PERMISĂ) nu va funcționa dacă într-o interogare ne referim la un tabel pentru care nu sunt configurate restricții de acces, dar care conține referințe la rânduri de tabel cu restricții configurate. În acest caz, rezultatul interogării va afișa „<Объект не найден>......" în locul valorii câmpului de referință.

Dacă dezvoltați un raport sau procesați folosind interogări de configurare standard sau personalizate, verificați întotdeauna indicatorul „Permis”. pentru ca raportul să funcționeze sub orice utilizator cu orice set de drepturi.

În cazul citirii obiectelor de date din baza de date, nu este posibilă setarea indicatorului „Permis”. Prin urmare este necesar configurați selecțiile pentru citirea obiectelor, ținând cont de posibilele restricții privind drepturile de acces pentru utilizator. Nu există mijloace de a obține numai date permise în tehnologia obiectelor.

Este important ca, dacă o interogare nu specifică cuvântul cheie ALLOWED, atunci toate selecțiile specificate în acea interogare nu trebuie să intre în conflict cu niciuna dintre restricțiile de citire a obiectelor bazei de date utilizate în interogare. Mai mult, dacă interogarea folosește tabele virtuale, atunci selecțiile corespunzătoare trebuie aplicate la tabelele virtuale în sine.

Practică 1. Generator de interogări în setările RLS.

Să compunem textul secțiunii „UNDE” în ​​interogarea directorului. Puteți utiliza generatorul de interogări.
Designerul are un aspect dezbrăcat.

fila „Tabele”.

Tabelul principal va fi tabelul obiectului pentru care constrângerea este configurată.

De asemenea, puteți selecta alte tabele și puteți configura diverse conexiuni între ele în fila „Relații”.

Fila „Condiții”

Aici puteți configura condițiile actuale de restricție de acces

Să adăugăm condiții la atributul „Preț” al directorului nomenclatorului pentru dreptul de a „citi” în toate câmpurile tabelului.

„Nomenclatură WHERE Nomenclatură.Preț > 500”

Să vedem cum funcționează această regulă simplă. Tabelul director conține următoarele elemente:

După setarea unei restricții de acces, tabelul va afișa doar elementele care îndeplinesc condiția:

Au dispărut și grupuri. Să schimbăm textul restricției

„Nomenclator WHERE Nomenclator.Preț > 500

SAU Nomenclatură. Acesta este un grup"

Ei bine, acum de asta ai nevoie.

Dacă eliminați afișarea câmpului „cod” din setările listei, vor fi afișate toate elementele directorului, adică. restricția nu a funcționat. Dacă setați câmpul „Cod” să fie afișat, restricția va funcționa.

În acest caz, în ciuda faptului că elementul director este vizibil în câmpul listă, forma acestuia nu poate fi deschisă deoarece este configurată o restricție asupra atributului. Același lucru se întâmplă într-o solicitare arbitrară: atunci când încercați să obțineți o proprietate „restricționată”, va apărea o eroare de acces.

Dacă încercați să obțineți acreditările „restricționate” în mod programatic, va fi generată și o eroare de acces.

Mai mult, nu se va putea accesa niciun câmp al unui obiect printr-un link, deoarece la primirea unui link, sistemul citește întregul obiect, iar dacă acesta conține detalii „restricționate”, obiectul nu va fi citit.

Prin urmare, atunci când lucrați programatic cu obiecte de bază de date, trebuie să aveți în vedere posibilele restricții la nivel de înregistrare și să obțineți toate datele obiectului necesare la cerere și apoi să le plasați într-o structură sau să executați o parte a codului într-un modul privilegiat.

După configurarea restricției de acces, afișarea liniei din lista de drepturi s-a schimbat - a devenit gri și a apărut o pictogramă.

Restricții la configurarea accesului (RLS).

• Nu există o secțiune Rezumat;
• Tabelele de registre virtuale nu pot fi accesate;
• Nu puteți utiliza parametrii în mod explicit;
• Poate fi folosit în interogări imbricate orice>/span> instrumente de limbaj de interogare, cu excepția:
  • operator ÎN IERARHIE;
  • REZULTATE propuneri;
  • rezultatele interogării imbricate nu trebuie să conțină părți de tabel>/span>;
  • mese virtuale, în special solduri și cifre de afaceri

Practica 2. Nomenclatura cu pretul curent.

Faceți o restricție de acces dacă trebuie să afișați articole cu un preț curent mai mare decât o anumită valoare, de exemplu, 100.

Soluţie:

Adăugăm o nouă regulă de restricție de acces pentru directorul „Nomenclatură” cu dreptul de „citire”.
Selectați „alte câmpuri”.
În constructor adăugăm o interogare imbricată. În acesta, selectați tabelul de registru de informații „Prețuri articole”.
Nu există nicio filă „comandă” - aceasta este o caracteristică a designerului de interogări pentru crearea unei cereri de restricție de acces.
În fila „Avansat”, setați „primul 999999999”, apare fila „comanda”.
Am configurat ordonarea după câmpul „Perioadă” în ordine descrescătoare.
Apoi stabilim o conexiune între tabelul principal și subinterogare prin referință.

Șabloane de restricții de acces.

Practica 3. Restricționarea „contrapărților” în funcție de valoare într-o constantă.

Să setăm o restricție de acces pentru directorul Counterparties pe baza valorii stocate în Constant.

În plus, trebuie să configurați o restricție pentru toate obiectele care utilizează directorul „Contrapărți” în detalii.

Soluţie

Pentru directorul „Contrapărți”, vom configura o restricție pentru dreptul de „citire” prin adăugarea unei interogări imbricate la constantă din secțiunea „Condiții”. Nu uita că acesta este un grup.

Vedem o problemă, directorul Counterparties este filtrat corect și toate documentele cu atributul „Counterparty” sunt afișate, unele cu link-uri „rupte” în atributul „Counterparty”.

Acum trebuie să configurați restricțiile de acces pentru toate obiectele care folosesc linkul către „Conturi”. Să le găsim folosind serviciul „căutare linkuri către un obiect”.

Să copiem și să modificăm ușor textul condiției RLS din directorul „Contrapărți”. Acest lucru trebuie făcut de câte ori sunt găsite obiecte.

Sau utilizați un model de restricții de acces pentru a evita problemele de duplicare a codului.

Șabloanele de restricții de acces sunt configurate la nivel de rol și pot fi utilizate pentru orice obiect din cadrul rolului editat.

Puteți adăuga orice fragment de text cu restricții de acces la șablon. Șablonul este numit folosind simbolul „#”. De exemplu, #TemplateCounterparty.

Prin # în 1C instrucțiunile sunt scrise în preprocesor. În contextul executării setărilor de restricție de acces, platforma înlocuiește textul de apel șablon cu textul șablonului.

Să adăugăm textul după cuvântul UNDE la șablonul „Șablon de contractant”, cu excepția textului despre EtoGroup.

Parametri în șabloanele de restricții de acces.

Să continuăm să rezolvăm problema 2.

Problema acum este că tabelul principal din director se numește „contraparte”, în documentul „Factură de primire”. Câmpul care se verifică în director se numește „link”, în document se numește „Contraparte”.

Să schimbăm numele tabelului principal din textul șablonului în „#CurrentTable”

„#CurrentTable” este un parametru predefinit.

Și printr-un punct indicăm numărul parametrului de intrare - „.#Parameter(1)

„#Parameter” este, de asemenea, o valoare predefinită. Poate conține un număr arbitrar de parametri de intrare. Acestea sunt adresate prin număr de serie.

În textul restricțiilor de acces pentru director, indicăm următoarele:

Pentru document, următoarele:

„Vânzări de bunuri WHERE #TemplateCounterparty („Contraparte”)”

Când apelați un șablon de restricție de acces, parametrii trebuie să îi fie transferați numai ca șir, adică între ghilimele.

Tabel principal - Nomenclator

Textul șablonului este:

#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)

Textul șablonului conține o parte a textului în limba de restricție a accesului la date și poate conține parametri care sunt evidențiați folosind simbolul „#”.

Simbolul „#” poate fi urmat de:

• Unul dintre cuvintele cheie:
  • Un parametru urmat de numărul parametrului din șablon între paranteze;
  • CurrentTable – indică inserarea în text a numelui complet al tabelului pentru care se construiește constrângerea;
  • CurrentTableName– denotă inserarea în text a numelui complet al tabelului (sub formă de valoare șir, între ghilimele) căruia i se aplică instrucțiunea, în versiunea curentă a limbajului încorporat;
  • NameCurrentAccessDreapta– conține denumirea dreptului pentru care se execută restricția curentă: CITEȘTE, ADĂUGAȚI, INSERARE, MODIFICARE, ACTUALIZARE, ȘTERGERE;
• numele parametrului șablonului – înseamnă inserarea constrângerii corespunzătoare parametrului șablonului în text;
• simbolul „#” – indică inserarea unui caracter „#” în text.

O expresie de restricție de acces poate conține:

• Șablon de restricție de acces, care este specificat în format #TemplateName(„Valoarea parametrului șablonului 1”, „Valoarea parametrului șablonului 2”,...). Fiecare parametru de șablon este inclus între ghilimele duble. Dacă trebuie să specificați un caracter de ghilimele duble în textul parametrului, trebuie să utilizați două ghilimele duble.
• Funcția StrContains(WhereWeLook, WhatWeLook). Funcția este concepută pentru a căuta o apariție a șirului WhatWeLook în șirul WhereWeLook. Returnează True dacă apariția este găsită și False în caz contrar.
• Operatorul + este pentru concatenarea șirurilor.

Pentru a facilita editarea textului șablonului, în fila Șabloane de restricții din formularul de rol, faceți clic pe butonul Setați textul șablonului. În caseta de dialog care se deschide, introduceți textul șablonului și faceți clic pe OK.

Ele nu pot fi instalate folosind SetParameter() sau ceva asemanator.

Parametrii în acest caz sunt:

• Opțiuni de sesiune
• Opțiuni funcționale

Citirea parametrilor de sesiune într-o cerere de restricție de acces are loc în modul privilegiat, adică fără controlul drepturilor de a opera cu aceștia.

Practica 4. Acces la contrapărțile „voastre”.

Este necesar să se configureze restricția accesului utilizatorului curent la contrapărțile „lor”.

Există un director „Utilizatori”, un director „Contrapărți”, documente cu detaliile „Contraparte”.

Utilizatorul actual ar trebui să vadă datele numai pentru acele contrapărți pentru care a fost stabilită o conexiune cu el.

Comunicarea trebuie, de asemenea, configurată.

Opțiuni posibile:

Stabilirea legăturilor între utilizator și contraparte

• Detalii în directorul contrapărților
• Registrul de informații

Soluții posibile la problemă:

• Stocarea unui utilizator într-o constantă este o opțiune proastă; constanta este disponibilă pentru toți utilizatorii.
• Stocarea unei matrice fixe de contrapărți ale utilizatorului curent în parametrii de sesiune nu este o opțiune foarte bună; pot exista multe contrapărți
• Stocarea în sesiune a parametrilor utilizatorului curent, apoi solicitarea unei liste a contrapărților „sa” este o opțiune acceptabilă.
• Alte optiuni.

Soluţie.

Să creăm un nou parametru de sesiune „CurrentUser” și să-l completăm în modulul de sesiune.

Să creăm un registru de informații „Conformitatea managerilor și contractorilor”

Să creăm un nou rol și în el o nouă restricție de acces pentru documentul „Factură”.

În textul solicitării, vom conecta tabelul principal cu registrul de informații pentru Account = Account și Manager = &CurrentUser. Tip conexiune Internă.

Dacă este posibil, este mai bine să evitați interogările imbricate în textele de restricție de acces, deoarece acesta va fi executat de fiecare dată când se citesc date din acest obiect din baza de date.

Verificare - restricțiile funcționează

* Caracteristică: Dacă modificați lista de contrapărți utilizatori din registru, restricțiile de acces vor intra în vigoare imediat, fără a reporni sesiunea de utilizator.

Practica 5. Data interzicerii modificărilor.

Este necesar să se implementeze o restricție privind editarea datelor înainte de data stabilită pentru interzicerea modificărilor.
Trebuie să-l limitezi pentru utilizatori.

Să creăm un registru de informații „Date interzicerii modificărilor” cu dimensiunea Utilizator, resursă Data interzicerii.

Să construim logica soluției astfel:

• dacă nu este specificat un utilizator, atunci interdicția se aplică tuturor utilizatorilor
• dacă există o restricție pentru toți utilizatorii și o restricție pentru un anumit utilizator, atunci restricția se aplică pentru un anumit utilizator și pentru alții conform principiului general.

Evident, o astfel de constrângere poate fi configurată pentru obiectele bazei de date care au o anumită poziție pe axa timpului. Poate fi

• Documentație
• Registre periodice de informații

Să creăm un nou rol „Restricții după data interzicerii modificărilor”.

În acesta, pentru documentul „Factură” pentru „schimbarea” corectă vom adăuga o nouă restricție de acces.

Specificăm setarea pentru toate câmpurile.

Textul restricției este:

ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice

Schimbați datele interzicerii Data interzicerii AS Data interzicerii
DIN

INNER JOIN (SELECT
MAX(Modificarea Datelor Interzise.Utilizator) AS Utilizator
DIN
Registrul de informații Datele interzicerii modificărilor AS Datele interzicerii modificărilor
UNDE
(Modificarea Datelor Interzise.Utilizator = &CurrentUser
SAU Datele Interzise Modificări.Utilizator = VALUE(Directory.users.EmptyLink))) AS VZ_User
BY Data interzicerii modificărilor.User = VZ_User.User) AS NestedQuery
Chitanța software Factură.Data > Interogare imbricată.Data interzicerii

Să verificăm - restricția funcționează.

Utilizarea instrucțiunilor preprocesorului

#Dacă Condiția1 #Atunci

Fragmentul de solicitare 1

#ElseIf Condition2 #Atunci

Cerere fragment 2

#In caz contrar

Fragmentul de solicitare 3

#EndIf

În condiții, puteți utiliza operațiuni logice (și, sau, nu, etc.) și acces la parametrii de sesiune.

Această abordare în contextul construirii restricțiilor de acces este convenabilă prin faptul că, în funcție de condiții, va fi compilat un text de cerere mai scurt. O interogare mai simplă încarcă sistemul mai puțin.

Dezavantajul este că constructorul de interogări nu va funcționa cu un astfel de text.

* Particularitate:

Spre deosebire de instrucțiunile către preprocesorul limbajului încorporat din textele de restricție de acces, înainte de operator. Apoi trebuie să puneți un hash - #Atunci

Practica 6. Comutați „Utilizați RLS”

Să completăm sistemul nostru de restricții cu un comutator care pornește/dezactivează utilizarea restricțiilor la nivel de înregistrare.

Pentru a face acest lucru, vom adăuga o constantă și un parametru de sesiune numit „UseRLS”.

Să scriem în Modulul de sesiune pentru a seta valoarea parametrului de sesiune din valoarea constantei.

Să adăugăm următorul cod la toate textele de restricție de acces:

„#Dacă &UseRLS #Atunci….. #EndIf”

Verificăm - totul funcționează.

Cu toate acestea, acum, după activarea steagului „utilizați radar”, modificările nu vor intra imediat în vigoare. De ce?

Deoarece parametrul de sesiune este setat la pornirea sesiunii.

Este posibil să setați valoarea parametrului de sesiune pentru a fi resetat atunci când este scrisă o nouă valoare constantă, dar aceasta va funcționa numai pentru sesiunea curentă a utilizatorului. Alți utilizatori ar trebui să fie solicitați să repornească sistemul.

Sfârșitul primei părți.

Mecanismul RLS din 1C (restricțiuni de acces la nivel de înregistrare) permite dezvoltatorului să-și stabilească propriile selecții și condiții direct pe tabelele bazei de date. Astfel de restricții se pot aplica pentru citirea, adăugarea, modificarea și ștergerea.

Principalul dezavantaj al metodei este reducerea performanței sistemului în ansamblu. Ideea este că selecțiile suplimentare sunt adăugate la interogările principale care preiau datele în mod dinamic. De fiecare dată când utilizatorul accesează orice date din baza de informații care fac obiectul unei restricții, programul va efectua o verificare prin executarea unei interogări.

În ciuda acestui dezavantaj semnificativ, mecanismul RLS este destul de convenabil și flexibil. Cu ajutorul acestuia, puteți configura sistemul astfel încât niciun utilizator să nu vadă ceva „inutil”. Limitarea accesului angajaților tăi, mai ales dacă sunt mulți dintre ei, este foarte productivă. Ideea nu este atât neîncrederea, ci protecția împotriva erorilor întâmplătoare și a factorului uman. Cu cât sunt mai puține date disponibile, cu atât este mai ușor să lucrezi cu ele și să nu te încurci.

Într-unul dintre articolele noastre, am atins deja parțial subiectul restricționării accesului la nivel de înregistrare. În acest caz, va fi luată în considerare o configurație mai aprofundată din partea dezvoltatorului.

Configurarea restricțiilor de acces la nivel de intrare

Configurarea și dezvoltarea radarului se realizează în configuratorul 1C. Pentru a face acest lucru, creați mai întâi un rol în ramura metadate.

În fila „Șabloane de constrângeri”, puteți crea unul sau mai multe astfel de șabloane. În exterior, practic nu diferă cu nimic de cererile obișnuite.

Apoi, accesați fila „Drepturi” a rolului pentru care doriți să setați o restricție. Pentru comoditate, puteți utiliza designerul de interogări, care are doar două file „Tabele și câmpuri” și „Condiții”.

După cum puteți vedea în imaginea de mai jos, am adăugat o singură constrângere cu text:

WHEREProductGroup = &ProductGroup

Ca urmare, atunci când utilizatorul accesează directorul „Nomenclatură”, programul va adăuga o linie cu această condiție la toate solicitările.

Toate setările pentru drepturile utilizatorului pe care le vom face în cadrul acestui articol se află în secțiunea 1C 8.3 „Administrare” - „Setări pentru utilizatori și drepturi”. Acest algoritm este similar în majoritatea configurațiilor pe formularele gestionate. Programul 1C Accounting va fi folosit ca exemplu, dar setarea drepturilor în alte programe (1C UT 11, 1C ZUP 3, 1C ERP) se face exact în același mod.

Să mergem la secțiunea „Utilizatori” din fereastra de setări. Aici vedem două hyperlinkuri: „Utilizatori” și „Setări de conectare”. Primul dintre ele vă permite să mergeți direct la lista de utilizatori a acestei baze de informații. Înainte de a crea un utilizator nou, să ne uităm la posibilele setări de conectare (hyperlink în dreapta).

În acest formular de setări, puteți configura complexitatea parolei (cel puțin 7 caractere, conținut obligatoriu de diferite tipuri de caractere etc.). De asemenea, puteți specifica durata parolei, perioada de valabilitate a acesteia și puteți interzice utilizatorilor să se conecteze la program dacă nu au fost activi pentru o anumită perioadă de timp.

Acum puteți trece direct la adăugarea unui nou utilizator la 1C. Acest lucru se poate face făcând clic pe butonul „Creare”, așa cum se arată în imaginea de mai jos.

În primul rând, vom indica numele complet - „Dmitri Petrovici Antonov” și vom selecta o persoană din directorul corespunzător. Aici puteți indica și departamentul în care lucrează angajatul nostru.

Numele de conectare „AntonovDP” a fost înlocuit automat ca abreviere pentru numele complet „Dmitri Petrovici Antonov”. Să setăm o parolă și o autentificare 1C Enterprise. Aici puteți indica și dacă acest utilizator își poate schimba parola în mod independent.

Să presupunem că dorim ca Dmitri Petrovich Antonov să fie disponibil în lista de selecție atunci când începem această bază de informații. Pentru a face acest lucru, trebuie să setați caseta de selectare pe elementul „Afișați în lista de selecție”. Ca urmare, fereastra de autorizare la pornirea programului va arăta așa cum se arată în figura de mai jos.

Să acordăm atenție unei alte setări importante din cardul directorului utilizatorului - „Este permisă conectarea la program”. Dacă decalajul nu este setat, atunci utilizatorul pur și simplu nu va putea intra în această bază de informații.

Drepturi de acces

După completarea tuturor datelor din cardul de utilizator - Dmitri Petrovici Antonov, le vom nota și trece la configurarea drepturilor de acces, așa cum se arată în figura de mai jos.

O listă de profiluri de acces introduse anterior în program deschisă înaintea noastră. Bifați casetele necesare.

Accesați profiluri de grup

Profilurile grupurilor de acces pot fi configurate din formularul principal de configurare a utilizatorului și a drepturilor. Accesați secțiunea „Grupuri de acces” și faceți clic pe hyperlinkul „Profiluri de acces de grup”.

Să creăm un grup nou din formularul de listă care se deschide. În secțiunea tabelară din fila „Acțiuni (roluri) permise”, bifați casetele pentru acele roluri care vor afecta drepturile de acces ale utilizatorilor incluși în grupul pe care îl creăm. Toate aceste roluri sunt create și configurate în configurator. Nu pot fi modificate sau create altele noi din modul utilizator. Puteți alege doar din lista existentă.

RLS: restricție de acces la nivel de înregistrare

Vă permite să configurați mai flexibil accesul la datele programului în anumite zone. Pentru a-l activa, bifați caseta cu același nume din formularul de setări pentru utilizator și drepturi.

Vă rugăm să rețineți că activarea acestei setări poate afecta negativ performanța sistemului. Ideea este că mecanismul RLS modifică toate cererile în funcție de restricțiile stabilite.

Să mergem la profilul de grup de acces „Grup de testare” pe care l-am creat mai devreme. Figura de mai jos arată că, după activarea restricțiilor de acces la nivel de înregistrare, a apărut o filă suplimentară „Restricții de acces”.

Să presupunem că vrem ca utilizatorii alocați unui grup de testare să aibă acces la datele pentru toate organizațiile din această bază de informații, cu excepția celor specificate în profil.

În partea superioară a tabelului, vom stabili restricții de acces în funcție de organizație. În partea de jos, vom preciza că accesul la date (documente, directoare etc.) nu va fi asigurat pentru organizația „Roga SRL”.

RLS- aceasta este capacitatea dezvoltatorului de a stabili condiții pe tabelele bazei de date pentru anumiți utilizatori (grupuri de utilizatori) și de a-i împiedica să vadă lucruri inutile. Condiția este de tip boolean. Dacă condiția este evaluată la adevărat, atunci accesul este acordat, în caz contrar, acesta este refuzat.

RLS este utilizat simultan cu setarea drepturilor de acces normale. Prin urmare, înainte de a începe configurarea RLS, trebuie să atribuiți drepturi obișnuite obiectelor de configurare.

RLS este utilizat pentru următoarele tipuri de drepturi de acces:

• Citind
• Plus
• Schimbare
• Îndepărtarea

Cum se configurează RLS

Să ne uităm la un exemplu simplu de configurare. Capturile de ecran au fost făcute pe versiunea 1C Enterprise 8.2 (8.2.9.356). Sintaxa șabloanelor de text de constrângere este descrisă în documentația pentru 8.2 din cartea „Ghidul dezvoltatorului. Partea 1”, așa că nu ne vom opri asupra ei.

Deci, primul pas este definirea șabloanelor de constrângeri pentru fiecare rol existent.

După aceasta, pe baza șabloanelor specificate, sunt stabilite restricții asupra obiectelor necesare. Pentru a edita textul unei condiții, puteți utiliza designerul de restricții de acces la date.

Pentru a edita mai multe roluri, este convenabil să gestionați prin fereastra „Toate rolurile”.

Puteți utiliza fereastra Restricții de acces total pentru a copia condițiile în alte roluri. Șabloanele pot fi copiate numai manual în alte roluri.

Asta e tot. Puteți verifica rezultatul.

Dezavantajele utilizării RLS:

1. Utilizarea unui mecanism de restricție de acces la nivel de înregistrare duce la o creștere implicită a tabelelor care participă la interogare, ceea ce poate duce la erori în modul client-server al bazei de date.
2. Poate fi dificil sau imposibil să implementați logica complexă a aplicației pentru controlul scrierii. În astfel de cazuri, este mai bine să folosiți condiții în procedura OnWrite().
3. Scrierea unei condiții (interogare) necesită anumite calificări ale dezvoltatorului.
4. Dificultăți suplimentare pot fi create de incapacitatea de a depana o condiție (interogare).

În configurațiile tipice, drepturile la nivel de înregistrare pot fi setate interactiv pentru următoarele obiecte: organizații, contrapărți, articole, depozite, divizii, persoane fizice, aplicații candidate și altele.

Trebuie amintit că restricțiile privind drepturile de acces la nivel de înregistrare sunt un mecanism destul de intensiv în resurse, iar cu cât le setați restricții mai complexe, cu atât programul va funcționa mai lent, în special cu o bază de date mare.