Platforma 1C: Enterprise 8 ka një mekanizëm të integruar për kufizimin e aksesit në të dhëna në nivel rekord. Ju mund të lexoni informacion të përgjithshëm në lidhje me të këtu. Shkurtimisht, RLS do t'ju lejojë të kufizoni aksesin në të dhëna sipas disa kushteve në vlerat e fushës. Për shembull, mund të kufizoni aksesin e përdoruesve në dokumente në varësi të vlerës së atributit "Organizimi". Disa përdorues do të punojnë me dokumente për organizatën "Management Company", ndërsa pjesa tjetër me organizatën "Uzina e qumështit". Si nje shembull.
Trajnimi
Shembulli zbatohet në konfigurimin demonstrues të SCP 1.3. Le të krijojmë një përdorues "Storekeeper" dhe t'i shtojmë atij rolin "Storekeeper" me të njëjtin emër.
Tani le të vazhdojmë drejtpërdrejt me vendosjen e të drejtave të aksesit në nivelin e rekordeve. Le të kalojmë në ndërfaqen "Administrimi i përdoruesit". Në menynë kryesore, zgjidhni "Qasja në nivelin e të dhënave -> Opsionet". Këtu kontrollojmë kutinë "Kufizoni aksesin në nivel rekord sipas llojeve të objekteve" dhe në listën e objekteve zgjidhni "Organizatat".
Kështu, ne kemi mundësuar përdorimin e RLS. Tani ju duhet ta konfiguroni atë.
Kontrolli i hyrjes në nivelin e regjistrimit nuk është konfiguruar veçmas për secilin përdorues ose profile leje. RLS është konfiguruar për grupet e përdoruesve. Le të shtojmë një grup të ri përdoruesish, le ta quajmë "Magazinierë"
Përbërja e grupit në anën e djathtë të formularit tregon një listë të përdoruesve që i përkasin këtij grupi. Le të shtojmë përdoruesin që krijuam më parë. Në të majtë është një tabelë e kufizimeve të hyrjes. Në cilësimin RLS, ne kemi zgjedhur që qasja të kufizohet vetëm nga organizatat, kështu që shohim vetëm një lloj objekti aksesi. Klikoni në butonin "Access Settings". Hapet përpunimi për vendosjen e lejeve për grupin aktual.
Në listën e objekteve të aksesit për grupin, shtoni organizatën "PPE "Sipërmarrës"". Llojin e trashëgimisë së të drejtave do ta lëmë të pandryshuar. E drejta për objektin e aksesit do të vendoset për të lexuar dhe shkruar. Klikoni "OK", cilësimet janë gati. Sapo kemi ngritur RLS në nivel organizate.
Çfarë sheh përdoruesi
Drejtoni programin nën përdoruesin e krijuar më parë dhe hapni drejtorinë "Organizatat". Kështu do të duket lista për përdoruesin tonë dhe për një përdorues me të drejta të plota:
Siç mund ta shohim, përdoruesi i magazinierit sheh vetëm një organizatë për të cilën ne kemi hapur akses për lexim. E njëjta gjë vlen edhe për dokumentet, si p.sh. faturat e mallrave dhe shërbimeve.
Kështu, përdoruesi jo vetëm që nuk do të shohë organizatat, qasja në të cilat nuk është caktuar për të, por gjithashtu nuk do të jetë në gjendje të lexojë / shkruajë dokumente dhe objekte të tjera në bazën e informacionit, për të cilat të drejtat në rolin në atributin ". Organizimi” janë vendosur.
Ne kemi shqyrtuar shembullin më të thjeshtë të konfigurimit të RLS. Në artikullin tjetër, do të flasim për zbatimin e mekanizmit RLS në konfigurimin "Menaxhimi i Ndërmarrjeve Prodhuese" versioni 1.3.
Objekti i konfigurimit "role" jep një grup të drejtash për operacionet (veprimet) në objektet e konfigurimit.
Roli "Të drejta të plota".
Ky është thjesht një rol (jo i paracaktuar) që ka kuti për të gjitha llojet e të drejtave në të gjitha objektet e konfigurimit.
Dallimi i tij nga rolet e tjera është prania e së drejtës së “Administratës”.
Nëse krijohet të paktën një përdorues, sistemi fillon të kontrollojë për të drejtën "Administrim" - të paktën një përdorues duhet ta ketë atë.
Kufizoni aksesin në nivel rekord
Siguria e nivelit të rreshtit (RLS) - Kufizim në nivel rekord.
Mekanizmi i kufizimeve të aksesit të të dhënave ju lejon të menaxhoni të drejtat e aksesit jo vetëm në nivelin e objekteve të meta të dhënave, por edhe në nivelin e objekteve të bazës së të dhënave. Objektet e mëposhtme mund të përdoren për të kufizuar aksesin në të dhëna:
- rolet,
- opsionet e sesionit,
- opsionet funksionale,
- module të përbashkëta të privilegjuara,
- fjala kyçe LEJOHET në gjuhën e pyetjes.
Mekanizmi është krijuar për të kufizuar hyrjen në të dhënat e tabelës së objekteve të meta të dhënave sipas kushteve arbitrare të vendosura në vlerat e fushave të rreshtave të këtyre tabelave. Për shembull, për të parë të dhënat vetëm për palët, organizatat "tuaja", etj.
Zbatimi teknik i kufizimeve të aksesit në 1C
1C gjeneron një kërkesë për DBMS. Grupi i serverit shton një seksion WHERE në kërkesë, i cili përmban tekstin e kushtit për kufizimin e aksesit nga RLS, më pas kjo kërkesë dërgohet në DBMS, të dhënat e nxjerra i kthehen klientit 1C.
Ky mekanizëm do të funksionojë për çdo kërkesë nga klienti:
- në raportet
- në listat dinamike dhe format e listave të rregullta
- në kërkesa të rastësishme.
Një zbatim i tillë i mekanizmit ndikon shumë në performancën.
Mënyrat për të anashkaluar kufizimet e aksesit.
Në operacione të mëdha me burime intensive (për shembull, përpunimi i ripostimit të dokumenteve), një pjesë e kodit mund të zhvendoset në module të privilegjuara.
POR) modul i privilegjuar është një modul i përbashkët me flamurin "I privilegjuar" në prona.
E veçanta e tij qëndron në faktin se kodi në të ekzekutohet pa asnjë kontroll aksesi, përfshirë RLS.
B) gjithashtu të privilegjuar modaliteti mund të aktivizohet për modulet e objektit të dokumentit. Kjo bëhet në pronat e dokumentit, flamuri
- Modaliteti i privilegjuar gjatë mbajtjes
- Modaliteti i privilegjuar kur anuloni planin
C) Metoda SetPrivilegedMode()
Një komandë sistemi që ju lejon të bëni një pjesë të kodit të çdo moduli të privilegjuar.
Nga rreshti tjetër i kodit, mënyra e privilegjuar e ekzekutimit do të jetë në fuqi.
Ai do të veprojë deri në linjën për çaktivizimin e këtij modaliteti ose deri në fund të procedurës / funksionit
(E vërtetë);
// çdo kod këtu do të ekzekutohet pa kontroll të të drejtave dhe RLS
SetPrivilegedMode(Gënjeshtra); // ose fundi i procedurës / funksionit
Numri i aktivizimeve të modalitetit të privilegjuar duhet të përputhet me numrin e çaktivizimeve. Megjithatë, nëse modaliteti i privilegjuar është aktivizuar (një ose më shumë) brenda një procedure ose funksioni, por nuk është çaktivizuar, sistemi automatikisht do ta çaktivizojë atë aq herë sa ka pasur aktivizime në pritje në procedurë ose funksion që braktiset.
Nëse në një procedurë ose metodë funksioni thërret SetPrivilegedMode(E rreme) më shumë se thirrjet e bëra me metodë SetPrivilegedMode(e vërtetë) atëherë do të hidhet një përjashtim
Funksioni Modaliteti i privilegjuar() kthen True nëse modaliteti i privilegjuar është ende i aktivizuar dhe False nëse modaliteti i privilegjuar është plotësisht i çaktivizuar. Nuk analizon numrin e cilësimeve të modalitetit të privilegjuar në një funksion të caktuar.
Të gjitha procedurat dhe funksionet e thirrura do të ekzekutohen gjithashtu në modalitetin e privilegjuar.
Është gjithashtu e mundur të filloni një seancë të privilegjuar. Ky është një seancë në të cilën modaliteti i privilegjuar është vendosur që në fillim të sistemit. Në të njëjtën kohë, gjatë funksionimit, metoda Modaliteti i privilegjuar() do të kthehet gjithmonë e vërtetë dhe aftësia për të çaktivizuar modalitetin e privilegjuar nuk mbështetet. Vetëm një përdorues me të drejta administrative (e drejta e administrimit) mund të fillojë një sesion të privilegjuar. Sesioni mund të fillohet duke përdorur çelësin e linjës së komandës për lëshimin e aplikacionit të klientit UsePrivilegedMode ose parametrin e vargut të lidhjes së bazës së informacionit prmod.
Natyrisht lind pyetja: Pse, atëherë, të vendosen fare kufizime aksesi, nëse mund të anashkalohet kaq lehtë?
Modaliteti i sigurt.
Po, është e mundur të shkruhet përpunimi i jashtëm me modalitetin e ekzekutimit të privilegjuar dhe të shkarkohen/korruptohen të dhënat. Për të parandaluar këtë, sistemi ka një metodë të kontekstit global
Vendos SafeMode().
Modaliteti i sigurt, ndër të tjera, injoron modalitetin e privilegjuar.
Duhet të vendoset përpara se të telefononi në mënyrë programore mbajtës të jashtëm ose të eksportoni procedura dhe funksione nga modulet e tyre.
Hedh një përjashtim kur kryen operacione të ndaluara në kohën e ekzekutimit.
Për më tepër, për përdoruesit, mund të çaktivizoni aftësinë për të nisur në mënyrë interaktive raporte të jashtme dhe përpunim në nivelin e cilësimeve të roleve.
Cilësimi i kufizimit të aksesit
RLS mund të konfigurohet vetëm për të drejtat:
- lexim (zgjidh)
- duke shtuar (fut)
- ndryshim (përditësim)
- fshirje (fshirje)
Për operacionet e leximit dhe fshirjes, objekti në bazën e të dhënave duhet të përputhet me kufizimin e aksesit të të dhënave.
Për operacionin e shtimit kufizimi i aksesit të të dhënave duhet të korrespondojë me objektin që planifikohet të shkruhet në bazën e të dhënave.
Për operacionin e ndryshimit Kufizimi i aksesit të të dhënave duhet të përputhet me objektin si përpara ndryshimit (që objekti të lexohet) ashtu edhe pas ndryshimit (që objekti të shkruhet).
Për të gjitha të drejtat e tjera, ky opsion nuk është i disponueshëm.
Le të shtojmë një kufizim të ri për të drejtën e "leximit" të librit të referencës "Nomenklatura". Do të hapet një listë e fushave për të cilat mund të konfiguroni kufizimin e shtuar.
Kjo do të thotë që nëse përpiqeni të hyni në fushat me kuti të kontrollit, kufizimi do të funksionojë, por nëse përpiqeni të hyni në fushat e pakontrolluara, kufizimi nuk do të funksionojë.
Nëse zgjidhni flamurin Fusha të tjera”, kufizimi do të vendoset për të gjitha fushat e tabelës, me përjashtim të fushave për të cilat kufizimet janë vendosur në mënyrë eksplicite.
*Veçori: për të drejtat për të shtuar, ndryshuar, fshirë:
- Kufizimi mund të konfigurohet vetëm për të gjitha fushat.
- Mund të ketë vetëm një kufi.
Për të drejtën "Lexo", mund të vendosni disa kushte, ato do të kombinohen me operatorin logjik "AND".
Në kufizimet për objektet e bazës së të dhënave të llojeve të mëposhtme, jo të gjitha fushat e objektit kryesor të të dhënave të kufizimit mund të përdoren:
- në regjistrat e akumulimit, kufizimet e aksesit mund të përmbajnë vetëm matje të objektit kryesor të kufizimit;
- në regjistrat kontabël në kufizime, mund të përdorni vetëm matjet e bilancit të objektit kryesor të kufizimit
Nëse, në kushtet e aksesit të kufizuar në të dhënat e regjistrit të qarkullimit të akumulimit, përdoren matje që nuk përfshihen në total, atëherë kur hyni në tabelën e qarkullimit virtual, totalet e ruajtura nuk përdoren dhe pyetja ekzekutohet plotësisht sipas tabela e lëvizjes.
Mekanizmi për vendosjen e kufizimeve të aksesit.
Çdo operacion mbi të dhënat e ruajtura në bazën e të dhënave në 1C: Enterprise përfundimisht rezulton në aksesin në bazën e të dhënave me një kërkesë për të lexuar ose modifikuar të dhënat. Gjatë ekzekutimit të pyetjeve në bazën e të dhënave, mekanizmat e brendshëm të 1C: Enterprise vendosin kufizime aksesi. ku:
- Është formuar lista e të drejtave(lexo, shto, përditëso, fshi), një listë e tabelave të bazës së të dhënave dhe një listë fushash të përdorura nga kjo pyetje.
- Nga të gjitha rolet e përdoruesit aktual zgjidhni kufizimet e hyrjes të dhënat për të gjitha të drejtat, tabelat dhe fushat e përfshira në kërkesë. Për më tepër, nëse ndonjë rol nuk përmban kufizime aksesi në të dhënat e ndonjë tabele ose fushe, atëherë kjo do të thotë që vlerat e fushave të kërkuara nga çdo rekord janë të disponueshme në këtë tabelë. Me fjalë të tjera, mungesa e një kufizimi të aksesit të të dhënave do të thotë se ekziston një kufizim WHERE True.
- Merrni vlerat aktuale të të gjithë parametrave të sesionit dhe opsioneve funksionale duke marrë pjesë në kufizimet e zgjedhura.
Marrja e vlerës së një parametri sesioni ose opsioni funksional nuk kërkon që përdoruesi aktual të ketë të drejtën për të marrë atë vlerë. Megjithatë, nëse vlera e disa parametrave të sesionit nuk është vendosur, atëherë do të ndodhë një gabim dhe pyetja e bazës së të dhënave nuk do të ekzekutohet.
Kufizimet që rrjedhin nga i njëjti rol kombinohen me një operacion AND.
Kufizimet e marra nga role të ndryshme kombinohen me operacionin OR.
Kushtet e ndërtuara u shtohen pyetjeve SQL me të cilat 1C: Enterprise akseson DBMS. Kur aksesoni të dhënat nga ana e kushteve të kufizimit të aksesit, nuk kryhet asnjë kontroll i të drejtave (as objekteve të meta të dhënave, as objekteve të bazës së të dhënave). Për më tepër, mekanizmi për shtimin e kushteve varet nga mënyra e zgjedhur e funksionimit të kufizimeve "të gjitha" ose "të lejuara".
*Karakteristika: Nëse një përdorues ka akses në disa role me kufizime të konfiguruara në nivelin e regjistrimeve për një objekt, atëherë në këtë rast kushtet e kufizimeve shtohen nga operacioni logjik "OR". Me fjalë të tjera, lejet e përdoruesit janë kumulative.
Kjo çon në përfundimin e mëposhtëm: mos lejoni që kushti i kufizimit të aksesit në një objekt në role të ndryshme të kryqëzohet, sepse në këtë rast teksti i pyetjes do të bëhet shumë më i ndërlikuar dhe kjo do të ndikojë në performancën.
Gjithsesi.
Kur vendosen kufizime duke përdorur metodën "të gjitha", kushtet dhe fushat shtohen në pyetjet SQL në mënyrë që 1C: Enterprise të mund të marrë informacion nëse të dhënat që janë të ndaluara për përdoruesin e caktuar janë përdorur në procesin e ekzekutimit të një pyetjeje të bazës së të dhënave apo jo . Nëse janë përdorur të dhëna të ndaluara, atëherë kërkesa ndërpritet për shkak të shkeljes së aksesit.
Vendosja e kufizimeve të aksesit me metodën "të gjithë" tregohet skematikisht në figurë:
Metoda "e lejuar".
Kur vendosen kufizime duke përdorur metodën "e lejuar", kushte të tilla shtohen në pyetjet SQL në mënyrë që të dhënat e ndaluara për përdoruesin aktual të mos ndikojnë në rezultatin e pyetjes. Me fjalë të tjera, kur vendosen kufizime në modalitetin "e lejuar", hyrjet e ndaluara për këtë përdorues konsiderohen të munguara dhe nuk ndikojnë në rezultatin e operacionit, i cili tregohet skematikisht në figurë:
Kufizimet e aksesit të të dhënave vendosen në objektet e bazës së të dhënave kur 1C: Enterprise hyn në bazën e të dhënave.
Në versionin klient-server të 1C:Enterprise, kufizimet zbatohen në serverin 1C:Enterprise.
Megjithatë, ky opsion (LEJOHET) nuk do të funksionojë nëse i referohemi një tabele në pyetje për të cilën nuk janë konfiguruar kufizimet e aksesit, por në të cilën ka lidhje me rreshtat e tabelës me kufizime të konfiguruara. Në këtë rast, rezultati i pyetjes do të jetë "<Объект не найден>……” në vend të vlerës së fushës së referencës.
Nëse jeni duke zhvilluar një raport ose përpunuar duke përdorur pyetje të përgjithshme ose të personalizuara të konfigurimit, kontrolloni gjithmonë flamurin "E lejuar". që raporti të funksionojë nën çdo përdorues me çdo grup të drejtash.
Në rastin e të dhënave të leximit të objekteve nga baza e të dhënave, nuk është e mundur të vendoset flamuri "Lejohet". Prandaj, është e nevojshme konfiguroni zgjedhjet për leximin e objekteve, duke marrë parasysh kufizimet e mundshme në të drejtat e aksesit për përdoruesin. Nuk ka mjete për të marrë vetëm të dhëna të lejuara në teknologjinë e objektit.
Është e rëndësishme që nëse fjala kyçe E LEJUAR nuk është e specifikuar në pyetje, atëherë të gjithë filtrat e specifikuar në atë pyetje nuk duhet të bien ndesh me asnjë nga kufizimet në leximin e objekteve të bazës së të dhënave të përdorura në pyetje. Për më tepër, nëse në pyetje përdoren tabela virtuale, atëherë filtrat përkatës duhet të vendosen në vetë tabelat virtuale.
Praktika 1. Ndërtuesi i pyetjeve në cilësimet RLS.
Le të kompozojmë tekstin e seksionit "KU" në pyetjen e drejtorisë. Ju mund të përdorni ndërtuesin e pyetjeve.
Konstruktori është i cunguar.
Skeda "Tabelat"
Tabela kryesore do të jetë tabela e objektit për të cilin po konfigurohet kufizimi.
Ju gjithashtu mund të zgjidhni tabela të tjera dhe të vendosni marrëdhënie të ndryshme midis tyre në skedën "Marrëdhëniet".
Skeda e kushteve
Këtu mund të konfiguroni kushtet aktuale për kufizimin e aksesit.
Le të shtojmë kushte për atributin "Çmimi" të drejtorisë së listës së aksioneve për të drejtën për "lexim" në të gjitha fushat e tabelës.
"Nomenklatura WHERE Nomenklatura. Çmimi > 500"
Le të shohim se si funksionon ky rregull i thjeshtë. Tabela e referencës përmban elementët e mëposhtëm:
Pas vendosjes së kufizimit të hyrjes, tabela do të tregojë vetëm elementët që plotësojnë kushtin:
Grupet gjithashtu janë zhdukur. Ndryshoni tekstin e kufizimit
"Nomenklatura WHERE Nomenklatura. Cmimi > 500
OSE Nomenklatura. Ky është një grup"
Epo, tani ja çfarë ju nevojitet.
Nëse hiqni shfaqjen e fushës "kodi" në cilësimet e listës, do të shfaqen të gjithë elementët e drejtorisë, d.m.th. kufizimi nuk funksionoi. Nëse vendosni shfaqjen e fushës "Kodi", kufizimi do të funksionojë.
Në të njëjtën kohë, përkundër faktit se elementi i kërkimit është i dukshëm në fushën e listës, forma e tij nuk mund të hapet, sepse është vendosur një kufizim në atributin. E njëjta gjë në një kërkesë arbitrare: kur përpiqeni të merrni një atribut "të kufizuar", do të ketë një gabim aksesi.
Nëse përpiqeni të merrni në mënyrë programore elementet "të kufizuara", do të shfaqet gjithashtu një gabim aksesi.
Për më tepër, do të jetë e pamundur të qaseni në ndonjë fushë të objektit përmes një lidhjeje, sepse kur merret një lidhje, sistemi lexon të gjithë objektin dhe nëse ka detaje "të kufizuara", objekti nuk do të lexohet.
Prandaj, kur punoni me objektet e bazës së të dhënave në mënyrë programore, duhet të keni parasysh kufizimet e mundshme në nivelin e regjistrimit dhe të merrni të gjitha të dhënat e nevojshme të objektit me një pyetje dhe më pas t'i vendosni ato në një strukturë ose të ekzekutoni një pjesë të kodit në një modul të privilegjuar.
Pas vendosjes së kufizimit të hyrjes, shfaqja e rreshtit në listën e të drejtave ndryshoi - u bë gri dhe u shfaq një ikonë.
Kufizimet e konfigurimit të aksesit (RLS).
- Nuk ka seksion përmbledhës;
- Nuk mund të hyni në tabelat e regjistrave virtualë;
- Ju nuk mund të përdorni në mënyrë të qartë parametrat;
- Nënpyetjet mund të përdoren any>/span> lehtësirat e gjuhës së pyetjes, përveç:
- operatori NË HIERARKI;
- ofron REZULTATET;
- rezultatet e pyetjeve të ndërlidhura nuk duhet të përmbajë pjesë tabelare>/span>;
- tabelat virtuale, në veçanti Bilancet dhe Qarkullimet
Praktika 2. Nomenklatura me çmimin aktual.
Bëni një kufizim aksesi nëse keni nevojë të shfaqni një artikull me çmimin aktual më të madh se një vlerë e caktuar, për shembull, 100.
Vendimi:
Shtojmë një rregull të ri të kufizimit të aksesit për librin e referencës "Nomenklatura" për të drejtën "lexo".
Zgjidhni "fusha të tjera".
Në konstruktor, shtoni një pyetje të mbivendosur. Në të, zgjidhni tabelën e regjistrit të informacionit "Çmimet e artikujve".
Nuk ka asnjë skedë "porosi" - kjo është një veçori e ndërtuesit të pyetjeve për ndërtimin e një pyetjeje të kufizimit të aksesit.
Në skedën "Advanced", vendosni "first 999999999", skeda "porosia" është shfaqur.
Vendosni renditjen sipas fushës "Periudha" në rend zbritës.
Më pas vendosim lidhjen e tabelës kryesore me nënpyetësin me referencë.
Modelet e kufizimit të aksesit.
Praktika 3. Kufizimi i "kontraktorëve" sipas vlerës në një konstante.
Vendosni kufizimin e hyrjes për direktorinë e palëve sipas vlerës së ruajtur në konstant.
Përveç kësaj, duhet të vendosni një kufizim për të gjitha objektet që përdorin direktorinë "Kontraktorët" në detaje.
Vendimi
Për librin e referencës "Llogaritë", për të drejtën "lexo", do të vendosim një kufizim duke shtuar një pyetje të ndërthurur në konstante në seksionin "Kushtet". Mos harroni këtë Grup.
Ne e shohim problemin, drejtoria Counterparties është filtruar saktë dhe shfaqen të gjitha dokumentet me atributin "Counterparty", disa me lidhje "të prishura" në atributin "Counterparty".
Tani ju duhet të konfiguroni kufizimin e hyrjes për të gjitha objektet duke përdorur lidhjen te "Llogaritë". Le t'i gjejmë me shërbimin "kërko lidhje me një objekt".
Le të kopjojmë dhe modifikojmë pak tekstin e kushtit RLS nga drejtoria "Counterparties". Kjo duhet bërë aq herë sa gjenden objekte.
Ose përdorni modelin e kufizimit të aksesit për të shmangur problemet e dyfishimit të kodit.
Modelet e kufizimit të aksesit janë konfiguruar në nivelin e rolit dhe mund të përdoren për çdo objekt brenda rolit të redaktuar.
Mund të vendosni çdo pjesë të tekstit të kufizimit të aksesit në shabllon. Shablloni thirret përmes simbolit "#". Për shembull, #TemplateContractor.
Nëpërmjet # në 1C, udhëzimet i shkruhen paraprocesorit. Në kontekstin e ekzekutimit të cilësimeve të kufizimit të aksesit, platforma zëvendëson tekstin e thirrjes së shabllonit me tekstin e shabllonit.
Le ta zhvendosim tekstin pas fjalës WHERE në shabllonin "TemplateContractor", përveç tekstit për ThisGroup.
Parametrat në shabllonet e kufizimit të aksesit.
Le të vazhdojmë të zgjidhim problemin 2.
Problemi tani është se tabela kryesore në drejtori quhet "kundërpalë", në dokumentin "Faturë". Fusha e kontrolluar në drejtori quhet "lidhje", në dokument - "Kontraparti".
Ndrysho emrin e tabelës kryesore në tekstin e shabllonit në "#CurrentTable"
"#CurrentTable" është një parametër i paracaktuar.
Dhe përmes pikës tregojmë numrin e parametrit të hyrjes - “.#Parameter(1)
"#Parameter" është gjithashtu një vlerë e paracaktuar. Mund të përmbajë një numër arbitrar parametrash hyrës. Ato referohen me numrin serial.
Në tekstin e kufizimit të hyrjes për drejtorinë, ne tregojmë sa vijon:
Për dokumentin si më poshtë:
“Shitja e mallrave WHERE #TemplateContractor(“Kontraktori”)”
Kur thirrni shabllonin e kufizimit të aksesit, parametrat duhet t'i kalojnë atij vetëm si varg, d.m.th. në thonjëza.
Tabela kryesore - Nomenklatura
Teksti i shabllonit është:
#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)
Teksti i shabllonit përmban një pjesë të tekstit në gjuhën e kufizimit të aksesit të të dhënave dhe mund të përmbajë parametra që theksohen me simbolin "#".
Karakteri "#" mund të pasohet nga:
- Një nga fjalët kyçe:
- Një parametër i ndjekur nga numri i parametrit në shabllonin në kllapa;
- CurrentTable - nënkupton futjen në tekst të emrit të plotë të tabelës për të cilën po ndërtohet kufizimi;
- Emri aktual i tabelës– tregon futjen në tekst të emrit të plotë të tabelës (si vlerë vargu, në thonjëza), në të cilën zbatohet udhëzimi, në versionin aktual të gjuhës së integruar;
- EmriCurrentPermission– përmban emrin e së drejtës për të cilën kryhet kufizimi aktual: LEXO/LEXO, SHTO/INSERT, MODIFIKO/Përditëso, FSHI/FSHI;
- emri i parametrit shabllon – nënkupton futjen e kufizimit të parametrit përkatës të shabllonit në tekst;
- simboli "#" - tregon futjen e një simboli të vetëm "#" në tekst.
Një shprehje e kufizimit të aksesit mund të përmbajë:
- Modeli i kufizimit të aksesit, i cili specifikohet në format #TemplateName("Vlera e parametrit të shabllonit 1", "Vlera e parametrit të shabllonit 2",...). Çdo parametër shabllon është i mbyllur në thonjëza të dyfishta. Nëse duhet të specifikoni një karakter thonjëza të dyfishtë në tekstin e parametrit, përdorni dy thonjëza të dyfishta.
- Funksioni StrContains (ku po kërkojmë, çfarë po kërkojmë). Funksioni është krijuar për të kërkuar një ndodhi të WhatLooking for në vargun WhereLooking for. Kthen "E vërtetë" nëse gjendet përputhja, e gabuar përndryshe.
- Operatori + për lidhjen e vargjeve.
Për lehtësinë e redaktimit të tekstit të shabllonit, në skedën Modelet e kufizimit në formën e roleve, klikoni butonin Vendos tekstin e shabllonit. Në dialogun që hapet, futni tekstin e shabllonit dhe klikoni OK.
Ato nuk mund të instalohen duke përdorur setParameter () apo diçka të ngjashme.
Në këtë rast, parametrat janë:
- Opsionet e sesionit
- Opsionet Funksionale
Leximi i parametrave të sesionit në një kërkesë për kufizim aksesi ndodh në një mënyrë të privilegjuar, d.m.th. pa kontroll të të drejtave për të vepruar me to.
Praktika 4. Qasja te palët “tuaj”.
Është e nevojshme të vendoset kufizimi i aksesit të përdoruesit aktual në palët "e tyre".
Ekziston një direktori "Përdoruesit", një drejtori "Kundërpalët", dokumente me "Kundërpartinë" e nevojshme.
Përdoruesi aktual duhet të shohë të dhëna vetëm për ato palë për të cilat është krijuar një lidhje me të.
Komunikimi gjithashtu duhet të konfigurohet.
Opsionet e mundshme:
Krijimi i lidhjeve përdorues + palë
- Detajet në dosjen e palëve
- Regjistri i informacionit
Zgjidhjet e mundshme për problemin:
- Ruajtja e përdoruesit në një konstante është një opsion i keq, konstanta është e disponueshme për të gjithë përdoruesit.
- Mbajtja e një grupi fiks të palëve të përdoruesit aktual në parametrat e sesionit nuk është një opsion i mirë, mund të ketë shumë palë
- Ruani në parametrat e sesionit të përdoruesit aktual, më pas kërkoni të merrni një listë të palëve "të tij" - një opsion i pranueshëm.
- Opsione të tjera.
Vendimi.
Le të krijojmë një parametër të ri sesioni "CurrentUser" dhe të shkruajmë plotësimin e tij në modulin e sesionit.
Le të krijojmë një regjistër informacioni "Korrespondenca e menaxherëve dhe palëve"
Le të krijojmë një rol të ri dhe në të një kufizim të ri aksesi për dokumentin "Fatura e marrjes".
Në tekstin e pyetjes, ne do të lidhim tabelën kryesore me regjistrin e informacionit nga Kontraktori = Kontraktori dhe Menaxheri = &Përdoruesi aktual. Lloji i lidhjes Brendshme.
Nëse është e mundur, është më mirë të shmangni pyetjet e mbivendosura në tekstet e kufizimit të aksesit, sepse ai do të ekzekutohet sa herë që të dhënat nga ky objekt lexohen nga baza e të dhënave.
Ne kontrollojmë - kufizimet funksionojnë
*Veçori: Nëse ndryshoni listën e palëve të tjera të përdoruesit në regjistër, kufizimet e aksesit do të hyjnë në fuqi menjëherë pa rifilluar sesionin e përdoruesit.
Praktika 5. Nuk ka ndryshim data.
Është e nevojshme të zbatohet kufizimi për redaktimin e të dhënave më herët se data e caktuar për ndalimin e ndryshimeve.
Përdoruesit duhet të jenë të kufizuar.
Le të krijojmë një regjistër informacioni "ChangeBarDateDate" me dimensionin User, RestrictedDate burim.
Le të ndërtojmë logjikën e zgjidhjes në këtë mënyrë:
- nëse përdoruesi nuk është i specifikuar, atëherë ndalimi vlen për të gjithë përdoruesit
- nëse ka një kufizim për të gjithë përdoruesit dhe një kufizim për një përdorues specifik, atëherë ka një kufizim për një përdorues specifik, dhe për pjesën tjetër sipas parimit të përgjithshëm.
Natyrisht, një kufi i tillë mund të konfigurohet për objektet e bazës së të dhënave që kanë një pozicion të caktuar në boshtin kohor. Ajo mund të jetë
- Dokumentacioni
- Regjistrat e informacionit periodik
Le të krijojmë një rol të ri "RestrictionsBy ChangeProhibitionDate".
Në të, për dokumentin "Faturë Fatura" për "ndryshimin" e duhur do të shtojmë një kufizim të ri aksesi.
Cilësimi është specifikuar për të gjitha fushat.
Teksti i kufizimit është:
Fatura e Faturës NGA Dokumenti Faturë Fatura AS Faturë Faturë
Ndrysho Datat e ndalimit.Data e ndalimit AS Data e ndalimit
NGA
BASHKIMI I BRENDSHËM (ZGJEDH
MAXIMUM(ChangeProhibitionDate.User) AS Përdorues
NGA
Regjistri i Informacionit Datat e Ndalimit të Ndryshimeve SI Data e Ndalimit të Ndryshimeve
KU
(ChangeProhibitionDates.User = &CurrentUser
ORChangeProhibitionDate.User = VALUE(Reference.users.NullReference))) AS OT_User
BYChangeProhibitedDate.User = OT_User.User) AS Nënpyetje
Fatura e faturës.Data > NestedRequest.BanDate
Ne kontrollojmë - kufizimi funksionon.
Përdorimi i udhëzimeve të paraprocesorit
#Nëse Kushti 1 #Atëherë
Kërkoni fragmentin 1
#ElseIf Condition2 #Atëherë
Kërkoni fragmentin 2
#Përndryshe
Kërkoni fragmentin 3
#FundNëse
Në kushte, mund të përdorni operacione logjike (dhe. ose, jo, etj.) dhe akses në parametrat e sesionit.
Kjo qasje në kontekstin e kufizimeve të aksesit të ndërtimit është e përshtatshme sepse, në varësi të kushteve, do të përpilohet një tekst më i shkurtër i pyetjes. Një kërkesë më e thjeshtë e ngarkon sistemin më pak.
Ana negative është se konstruktori i pyetjeve nuk do të funksionojë me një tekst të tillë.
* Veçori:
Ndryshe nga udhëzimet për paraprocesorin 1C:Enterprise në tekstet e kufizimit të aksesit, paraprini operatorin Pastaj me një shenjë hash — #Then
Praktikoni 6. Ndërroni "Përdor RLS"
Le të plotësojmë sistemin tonë të kufizimit me një ndërprerës që mundëson/çaktivizon përdorimin e kufizimit në nivel rekord.
Për ta bërë këtë, shtoni një parametër konstant dhe një sesion të quajtur "UseRLS".
Le të shkruajmë në Session Module vendosjen e vlerës së parametrit të sesionit nga vlera e konstantës.
Shtoni kodin e mëposhtëm në të gjitha tekstet e kufizimit të aksesit:
"#If &UseRLS #Atëherë….. #EndNëse"
Ne kontrollojmë - gjithçka funksionon.
Megjithatë, tani pas ndezjes së flamurit "përdor radar", ndryshimet nuk do të hyjnë në fuqi menjëherë. Pse?
Sepse parametri i sesionit vendoset kur fillon sesioni.
Është e mundur të rivendoset parametri i sesionit kur shkruhet një vlerë e re konstante, por kjo do të funksionojë vetëm për sesionin aktual të përdoruesit. Përdoruesve të tjerë duhet t'u kërkohet të rinisin sistemin.
Fundi i pjesës së parë.
Mekanizmi RLS në 1C (kufizimet e hyrjes në nivelin e regjistrimit) i lejon zhvilluesit të vendosë zgjedhjet dhe kushtet e veta drejtpërdrejt në tabelat e bazës së të dhënave. Kufizime të tilla mund të zbatohen për leximin, shtimin, modifikimin dhe fshirjen.
Disavantazhi kryesor i metodës është ulja e efikasitetit të sistemit në tërësi. Çështja është se filtra shtesë shtohen në pyetjet kryesore që marrin në mënyrë dinamike të dhëna. Sa herë që përdoruesi akseson disa të dhëna të bazës së informacionit që kanë një kufizim, programi do të kryejë një kontroll duke ekzekutuar një pyetje.
Pavarësisht nga një pengesë kaq e rëndësishme, mekanizmi RLS është mjaft i përshtatshëm dhe fleksibël. Me të, ju mund të konfiguroni sistemin në mënyrë që asnjë përdorues të mos shohë asgjë "ekstra". Kufizimi i aksesit të punonjësve tuaj, veçanërisht nëse ka shumë prej tyre, është shumë produktiv. Çështja nuk është aq shumë te mosbesimi, por te mbrojtja nga gabimet e rastësishme dhe faktori njerëzor. Sa më pak të dhëna të disponueshme, aq më e lehtë është të punosh me to dhe të mos "ngatërrohesh".
Në një nga artikujt tanë, ne kemi prekur tashmë pjesërisht temën e kufizimit të aksesit në nivelin rekord. Në këtë rast, do të merret parasysh personalizimi më i thelluar nga zhvilluesi.
Konfigurimi i kufizimit të hyrjes në nivel të regjistrimit
Radari është konfiguruar dhe zhvilluar në konfiguruesin 1C. Për ta bërë këtë, së pari krijoni një rol në degën e meta të dhënave.
Në skedën Modelet e kufizimit, mund të krijoni një ose më shumë nga këto shabllone. Nga pamja e jashtme, ato praktikisht nuk ndryshojnë nga kërkesat e zakonshme.
Më pas, shkoni te skeda "Lejet" e rolit për të cilin dëshironi të vendosni një kufizim. Për lehtësi, mund të përdorni ndërtuesin e pyetjeve, i cili ka vetëm dy skeda "Tabelat dhe fushat" dhe "Kushtet".
Siç mund ta shihni në imazhin më poshtë, ne shtuam vetëm një kufizim me tekst:
WHEREItemGroup = &Grupi Artikuj
Si rezultat, kur përdoruesi akseson librin e referencës "Nomenklatura", programi do të shtojë një rresht me këtë kusht në të gjitha pyetjet.
Të gjitha cilësimet e të drejtave të përdoruesit që do të bëjmë në kuadrin e këtij neni ndodhen në seksionin 1C 8.3 "Administrimi" - "Cilësimet e përdoruesit dhe të drejtave". Ky algoritëm është i ngjashëm në shumicën e konfigurimeve në format e menaxhuara. Programi i Kontabilitetit 1C do të përdoret si shembull, por vendosja e të drejtave në programe të tjera (1C UT 11, 1C ZUP 3, 1C ERP) bëhet saktësisht në të njëjtën mënyrë.
Le të shkojmë te seksioni "Përdoruesit" të dritares së cilësimeve. Këtu shohim dy hiperlidhje: "Përdoruesit" dhe "Cilësimet e hyrjes". E para prej tyre ju lejon të shkoni direkt në listën e përdoruesve të kësaj infobaze. Para se të krijoni një përdorues të ri, merrni parasysh cilësimet e mundshme të hyrjes (hiperlidhja në të djathtë).
Në këtë formular të cilësimeve, mund të vendosni kompleksitetin e fjalëkalimit (të paktën 7 karaktere, përmbajtje të detyrueshme të llojeve të ndryshme të karaktereve, etj.). Këtu mund të specifikoni gjithashtu gjatësinë e fjalëkalimit, periudhën e vlefshmërisë së tij dhe ndalimin e aksesit në program për përdoruesit që nuk kanë pasur aktivitet për një periudhë të caktuar kohore.
Tani mund të shkoni drejtpërdrejt në shtimin e një përdoruesi të ri në 1C. Ju mund ta bëni këtë duke klikuar butonin "Krijo", siç tregohet në imazhin më poshtë.
Para së gjithash, ne tregojmë emrin e plotë - "Antonov Dmitry Petrovich" dhe zgjedhim një individ nga drejtoria përkatëse. Këtu mund të specifikoni gjithashtu departamentin në të cilin punon punonjësi ynë.
Emri i hyrjes "AntonovDP" u zëvendësua automatikisht si një shkurtim për emrin e plotë "Antonov Dmitry Petrovich". Vendosni një fjalëkalim dhe vërtetim për 1C Enterprise. Këtu mund të specifikoni gjithashtu nëse ky përdorues lejohet të ndryshojë vetë fjalëkalimin.
Supozoni se duam që Dmitry Petrovich Antonov të jetë i disponueshëm në listën e përzgjedhjes kur të hapet kjo infobazë. Për ta bërë këtë, duhet të vendosni flamurin në artikullin "Shfaq në listën e përzgjedhjes". Si rezultat, dritarja e autorizimit gjatë nisjes së programit do të duket si ajo e paraqitur në figurën më poshtë.
Le t'i kushtojmë vëmendje një cilësime tjetër të rëndësishme në kartën e udhëzuesit të përdoruesit - "Hyrja në program lejohet". Nëse vonesa nuk është vendosur, atëherë përdoruesi thjesht nuk do të jetë në gjendje të hyjë në këtë infobazë.
Të drejtat e aksesit
Pasi të plotësojmë të gjitha të dhënat në kartën e përdoruesit - Antonov Dmitry Petrovich, ne do t'i shkruajmë ato dhe do të vazhdojmë me vendosjen e të drejtave të hyrjes, siç tregohet në figurën më poshtë.
Para nesh hapëm një listë të profileve të hyrjes në program të futura më parë. Kontrolloni kutitë që kërkohen.
Hyni në profilet e grupit
Profilet e grupit të aksesit mund të konfigurohen nga forma kryesore për konfigurimin e përdoruesve dhe të drejtave. Shkoni te seksioni "Access Groups" dhe klikoni në lidhjen "Access Group Profiles".
Le të krijojmë një grup të ri nga forma e hapur e listës. Në seksionin tabelor në skedën "Veprimet (rolet) të lejuara", është e nevojshme të kontrolloni kutitë për ato role që do të ndikojnë në të drejtat e aksesit të përdoruesve të përfshirë në grupin që po krijojmë. Të gjitha këto role krijohen dhe konfigurohen në konfigurues. Ato nuk mund të modifikohen ose krijohen nga modaliteti i përdoruesit. Ju mund të zgjidhni vetëm nga një listë ekzistuese.
RLS: Kufizimi i hyrjes në nivel të regjistrimit
Ju lejon të konfiguroni në mënyrë më fleksibël aksesin në të dhënat e programit në seksione të caktuara. Për ta aktivizuar, vendosni flamurin në artikullin me të njëjtin emër në formularin e cilësimeve të përdoruesit dhe të drejtave.
Ju lutemi vini re se aktivizimi i këtij cilësimi mund të ndikojë negativisht në performancën e sistemit. Çështja është se mekanizmi RLS ndryshon të gjitha kërkesat në varësi të kufizimeve të vendosura.
Le të shkojmë te profili i grupit të aksesit "Test group" që krijuam më parë. Figura më poshtë tregon se pas aktivizimit të kufizimit të aksesit në nivelin e regjistrimit, u shfaq një skedë shtesë "Kufizimet e hyrjes".
Supozoni se duam që përdoruesit të cilëve u është caktuar grupi i testimit të kenë akses në të dhënat për të gjitha organizatat në këtë bazë informacioni, përveç atyre të specifikuara në profil.
Në pjesën e sipërme të tabelës, vendosni kufizimin e aksesit sipas organizatës. Në pjesën e poshtme do të sqarojmë se nuk do të ofrohet akses në të dhëna (dokumente, direktori etj.) për organizatën Roga LLC.
RLS- kjo është aftësia e zhvilluesit për të vendosur një kusht në tabelat e bazës së të dhënave për përdorues të caktuar (grupe përdoruesish) dhe për t'i parandaluar ata të shohin shumë. Gjendja është e tipit Boolean. Nëse vlera e kushtit është e vërtetë, atëherë qasja jepet, përndryshe refuzohet.
RLS përdoret në të njëjtën kohë me vendosjen e lejeve normale. Prandaj, përpara se të filloni të konfiguroni RLS, duhet të shpërndani të drejtat e zakonshme për objektet e konfigurimit.
RLS zbatohet për llojet e mëposhtme të të drejtave të aksesit:
- Leximi
- Shtojca
- Ndryshimi
- Heqja
Si të vendosni RLS
Le të shohim një shembull të thjeshtë konfigurimi. Pamjet e ekranit janë marrë në versionin 1C Enterprise 8.2 (8.2.9.356). Sintaksa e shablloneve të tekstit të kufizimeve përshkruhet në dokumentacionin për 8.2 në librin "Udhëzuesi i Zhvilluesit. Pjesa 1”, ndaj nuk do të ndalemi më në të.
Pra, hapi i parë është përcaktimi i shablloneve të kufizimit për secilin rol ekzistues.
Pas kësaj, bazuar në shabllonet e specifikuara, vendosen kufizime për objektet e nevojshme. Për të modifikuar tekstin e kushtit, mund të përdorni Ndërtuesin e kufizimit të aksesit të të dhënave.
Për të modifikuar role të shumta, është e përshtatshme të menaxhoni përmes dritares "Të gjitha rolet".
Ju mund të përdorni dritaren Kufizimet e të gjithë aksesit për të kopjuar kushtet në role të tjera. Modelet në role të tjera mund të kopjohen vetëm me dorë.
Kjo eshte e gjitha. Ju mund të kontrolloni rezultatin.
Disavantazhet e përdorimit të RLS:
- Përdorimi i mekanizmit të kufizimit të hyrjes në nivel të regjistrimit çon në një rritje të nënkuptuar të tabelave të përfshira në pyetje, gjë që mund të çojë në gabime në modalitetin klient-server të bazës së të dhënave.
- Për kontrollin e shkrimit, mund të jetë e vështirë ose e pamundur të zbatohet logjika komplekse e aplikimit. Në raste të tilla, është më mirë të përdoren kushtet në procedurën OnWrite().
- Shkrimi i një kushti (kërkese) kërkon një kualifikim të caktuar të zhvilluesit.
- Vështirësi shtesë mund të krijohen nga pamundësia e korrigjimit të gjendjes (kërkesës).
Në konfigurimet tipike, të drejtat në nivel rekord mund të vendosen në mënyrë interaktive për objektet e mëposhtme: organizatat, kontraktorët, artikujt e aksioneve, magazinat, divizionet, individët, aplikacionet e kandidatëve dhe të tjerë.
Duhet mbajtur mend se kufizimet e të drejtave të hyrjes në nivelin e regjistrimit janë një mekanizëm mjaft intensiv i burimeve dhe sa më komplekse të vendosni kufizime, aq më ngadalë do të funksionojë programi, veçanërisht me një bazë të dhënash të madhe.
