Käyttämällä "Sallittu"-direktiiviä. Ohjelmoijan muistikirja Parametrit pääsyrajoitusmalleissa

1C 8 -kyselykieli on 1C-ohjelmoijalle välttämätön työkalu, jonka avulla voit kirjoittaa tiiviimpää, yksinkertaisempaa, ymmärrettävää koodia ja käyttää vähemmän järjestelmäresursseja työskennellessäsi tietojen kanssa. Tämä artikkeli avaa sarjan oppitunteja, jotka on omistettu 1C 8 -kyselykielelle. Ensimmäisellä oppitunnilla tarkastellaan tämän kielen pääoperaattorin rakennetta. VALITA. Tällä operaattorilla voit luoda valintoja tietokantataulukoista. Valitut taulukkotiedot voidaan lajitella, asettaa niihin ehtoja, linkittää ja yhdistää muiden taulukoiden tietoihin, ryhmitellä eri kenttien mukaan ja paljon muuta.

Kyselykieli 1C yritys 8 - Operaattorin rakenne SELECT

Katsotaanpa SELECT-operaattorin rakennetta (operaattorin valinnaiset osat on merkitty hakasulkeissa). 1C-kyselykieli tarjoaa laajan valikoiman työkaluja tietonäytteiden luomiseen.

SELECT [ALOWED] [DIFFERENT] [FIRST A] [Field1] [AS Alias1], [Field2] [AS Alias2], ... [FieldM] [AS AliasB] [PUT TemporaryTableName] [FROM Table1 AS AliasTableTable1 [[SISÄINEN JOIN] ][LEFT JOIN][FULL JOIN] Taulukko 2 AS Alias Taulukko 2 [[SISÄLIITTYMÄ][VASEN LIITTYMINEN][FULL JOIN] TableC AS Alias TablesC BY Lauseke1 [Ja lauseke2]...[Ja lausekeD]] .. . ... BY Lauseke1 [Ja lauseke2]...[Ja lausekeE]] ... [TableF AS TableF Alias] ... ] [GROUP BY GroupingField1[,] ... [GroupingFieldG]] [WHERE Lauseke1 [JA Lauseke2] ... [JA LausekeH]] [YHDISTÄ KAIKKI...] [; ...] [INDEKSI Alias1 ... AliasB] [YHTEENSÄ [AggregationFunction(Field1)][,] [AggregationFunction(Field2)][,] ... [AggregationFunction(FieldI)] [YLEISTÄ][,] [ GroupingField1][,] ... [GroupingFieldj]]

Avainsanat ja lohkot kenttien käsittelyyn

VALITA— avainsana, joka ilmaisee operaattorin alun;
SALLITTU — osoittaa, että valinnan tulee sisältää taulukkotietueita, joilla on lukuoikeus tietylle käyttäjälle;
ERI — ilmaisee, että otoksen tulee sisältää vain erilaisia (kaikilla kentillä) virtoja. Toisin sanoen päällekkäiset rivit jätetään pois otoksesta;
ENSIN A — jos määrität tämän avainsanan, vain ensimmäinen A kyselyn valitsemista riveistä sisällytetään valintaan, jossa A on luonnollinen luku;
Kenttälohko— tämä lohko osoittaa kentät, jotka on sisällytettävä valintaan. Nämä kentät ovat valittuja sarakkeita. Yksinkertaisimmassa tapauksessa kenttä näyttää tältä: Taulukon alias.TableFieldName AS Kentän alias
Tällä tavalla ilmaisemme, mistä taulukosta otamme tämän kentän. 1C-kyselykielen avulla voit määrittää aliaksia, mutta niitä ei tule toistaa samassa SELECT-käskyssä. Kenttä voi olla monimutkaisempi, ja se koostuu erilaisista taulukkokenttien, kyselykielifunktioiden ja aggregaattifunktioiden yhdistelmistä, mutta emme käsittele näitä tapauksia tässä opetusohjelmassa.

Avainsanat ja lohkot taulukoiden kanssa työskentelyyn

PUT TemporaryTableName- avainsana PAIKKA on tarkoitettu luomaan tietynniminen väliaikainen taulukko, joka tallennetaan RAM-muistiin tietyssä 1C 8 -istunnossa, kunnes se päättyy tai kunnes väliaikainen taulukko tuhoutuu. On huomattava, että väliaikaisten taulukoiden nimiä yhdessä 1C 8 istunnossa ei pitäisi toistaa;
Taulukot ja suhteet— lohko ilmoittaa kaikki tässä kyselyssä käytetyt taulukot sekä niiden väliset suhteet. Lohko alkaa avainsanalla FROM, ja sen jälkeen ensimmäisen taulukon nimi ja alias. Jos tämä taulukko liittyy muihin taulukoihin, suhteet ilmoitetaan. 1C-kyselykieli sisältää seuraavat yhteystyypit:
- SISÄLIITTYMINEN— vasemmanpuoleisen taulukon tietue sisällytetään valintaan vain, jos yhteysehto täyttyy, oikeanpuoleisen taulukon tietue sisällytetään valintaan vain, jos yhteysehto täyttyy;
- VASEN YHTEYS— vasemmanpuoleisen taulukon tietue sisällytetään joka tapauksessa valintaan, oikeanpuoleisen taulukon tietue vain, jos yhteysehto täyttyy;
- TÄYDELLINEN YHTEYS— vasemmanpuoleisen taulukon tietue tulee joka tapauksessa ensin mukaan valintaan, sitten vasta, jos yhteysehto täyttyy, oikeanpuoleisen taulukon tietue tulee joka tapauksessa ensin mukaan valintaan, sitten vasta jos yhteysehto on tavattu. Tässä tapauksessa tuloksena olevat kaksoisrivit jätetään pois otoksesta.
Yhteystyypin jälkeen ilmoitetaan toisen taulukon nimi ja alias. Seuraavaksi tulee avainsana BY, jota seuraavat loogisten operaattoreiden toisiinsa yhdistämät viestintäolosuhteet JA TAI. Jokaisen ehdon lausekkeen on palautettava Boolen arvo (tosi, epätosi). Jos ensimmäinen taulukko on yhdistetty johonkin muuhun kuin toiseen taulukkoon, yhteystyyppi ilmoitetaan jälleen ja niin edelleen. Jokainen yhteyteen osallistuvista taulukoista vuorostaan voidaan liittää muihin taulukoihin, tämä näkyy kyselyn rakennekaaviossa. Jos taulukko ei liity ensimmäiseen, se ilmoitetaan ilman yhteystyyppiä, sen yhteydet voivat seurata ja niin edelleen;

Avainsanat ja datan muunnoslohkot

Ryhmittelylohko— tätä lohkoa käytetään taulukon rivien ryhmittelyyn. Rivit yhdistetään yhdeksi, jos avainsanan jälkeen määritettyjen kenttien arvot on määritetty GROUP BY osoittautua samaksi. Tässä tapauksessa kaikki muut kentät lasketaan yhteen, lasketaan keskiarvo, maksimoidaan tai minimoidaan koontifunktioiden avulla. Aggregaattifunktioita käytetään kenttälohkossa. Esimerkki: Maksimi(TaulukkoAlias.Taulukon kentänNimi) AS KenttäAlias
Kuntoblokki- tässä lohkossa avainsanan jälkeen MISSÄ loogisilla operaattoreilla erotetut ehdolliset lausekkeet on merkitty JA TAI, jotta mikä tahansa valituista riveistä voidaan sisällyttää otokseen, kaikilla koosteen ehdoilla on oltava arvo Totta.
YHDISTÄ KAIKKI— tätä avainsanaa käytetään kyselyjen yhdistämiseen (operaattorit VALITA). 1C-kyselykielen avulla voit yhdistää useita kyselyjä yhdeksi. Jotta kyselyt voidaan yhdistää, niillä on oltava sama kenttäjoukko.
«;» — puolipisteitä käytetään erottamaan toisistaan riippumattomat lausunnot VALITA;
HAKEMISTO— avainsanaa käytetään sen jälkeen määritettyjen kenttien indeksointiin;
Yhteenvetolohko— käytetään puumaisten näytteiden rakentamiseen. Jokaiselle avainsanan jälkeen määritetylle ryhmittelykentälle BY, valintaan luodaan erillinen rivi. Tällä rivillä lasketaan koontifunktioiden avulla avainsanan jälkeen määritettyjen kenttien kokonaisarvot TULOKSET.

Haluatko jatkaa 1C 8 -kyselykielen oppimista? Lue sitten seuraava artikkeli.

Kysely on tehokas työkalu, jonka avulla voidaan nopeasti (kaikkiin muihin menetelmiin verrattuna) hankkia ja käsitellä 1C-tietokannan eri kohteissa olevia tietoja.

Luo pyyntö

Pyyntö luodaan erillisenä objektina, jolla on vaadittu attribuutti Teksti, johon itse pyyntö todella on tehty. Lisäksi pyyntöön voidaan välittää erilaisia sen suorittamiseen tarvittavia parametreja. Kun pyynnön teksti ja parametrit on täytetty, pyyntö on suoritettava ja suorituksen tulos sijoitettava valintaan tai arvotaulukkoon. Kaikki näyttää jotakuinkin tältä:

//Luo pyyntö
Pyyntö = uusi pyyntö;

//Täytä pyyntöteksti
Pyyntö. Teksti = "Tähän kirjoitamme pyynnön tekstin";

//Siirrä parametrit pyyntöön
Pyyntö. SetParameter("ParametrinNimi" , Parametriarvo) ;

//Suorita pyyntö
Tulos = Kysely. Juosta() ;

//Lataa kyselyn tulos valintaan
Näyte = Tulos. Valitse() ;

//Lataa kyselyn tulos arvotaulukkoon
Taulukko = Tulos. Unload() ;

//Viimeiset toiminnot voidaan yhdistää
Hae = Kysely. Juosta() . Valitse() ;
//tai
Taulukko = Kysely. Juosta() . Unload() ;

1C-kyselykielen perusteet

Yksinkertaisimpia ja yleisimmin käytettyjä kyselyitä käytetään tiedon hankkimiseen jostain lähteestä. Lähde voi olla melkein kaikki objektit, jotka sisältävät mitä tahansa tietoa: hakemistoja, dokumentteja, rekistereitä, vakioita, luetteloita, ominaisuustyyppien suunnitelmia jne.

Näistä objekteista saat kyselyn avulla arvot yksityiskohdista, taulukon osista, taulukon osien yksityiskohdista, muutoksista, resursseista jne.

Pyyntöteksti on usein kätevä käyttää Pyydä rakentaja. Sitä kutsutaan, kun napsautat hiiren kakkospainikkeella mitä tahansa ohjelmamoduulin kohtaa.

Jos esimerkiksi haluat saada kaikkien hakemistotietojen arvot Vastapuolet, pyyntö näyttää tältä:

Pyyntö. Teksti = "VALITA
| *
|FROM
| Vastapuolet";

Jos haluat saada vain yksittäisiä tietoja, toimi näin:

Vastaanottaaksesi tällaisen pyynnön tekstiviestillä Kyselyn rakentaja sinun on valittava välilehdellä sopivat kentät Pöydät ja kentät.

Voit määrittää kyselyssä valituille elementeille ja lähteille aliaksia ja käyttää niitä myöhemmin sekä itse kyselyssä että tuloksen kanssa työskennellessä. Lisäksi pyyntö voi sisältää kenttiä, joissa on ennalta määritetty tietty arvo tai laskettu arvo:

Pyyntö. Teksti = "VALITA
| Clients.Code AS-numero,

| 1000 AS kenttäArvolla
|FROM
;

Hae = Kysely. Juosta() . Valitse() ;

Hei valinta. Seuraava() Silmukka
ClientNumber = Näyte. Määrä;
ClientName = Valinta. Nimi;
Arvo = näyte. FieldWithValue;
EndCycle ;

Käytä välilehteä asettaaksesi aliaksia Liitot/aliakset V Kyselyn rakentaja.

Välilehteen luodaan manuaalisesti kenttä, jossa on kiinteä tai laskettu arvo Pöydät ja kentät, kolumnissa Kentät.

Kaikki valitut elementit voidaan järjestää joko eteen- tai taaksepäin. Voit valita yhden tai useamman kentän tilausta varten. Järjestämisen lisäksi voi joskus olla hyödyllistä valita vain yksi tai muutama ensimmäisistä kohteista.

Voit rajoittaa kohteiden valinnan niihin, joihin käyttäjällä on käyttöoikeudet. Tai poista päällekkäiset rivit kyselyn tuloksesta.

Järjestys asetetaan välilehdellä Tilaus V Kyselyn rakentaja Valittujen elementtien määrä, resoluutio ja toistettavuusparametrit ovat välilehdellä Lisäksi.

Jatkuu…

"Rooli"-määritysobjekti antaa joukon oikeuksia toimintoihin (toimintoihin) konfigurointiobjektien päällä.

Rooli "Täydet oikeudet".

Tämä on vain rooli (ei ennalta määritetty), jossa kaikki oikeudet kaikkiin konfiguraatioobjekteihin tarkistetaan.

Se, mikä erottaa sen muista rooleista, on "hallinnointi"-oikeus.

Jos vähintään yksi käyttäjä on luotu, järjestelmä alkaa tarkistaa "Hallinta"-oikeuden olemassaoloa - vähintään yhdellä käyttäjällä on oltava se.

Tietuetason pääsyrajoitukset

Rivitason suojaus (RLS) – ennätystason rajoitus.

Tietojen käyttörajoitusmekanismin avulla voit hallita käyttöoikeuksia paitsi metatieto-objektien tasolla myös tietokantaobjektien tasolla. Seuraavia objekteja voidaan käyttää rajoittamaan pääsyä tietoihin:

roolit,
istunnon parametrit,
toiminnallisia vaihtoehtoja,
etuoikeutetut jaetut moduulit,
avainsana SALLITTU kyselykielellä.

Mekanismi on suunniteltu rajoittamaan pääsyä metatieto-objektien taulukkotietueisiin mielivaltaisten ehtojen perusteella, jotka on asetettu näiden taulukoiden rivikenttien arvoille. Esimerkiksi, jos haluat nähdä vain "oma" vastapuolesi, organisaatiosi jne.

Pääsyrajoitusten tekninen toteutus 1C:ssä

1C luo pyynnön DBMS:lle. Palvelinklusteri lisää pyyntöön WHERE-osion, joka sisältää RLS:n kautta pääsyn rajoittamisen ehdon tekstin, sitten tämä pyyntö lähetetään DBMS:lle, puretut tiedot palautetaan 1C-asiakkaalle.

Tämä mekanismi toimii kaikissa asiakkaan pyynnöstä:

raporteissa,
dynaamisissa listoissa ja tavallisissa luettelomuodoissa
mukautetuissa kyselyissä.

Tällainen mekanismin toteutus vaikuttaa suuresti suorituskykyyn.

Tapoja ohittaa pääsyrajoitukset.

Suurissa resurssiintensiivisissä toimissa (esimerkiksi dokumenttien uudelleenpostittamisen käsittelyssä) osa koodista voidaan siirtää etuoikeutettuihin moduuleihin.

A) Etuoikeutettu moduuli on yleinen moduuli, jonka ominaisuuksissa on "Etuoikeutettu"-lippu.

Sen erikoisuus on, että siinä oleva koodi suoritetaan ilman käyttöoikeuksien valvontaa, mukaan lukien RLS.

B) Myös etuoikeutettu tila voidaan kytkeä päälle asiakirjaobjektimoduuleille. Tämä tehdään asiakirjan ominaisuuksissa, lippu

Etuoikeutettu kohtelu suoritettaessa
Etuoikeutettu tila peruttaessa tapahtumaa

B) Menetelmä SetPrivilegedMode()

System-komennon avulla voit tehdä osan minkä tahansa moduulin koodista etuoikeutetuksi.

Seuraavasta koodirivistä alkaen etuoikeutettu suoritustila toimii.

Se toimii, kunnes rivi poistaa tämän tilan käytöstä tai toimenpiteen/toiminnon loppuun

(Totta);

// mikä tahansa koodi tässä suoritetaan ilman oikeuksien valvontaa ja RLS:ää

AsetaPrivilegedMode(Valehdella ); // tai toimenpiteen / funktion loppu

Etuoikeutetun tilan käyttöönottokertojen lukumäärän on vastattava sitä, kuinka monta kertaa se on poistettu käytöstä. Jos etuoikeutettu tila otettiin käyttöön toimenpiteen tai toiminnon aikana, mutta sitä ei sammutettu, järjestelmä sammuu automaattisesti niin monta kertaa kuin toimenpiteessä tai toiminnossa oli keskeneräisiä käynnistyksiä.

Jos proseduurissa tai funktiossa kutsuu menetelmää AsetaPrivilegedMode(False) teki enemmän kuin menetelmäkutsuja AsetaPrivilegedMode(Totta), silloin tehdään poikkeus

Toiminto PrivilegedMode() palauttaa True, jos etuoikeutettu tila on edelleen käytössä, ja False, jos se on kokonaan poistettu käytöstä. Tämä ei analysoi tietyn toiminnon etuoikeutettujen tilan asetusten määrää.

Kaikki kutsutut proseduurit ja toiminnot suoritetaan myös etuoikeutetussa tilassa.

On myös mahdollista aloittaa etuoikeutettu istunto. Tämä on istunto, jossa etuoikeutettu tila on perustettu järjestelmän alusta alkaen. Lisäksi käytön aikana menetelmä PrivilegedMode() palauttaa aina True, eikä etuoikeutetun tilan poistamista tueta. Vain käyttäjä, jolla on järjestelmänvalvojan oikeudet (järjestelmänvalvojan oikeudet), voi aloittaa etuoikeutetun istunnon. Istunto voidaan käynnistää asiakassovelluksen käynnistyksen komentorivikytkimellä UsePrivilegedMode tai infobase-yhteysmerkkijonoparametrilla prmod.

Herää luonnollisesti kysymys: Miksi sitten ylipäätään asetetaan pääsyrajoituksia, jos ne voidaan niin helposti ohittaa?

Turva tila.

Kyllä, voit kirjoittaa ulkoista käsittelyä etuoikeutetulla suoritusmuodolla ja purkaa/korruptoituneita tietoja. Tämän estämiseksi järjestelmässä on globaali kontekstimenetelmä

AsetaSafeMode().

Vikasietotila ohittaa muun muassa etuoikeutetun tilan.

Se on asennettava ennen ulkoisten prosessorien ohjelmallista kutsumista tai toimintojen ja toimintojen vientiä niiden moduuleista.

Kiellettyjä toimintoja suoritettaessa tehdään poikkeus ajon aikana.

Lisäksi rooliasetustasolla voit poistaa käytöstä käyttäjien mahdollisuuden käynnistää vuorovaikutteisesti ulkoisia raportteja ja käsittelyä.

Pääsyrajoitusten määrittäminen

RLS voidaan määrittää vain seuraaville oikeuksille:

lue (valitse)
lisääminen (lisää)
muuttaa (päivitys)
poistaa

Lukutoimintoihin ja poistaminen, tietokannassa sijaitsevan objektin on noudatettava tietojen käyttörajoituksia.

Lisäystoimintoa varten Tietojen käyttörajoituksen tulee vastata objektia, joka on suunniteltu kirjoitettavaksi tietokantaan.

Muutostoimintaan tietojen käyttörajoituksen on oltava objektin mukainen sekä ennen muutosta (jotta objekti luetaan) että muutoksen jälkeen (jotta objekti kirjoitetaan).

Kaikille muille oikeuksille tällaista vaihtoehtoa ei ole.

Lisätään uusi rajoitus "Nimikkeistö"-hakemiston "luku"-oikeuteen. Näkyviin tulee luettelo kentistä, joille voit määrittää lisätyn rajoituksen.

Tämä tarkoittaa, että jos yrität käyttää valittuja kenttiä, rajoitus laukeaa, mutta jos yrität käyttää tarkistamattomia kenttiä, rajoitus ei laukea.

Jos valitset lipun " Muut kentät", rajoitus määritetään kaikille taulukon kenttiin, paitsi kenttiin, joille on erikseen asetettu rajoituksia.

*Ominaisuus: lisä-, muutos-, poisto-oikeudet:

Rajoitus voidaan määrittää vain kaikille kentälle.

Rajoituksia voi olla vain yksi.

"Lue"-oikealle voit määrittää useita ehtoja, jotka yhdistetään loogiseen operaattoriin "AND".

Päärajoitustietoobjektin kaikkia kenttiä ei saa käyttää seuraavan tyyppisten tietokantaobjektien rajoituksissa:

akkumulaatiorekistereissä pääsyrajoitukset voivat sisältää vain rajoituksen pääobjektin mittauksia;
kirjanpitorekistereissä rajoituksissa voidaan käyttää vain rajoituksen pääkohteen tasemittauksia

Jos kiertokertymärekisterin tietoihin rajoitetun pääsyn olosuhteissa käytetään mittauksia, jotka eivät sisälly summiin, niin virtuaaliseen kierrostaulukkoon päästään tallennettuja summia ei käytetä ja pyyntö suoritetaan kokonaan liikepöytä.

Pääsyrajoitusten asettamismekanismi.

Mikä tahansa 1C:Enterprisen tietokantaan tallennettujen tietojen käsittely johtaa lopulta kutsuun tietokantaan, jossa pyydetään tietojen lukemista tai muuttamista. Suorittaessaan kyselyitä tietokantaan 1C:Enterprisen sisäiset mekanismit asettavat pääsyrajoituksia. Jossa:

Luettelo oikeuksista luodaan(lue, lisää, muokkaa, poista), luettelo tietokantataulukoista ja luettelo tämän kyselyn käyttämistä kentistä.
Kaikista nykyisen käyttäjän rooleista pääsyrajoitukset on valittu kaikkien pyyntöön liittyvien oikeuksien, taulukoiden ja kenttien tietoihin. Lisäksi, jos rooli ei sisällä rajoituksia pääsylle taulukon tai kentän tietoihin, tämä tarkoittaa, että vaadittujen kenttien arvot mistä tahansa tietueesta ovat saatavilla tässä taulukossa. Toisin sanoen tietoihin pääsyä koskevan rajoituksen puuttuminen tarkoittaa rajoituksen olemassaoloa MISSÄ ON TOSI.
Hakee kaikkien istuntoparametrien ja toiminnallisten asetusten nykyiset arvot osallistumalla valittuihin rajoituksiin.

Istuntoparametrin tai ominaisuuden arvon saamiseksi nykyisellä käyttäjällä ei tarvitse olla lupaa saada kyseistä arvoa. Jos jonkin istuntoparametrin arvoa ei kuitenkaan ole asetettu, tapahtuu virhe eikä tietokantakyselyä suoriteta.

Yhdestä roolista johdetut rajoitukset yhdistetään AND-operaatiolla.

Eri rooleista johdetut rajoitukset yhdistetään OR-operaatiolla.

Rakennetut ehdot lisätään SQL-kyselyihin, joilla 1C: Enterprise käyttää DBMS:ää. Käytettäessä tietoja pääsyrajoitusehdoista, oikeuksien tarkistusta ei suoriteta (ei metatieto-objekteille eikä tietokantaobjekteille). Lisäksi ehtojen lisäämismekanismi riippuu rajoitusten "kaikki" tai "sallittu" valitusta toimintatavasta.

*Ominaisuus: Jos käyttäjällä on pääsy useisiin rooleihin määritetyillä rajoituksilla yhdelle objektille tietuetasolla, niin tässä tapauksessa rajoitusten ehdot lisätään loogisella operaatiolla "OR". Toisin sanoen käyttäjän tehot ovat kumulatiivisia.

Tämä johtaa seuraavaan johtopäätökseen: älä anna ehtojen rajoittaa pääsyä yhteen kohteeseen eri rooleissa leikkaamaan, koska tässä tapauksessa pyynnön teksti on erittäin monimutkainen ja tämä vaikuttaa suorituskykyyn.

"Kaikki" -menetelmä.

Kun rajoituksia asetetaan "kaikki"-menetelmällä, SQL-kyselyihin lisätään ehtoja ja kenttiä, jotta 1C:Enterprise voi saada tietoa siitä, käytettiinkö tietokantakyselyn suorittamisen aikana tietylle käyttäjälle kiellettyjä tietoja vai ei. Jos kiellettyjä tietoja käytettiin, pyyntö kaatuu pääsyrikkomuksen vuoksi.

Pääsyrajoitusten asettaminen "kaikki"-menetelmällä on esitetty kaavamaisesti kuvassa:

"Sallittu" menetelmä.

Käytettäessä rajoituksia "sallitulla" menetelmällä SQL-kyselyihin lisätään ehtoja, jotta nykyiselle käyttäjälle kielletyt tietueet eivät vaikuta kyselyn tulokseen. Toisin sanoen, kun rajoituksia asetetaan "sallitussa"-tilassa, tietylle käyttäjälle kiellettyjä tietueita pidetään puuttuvina, eivätkä ne vaikuta toimenpiteen tulokseen, joka on esitetty kaavamaisesti kuvassa:

Tietokantaobjekteille asetetaan tietojen käyttörajoituksia, kun 1C:Enterprise käyttää tietokantaa.

1C:Enterprisen asiakaspalvelinversiossa rajoituksia sovelletaan 1C:Enterprise-palvelimeen.

Tämä vaihtoehto (ALOWED) ei kuitenkaan toimi, jos kyselyssä viitataan taulukkoon, jolle ei ole määritetty pääsyrajoituksia, mutta joka sisältää viittauksia taulukon riveihin, joissa on määritetty rajoituksia. Tässä tapauksessa kyselyn tulos näyttää "<Объект не найден>......" viitekentän arvon sijaan.

Jos kehität raporttia tai käsittelet tavallisia tai mukautettuja määrityskyselyitä, tarkista aina "Sallittu"-merkki jotta raportti toimisi kenen tahansa käyttäjän alla millä tahansa oikeuksilla.

Tietokannan tietojen objektiluettaessa ei ole mahdollista asettaa "Allowed" -lippua. Siksi se on välttämätöntä määrittää valinnat objektin lukemista varten ottaen huomioon mahdolliset käyttöoikeusrajoitukset käyttäjälle. Objektitekniikassa ei ole keinoja saada vain sallittuja tietoja.

On tärkeää, että jos kyselyssä ei määritetä ALLOWED-avainsanaa, kaikki kyseisessä kyselyssä määritetyt valinnat eivät saa olla ristiriidassa kyselyssä käytettyjen tietokantaobjektien lukurajoitusten kanssa. Lisäksi jos kyselyssä käytetään virtuaalisia taulukoita, vastaavat valinnat tulee soveltaa itse virtuaalitaulukoihin.

Harjoitus 1. Kyselynmuodostin RLS-asetuksissa.

Muodostetaan kyselyn WHERE-osion teksti hakemistoon. Voit käyttää kyselyn rakennustyökalua.
Suunnittelijalla on riisuttu ulkonäkö.

"Taulukot" -välilehti

Päätaulukko on sen objektin taulukko, jolle rajoitus määritetään.

Voit myös valita muita taulukoita ja määrittää niiden välille erilaisia yhteyksiä "Suhteet"-välilehdellä.

Välilehti "Ehdot"

Täällä voit määrittää todelliset pääsynrajoitusehdot

Lisätään ehtoja nimikkeistöhakemiston "Price"-attribuutille taulukon kaikkien kenttien "lukemisoikeudesta".

"Nimikkeistö WHERE Nomenclature.Price > 500"

Katsotaanpa, kuinka tämä yksinkertainen sääntö toimii. Hakemistotaulukko sisältää seuraavat elementit:

Käyttörajoituksen määrittämisen jälkeen taulukko näyttää vain elementit, jotka täyttävät ehdon:

Myös ryhmät katosivat. Muutetaan rajoituksen tekstiä

"Nimikkeistö WHERE Nimikkeistö. Hinta > 500

TAI Nimikkeistö. Tämä on ryhmä"

No, nyt sitä tarvitset.

Jos poistat "koodi"-kentän näyttämisen lista-asetuksista, kaikki hakemiston elementit tulevat näkyviin, ts. rajoitus ei toiminut. Jos asetat "Koodi"-kentän näkyviin, rajoitus toimii.

Tässä tapauksessa huolimatta siitä, että hakemistoelementti on näkyvissä luettelokentässä, sen muotoa ei voida avata, koska attribuutille on määritetty rajoitus. Sama tapahtuu mielivaltaisessa pyynnössä: kun yrität saada "rajoitetun" ominaisuuden, tapahtuu pääsyvirhe.

Jos yrität saada "rajoitetut" tunnistetiedot ohjelmallisesti, myös pääsyvirhe heitetään.

Lisäksi linkin kautta ei pääse mihinkään objektin kenttiin, koska linkin vastaanottaessaan järjestelmä lukee koko objektin ja jos se sisältää "rajoitettuja" yksityiskohtia, objektia ei lueta.

Siksi, kun työskentelet ohjelmallisesti tietokantaobjektien kanssa, sinun on pidettävä mielessä mahdolliset tietuetason rajoitukset ja hankittava kaikki tarvittavat objektitiedot pyynnöstä ja asetettava ne sitten rakenteeseen tai suoritettava osa koodista etuoikeutetussa moduulissa.

Pääsyrajoituksen asettamisen jälkeen rivin näyttö oikeusluettelossa muuttui - se muuttui harmaaksi ja kuvake ilmestyi.

Rajoitukset pääsyn määrittämiseen (RLS).

Yhteenveto-osiota ei ole;
Virtuaalirekisteritaulukoita ei voi käyttää;
Et voi käyttää parametreja eksplisiittisesti;
Voidaan käyttää sisäkkäisissä kyselyissä any>/span> kyselykielityökalut paitsi:
- operaattori HIERARKIASSA;
- TULOKSET ehdotukset;
- sisäkkäiset kyselytulokset ei saa sisältää pöydän osia>/span>;
- virtuaalisia pöytiä, erityisesti saldot ja liikevaihdot

Harjoitus 2. Nimikkeistö nykyhinnalla.

Rajoita pääsyä, jos haluat näyttää kohteita, joiden nykyinen hinta on korkeampi kuin tietty arvo, esimerkiksi 100.

Ratkaisu:

Lisäämme uuden pääsynrajoitussäännön "Nimikkeistö"-hakemistoon "luku"-oikeudella.
Valitse "muut kentät".
Konstruktorissa lisäämme sisäkkäisen kyselyn. Valitse siinä tietorekisteritaulukko ”Tuotehinnat”.
"Tilaa"-välilehteä ei ole - tämä on kyselyn suunnittelijan ominaisuus pääsyrajoituspyynnön muodostamiseen.
Aseta "Lisäasetukset"-välilehdellä "first 999999999", "tilaus"-välilehti tulee näkyviin.
Järjestämme "Kausi"-kentän mukaan laskevassa järjestyksessä.
Sitten luomme yhteyden päätaulukon ja alikyselyn välille viittauksella.

Pääsyrajoitusmallit.

Käytäntö 3. Rajoitus "vastapuolille" vakion arvolla.

Asetetaan pääsyrajoitus Vastapuolet-hakemistoon vakioon tallennetun arvon perusteella.

Lisäksi sinun on asetettava rajoitus kaikille objekteille, jotka käyttävät "Vastapuolet"-hakemistoa tiedoissa.

Ratkaisu

"Vastapuolet"-hakemistossa asetamme rajoituksen "luku"-oikeudelle lisäämällä sisäkkäisen kyselyn "Ehdot"-osion vakioon. Älä unohda, että tämä on ryhmä.

Näemme ongelman, Counterparties-hakemisto on suodatettu oikein ja kaikki asiakirjat, joissa on "Counterparty"-attribuutti, näytetään, joistakin "vastapuoli"-attribuutissa on "rikkinäisiä" linkkejä.

Nyt sinun on määritettävä pääsyrajoitukset kaikille objekteille, jotka käyttävät linkkiä "Tilit". Etsitään ne "hae linkkejä kohteeseen" -palvelun avulla.

Kopioidaan ja muokataan hieman RLS-ehdon tekstiä "Vastapuolet" -hakemistosta. Tämä on tehtävä niin monta kertaa kuin esineitä löytyy.

Tai käytä pääsyrajoitusmallia koodin päällekkäisyyksien välttämiseksi.

Pääsyrajoitusmallit määritetään roolitasolla, ja niitä voidaan käyttää missä tahansa muokatun roolin objektissa.

Voit lisätä malliin minkä tahansa käyttörajoituksen tekstin. Mallia kutsutaan "#"-symbolilla. Esimerkiksi #TemplateCounterparty.

1C:n # kautta ohjeet kirjoitetaan esiprosessorille. Käyttörajoitusasetusten suorittamisen yhteydessä alusta korvaa mallin kutsutekstin mallitekstillä.

Lisätään sanan WHERE jälkeen oleva teksti "Contractor Template" -malliin, paitsi EtoGroupia koskeva teksti.

Parametrit pääsyrajoitusmalleissa.

Jatketaan ongelman 2 ratkaisemista.

Ongelmana on nyt se, että hakemiston päätaulukkoa kutsutaan "vastapuoliksi", dokumentissa "Kuittilasku". Hakemistossa tarkistettava kenttä on nimeltään "linkki", asiakirjassa sitä kutsutaan nimellä "vastapuoli".

Muutetaan päätaulukon nimi mallitekstissä muotoon #CurrentTable

"#CurrentTable" on ennalta määritetty parametri.

Ja pisteen kautta osoitamme syöttöparametrin numeron - ".#Parameter(1)

"#Parametri" on myös ennalta määritetty arvo. Voi sisältää mielivaltaisen määrän syöttöparametreja. Ne on osoitettu sarjanumerolla.

Hakemiston pääsyrajoitusten tekstissä ilmoitamme seuraavaa:

Asiakirjalle seuraavaa:

"Tavaroiden myynti, MISSÄ #TemplateCounterparty ("vastapuoli")"

Pääsyrajoitusmallia kutsuttaessa parametrit on välitettävä sille vain merkkijonona, eli lainausmerkeissä.

Päätaulukko - Nimikkeistö

Mallin teksti on:

#NykyinenTable WHERE #NykyinenTaulukko.#Parametri(1) = #Parametri(2)

Malliteksti sisältää osan tekstiä tietojen käyttörajoituskielellä ja voi sisältää parametreja, jotka on korostettu #-symbolilla.

"#"-symbolia voi seurata:

Yksi avainsanoista:
- Parametri, jota seuraa mallissa olevan parametrin numero suluissa;
- CurrentTable – ilmaisee sen taulukon koko nimen lisäämisen tekstiin, jolle rajoitusta rakennetaan;
- Nykyinen TaulukonNimi– merkitsee sen taulukon koko nimen lisäämistä tekstiin (merkkijonoarvona lainausmerkeissä), johon käskyä sovelletaan, sisäänrakennetun kielen nykyisessä versiossa;
- NameCurrentAccessRight– sisältää sen oikeuden nimen, jolle nykyinen rajoitus suoritetaan: LUE, LISÄÄ, LISÄÄ, MUUTA, PÄIVITYS, POISTA;
malliparametrin nimi – tarkoittaa vastaavan malliparametrin rajoitteen lisäämistä tekstiin;
symboli "#" - osoittaa yhden merkin "#" lisäämisen tekstiin.

Pääsyrajoituslauseke voi sisältää:

Pääsyrajoitusmalli, joka on määritetty muodossa #TemplateName("Mallin parametrin arvo 1", "Mallin parametrin arvo 2",...). Jokainen mallin parametri on lainausmerkkien sisällä. Jos sinun on määritettävä kaksoislainausmerkki parametritekstiin, sinun on käytettävä kahta lainausmerkkiä.
Funktio StrContains (WhereWeLook, WhatWeLook). Funktio on suunniteltu etsimään WhatWeLook-merkkijono esiintymää WhereWeLook-merkkijonosta. Palauttaa True, jos tapahtuma löytyy, ja False muussa tapauksessa.
+-operaattori on merkkijonojen yhdistämiseen.

Mallin tekstin muokkaamisen helpottamiseksi napsauta roolilomakkeen Rajoitusmallit-välilehdellä Aseta malliteksti -painiketta. Kirjoita avautuvaan valintaikkunaan mallin teksti ja napsauta OK.

Niitä ei voi asentaa käyttämällä SetParameter() tai jotain vastaavaa.

Parametrit tässä tapauksessa ovat:

Istunnon asetukset
Toiminnalliset vaihtoehdot

Istuntoparametrien lukeminen pääsyrajoituspyynnössä tapahtuu etuoikeutetussa tilassa, toisin sanoen ilman, että valvotaan oikeuksia toimia niiden kanssa.

Käytäntö 4. Pääsy "oma" vastapuoliin

On tarpeen määrittää nykyisen käyttäjän pääsy "heidän" vastapuolilleen.

Siellä on hakemisto "Käyttäjät", hakemisto "Vastapuolet", asiakirjat, joissa on tiedot "vastapuoli".

Nykyisen käyttäjän pitäisi nähdä tiedot vain niistä vastapuolista, joille on muodostettu yhteys hänen kanssaan.

Myös viestintä on konfiguroitava.

Mahdolliset vaihtoehdot:

Yhteyden muodostaminen käyttäjän ja vastapuolen välille

Yksityiskohdat vastapuoliluettelossa
Tietojen rekisteri

Mahdollisia ratkaisuja ongelmaan:

Käyttäjän tallentaminen vakioon on huono vaihtoehto. Vakio on kaikkien käyttäjien käytettävissä.
Nykyisen käyttäjän vastapuolten kiinteän joukon tallentaminen istuntoparametreihin ei ole kovin hyvä vaihtoehto, vastapuolia voi olla useita
Nykyisen käyttäjän istuntoparametrien tallentaminen ja sitten luettelon pyytäminen "hänen" vastapuolista on hyväksyttävä vaihtoehto.
Muita vaihtoehtoja.

Ratkaisu.

Luodaan uusi istuntoparametri "CurrentUser" ja täytä se istuntomoduuliin.

Luodaan tietorekisteri "Johtajien ja urakoitsijoiden vaatimustenmukaisuus"

Luodaan uusi rooli ja siihen uusi pääsyrajoitus dokumentille “Lasku”.

Pyynnön tekstissä yhdistämme päätaulukon tietorekisteriin Tili = Tili ja Esimies = &NykyinenKäyttäjä. Yhteystyyppi Sisäinen.

Jos mahdollista, on parempi välttää sisäkkäisiä kyselyitä pääsyrajoitusteksteissä, koska se suoritetaan aina, kun tästä objektista luetaan tietoja tietokannasta.

Tarkistetaan - rajoitukset toimivat

*Ominaisuus: Jos muutat käyttäjien vastapuoliluetteloa rekisterissä, pääsyrajoitukset astuvat voimaan välittömästi ilman käyttäjäistunnon uudelleenkäynnistystä.

Käytäntö 5. Muutoskiellon päivämäärä.

Tietojen muokkaamista koskeva rajoitus on tarpeen toteuttaa ennen asetettua muutoskieltopäivää.
Sinun on rajoitettava sitä käyttäjille.

Luodaan tietorekisteri ”Muutoskieltopäivät” dimensiolla Käyttäjä, resurssi Kieltopäivämäärä.

Rakennetaan ratkaisun logiikka näin:

Jos käyttäjää ei ole määritetty, kielto koskee kaikkia käyttäjiä
jos rajoitus koskee kaikkia käyttäjiä ja tiettyä käyttäjää, rajoitus koskee tiettyä käyttäjää ja muita yleisen periaatteen mukaisesti.

Ilmeisesti tällainen rajoitus voidaan määrittää tietokantaobjekteille, joilla on jokin asema aika-akselilla. Se voi olla

Dokumentointi
Säännölliset tietorekisterit

Luodaan uusi rooli "Rajoitukset muutoskiellon päivämäärän mukaan".

Siihen "Lasku" -asiakirjaan oikean "muutoksen" osalta lisäämme uuden pääsyrajoituksen.

Määritämme asetukset kaikille kentälle.

Rajoituksen teksti on:

ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice

Muuta kieltopäivämäärää AS Kieltopäivä
FROM

SISÄLIITTYMÄ (VALITSE
MAX(Muuta kiellettyjä päivämääriä.Käyttäjä) AS-käyttäjä
FROM
Tietojen rekisteri Muutoskieltopäivät AS Muutoskiellon päivämäärät
MISSÄ
(Muuta kiellettyjä päivämääriä.User = &nykyinen käyttäjä
TAI Päivämäärät Kielletyt muutokset.Käyttäjä = VALUE(Directory.users.EmptyLink))) AS VZ_User
Muutoskiellon päivämäärän mukaan.Käyttäjä = VZ_Käyttäjä.Käyttäjä) AS NestedQuery
Ohjelmistokuittaus Lasku.Päiväys > Sisäkkäinen Query.Ban Date

Tarkastetaan - rajoitus toimii.

Esikäsittelyohjeiden käyttäminen

#Jos ehto1 #Sitten

Pyynnön fragmentti 1

#ElseIf-ehto2 #Sitten

Pyynnön fragmentti 2

#Muuten

Pyynnön fragmentti 3

#Loppu Jos

Ehdoissa voit käyttää loogisia operaatioita (ja. tai, ei jne.) ja pääsyä istuntoparametreihin.

Tämä lähestymistapa pääsyrajoitusten rakentamisen yhteydessä on kätevä, koska ehdoista riippuen kootaan lyhyempi pyyntöteksti. Yksinkertaisempi kysely kuormittaa järjestelmää vähemmän.

Huono puoli on, että kyselyn rakentaja ei toimi tällaisen tekstin kanssa.

* Erikoisuus:

Toisin kuin sisäänrakennetun kielen esiprosessorille annetut ohjeet pääsyrajoitusteksteissä, ennen operaattoria Sitten sinun on laitettava hash - #Sitten

Harjoitus 6. Vaihda "Käytä RLS"

Täydennetään rajoitusjärjestelmäämme kytkimellä, joka kytkee rajoitusten käytön päälle/pois ennätystasolla.

Voit tehdä tämän lisäämällä vakion ja istunnon parametrin nimeltä "UseRLS".

Kirjoitetaan Session Module asettaaksesi istuntoparametrin arvo vakion arvosta.

Lisätään seuraava koodi kaikkiin pääsyrajoitusteksteihin:

"#Jos &UseRLS #Sitten….. #EndIf"

Tarkistamme - kaikki toimii.

Nyt kun "käytä tutkaa" -lippu on kytketty päälle, muutokset eivät kuitenkaan tule heti voimaan. Miksi?

Koska istuntoparametri asetetaan istunnon alkaessa.

On mahdollista asettaa istuntoparametrin arvo nollattavaksi, kun uusi vakioarvo kirjoitetaan, mutta tämä toimii vain nykyisessä käyttäjäistunnossa. Muita käyttäjiä tulee kehottaa käynnistämään järjestelmä uudelleen.

Ensimmäisen osan loppu.

20.09.2014

Kyselykielessä on "Sallittu"-käsky. Se on suunniteltu antamaan alustalle mahdollisuus suodattaa pois tietueet, joihin käyttäjällä ei ole oikeuksia, kun se asettaa rajoituksia tietokantatietueen tasolla.

Vaikuttaa siltä, että on parempi käyttää aina tätä direktiiviä kyselyissä. Väitän, että näin ei ole. Väitän myös, että jos mahdollista, sinun tulisi välttää sen käyttöä, tässä miksi.

Oletetaan, että teemme selvityksen yksityishenkilöiden keskinäisistä selvityksistä. Käyttäjällä on oikeudet yhteen organisaatioon, tietokannassa on useampi kuin yksi organisaatio ja tietokannassa on käytössä tietuetason rajoitukset. Tietokannassa on myös rekisteri "Keskinäiset selvitykset", joiden mitat ovat "Organisaatio" ja "Yksihenkilö". Jos järjestelmässä on pyyntö

"Valita

Organisaatio,

Yksilöllinen

ja se suoritetaan sellaisen käyttäjän puolesta, jolla on käyttöoikeus yhteen organisaatioon, niin pyyntöä ei suoriteta, jos tässä rekisterissä on tietueita muista organisaatioista. Tapahtuu virhe ja virheen kuvaus on "Käyttäjällä ei ole riittäviä oikeuksia pyynnön suorittamiseen!" ja tämä on totta, alusta ei huijaa, koska sillä ei ole oikeuksia muiden tässä rekisterissä olevien organisaatioiden tietueisiin.

Mitä tehdä tässä tapauksessa, käyttää "Sallittu" -direktiiviä? Minun mielestäni se ei ole sen arvoista. Sinun tarvitsee vain määrittää valinta organisaatioittain, ja käyttäjä voi luoda raportin. Tietojen koostumuksen sisältävän raportin kysely näyttää tältä

"Valita

Organisaatio,

Yksilöllinen

(Valita

Organisaatio

Yksilöllinen)

Kertymärekisteristä

(Missä

Organisaatio

Yksilöllinen)

Jos käyttäjä suorittaa kyselyn taulukossa ilman valintaa, raporttia ei luoda, eikä käyttäjä tunnista muiden organisaatioiden tietoja, mutta jos hän valitsee organisaatiolleen, se generoidaan oikeilla tiedoilla.

Voit kysyä uudelleen: "Miksi sinun ei pitäisi käyttää sallittua direktiiviä?" Tämä pakottaa välittömästi valinnan ja suojaa käyttäjää tarpeettomilta viesteiltä!

Vastaus tähän kysymykseen on seuraava: kuinka tässä tapauksessa käyttäjä tietää, että kaikki tarvittavat tiedot sisältyvät raporttiin. Oletetaan, että aiemmin tämä käyttäjä työskenteli täydellä oikeudella ja teki virheen ja valitsi asiakirjasta henkilön toisesta organisaatiosta. Saattaa myös olla tilanne, jossa tiedot on ladattu - ja toisen organisaation jaosto kirjattiin organisaation asiakirjoihin (ZUP:ssa niitä koskevat myös omistajan rajoitukset). Tässä tapauksessa "Sallittu"-direktiivi katkaisee kiellettyjä tietoja ilman viestejä käyttäjälle, eikä hän tiedä, ettei kaikkea, mitä raporttiin pitäisi sisällyttää.

Siksi sinun ei pitäisi sisällyttää tätä direktiiviä umpimähkäisesti vakiokokoonpanopyyntöihin, koska tämä on virhe. Tätä ei suositella säännellyissä raportointipyynnöissä. Älä myöskään tee tätä muissa raporteissa ja asiakirjoissa, joissa vaaditaan tietojen tarkkuutta.

Mutta kuinka voit välttää ohjelman kaatumisen, jos sinulla ei ole tarpeeksi oikeuksia?

Kyllä, se on hyvin yksinkertaista, sinun on käytettävä "Try" -komentoa, tässä on esimerkki:

Yrittää

Request.Run();

Poikkeus

Raportti(ErrorDescription());

EndAttempt;

Kulunvalvontajärjestelmiä käyttävissä raporteissa raportin suorittamisen ohjelmakoodi tulee kirjoittaa manuaalisesti, myös yrittämällä.

Tämän seurauksena käyttäjä ei saa vääriä tietoja ja saa kohtuullisen virheilmoituksen.

Voit tutustua RLS:n asettamisen vivahteisiin erillisissä osastoissa artikkelissamme.