"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ä metatietoobjektien taulukkotietueisiin mielivaltaisten ehtojen perusteella, jotka on asetettu näiden taulukoiden rivikenttien arvoille. Esimerkiksi, jos haluat nähdä vain "omien" vastapuolien, organisaatioiden jne. tiedot.

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,
• V dynaamiset luettelot ja sisään tavallisia muotoja luetteloita
• 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. Voit aloittaa istunnon näppäimellä komentorivi käynnistämällä asiakassovelluksen UsePrivilegedMode tai infobase-yhteysmerkkijonoparametrin 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 asetettava ennen ohjelmakutsua ulkoiset hoidot tai viedä menettelyjä ja toimintoja moduuleistaan.

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 kohde 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äyttöön tulee luettelo kentistä, joille voit määrittää lisätyn rajoituksen.

Tämä tarkoittaa, että jos yrität käyttää merkittyjä kenttiä, rajoitus laukeaa, mutta jos yrität käyttää valitsemattomia kenttiä, rajoitus ei toimi.

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

*Ominaisuus: oikeudet lisätä, muuttaa, poistaa:

• Rajoitus voidaan määrittää vain kaikille kentälle.
• Rajoitus 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 rakentamiseen.
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 tekstistä 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;
  • CurrentTableName– 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ä.
• Kiinteän taulukon tallentaminen nykyisen käyttäjän vastapuolista 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ääriä Kieltopäivä AS Kieltopäivä
FROM

SISÄLIITTYMINEN (VALITSE
MAX(Muuta kiellettyjä päivämääriä.Käyttäjä) AS-käyttäjä
FROM
Tietorekisteri Muutoskiellon päivämäärät AS Muutoskiellon päivämäärät
MISSÄ
(Muuta kiellettyjä päivämääriä.Käyttäjä = &NykyinenKä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

Olosuhteissa sitä voidaan käyttää loogisia operaatioita(ja. tai, ei jne.) ja pääsyn istunnon parametreihin.

Tämä lähestymistapa pääsyrajoitusten rakentamisen yhteydessä on kätevä siinä mielessä, että 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.

Tätä varten lisäämme vakion ja istuntoparametrin nimeltä "UseRLS".

Kirjoitetaan Session Module asettaaksesi istuntoparametrin arvo vakion arvosta.

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

"#Jos &KÄYTTÄJÄ #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.

Käyttöoikeuden määrittäminen hakemiston syöttötasolla.

Tämä asetus sisällytettiin kokoonpanoon ei niin kauan sitten, mielestäni asetus on erittäin hyödyllinen.

Tämä asetus on tarpeen niille, joiden on rajoitettava pääsyä hakemistoon tämän hakemiston elementeillä. Esimerkiksi johtajan täytyy nähdä vain asiakkaat sekä raportit ja asiakirjalokit vain niiden vastapuolten osalta, joihin hänellä on pääsy, ja kirjanpitäjällä on oltava täysi pääsy kaikkiin hakemiston elementteihin, esimerkiksi "Vastapuolet. ”

Ehdotan, että harkitaan esimerkkiä käyttäen esimerkkiä pehmokäynnistimen kokoonpanosta.

1. Päällä tässä vaiheessa on tarpeen määritellä joukko käyttäjäryhmiä.

Järjestelmänvalvojat;

Myyntipäälliköt;

Ostopäälliköt;

1. Toisessa vaiheessa määritetään pääsyryhmät hakemistoon.

Ostajat;

Toimittajat;

Tyypillisesti edellä kuvatuista ryhmäluetteloista keskustellaan johdon kanssa ja vasta sen jälkeen kirjataan ohjelmaan.

Nyt on tarpeen kuvata todelliset asetukset, jotka on suoritettava 1C: ssä.

1. Otetaan käyttöön "Rajoitettu pääsy tietuetasolla". Palvelu - käyttäjien ja käyttöoikeuksien hallinta - Pääsyparametrit tietuetasolla. Katso kuva 1.

Käsittelylomake "Pääsyparametrit tietuetasolla" avautuu, katso kuva. 2.

Tällä lomakkeella sinun on itse asiassa otettava käyttöön rajoitus, josta vastaa "Rajoita pääsyä tietuetasolla objektityypin mukaan" -lippu ja valittava ne hakemistot, joita rajoitus koskee. Tässä artikkelissa käsitellään vain "vastapuolet" -hakemistoa.

1. Seuraavaksi tarvitsemme niitä käyttäjä- ja vastapuoliryhmiä, jotka määriteltiin artikkelin alussa.

Urakoitsijaryhmät syötetään "Käyttäjäryhmät" -hakemistoon, katso kuva. 3.

Hakemistoelementin "Käyttäjäryhmät" muoto avautuu, katso kuva. 4.

Ikkunan vasemmalla puolella näkyy pääsyobjekti (meille nämä ovat "vastapuolia"), oikealla ovat käyttäjät, jotka ovat ryhmän jäseniä, tässä esimerkissä Nämä ovat "järjestelmänvalvojia".

Sinun on suoritettava jokaiselle määrittämällesi käyttäjäryhmälle tämä asetus, ei pitäisi olla enää yhtä käyttäjää, joka ei ole ryhmän jäsen.

1. Kolmannessa vaiheessa sinun on syötettävä "vastapuolten pääsyryhmät", josta vastaa hakemisto "Vastapuolien pääsyryhmät". Katso kuva 5.

Esimerkiksi nämä ovat: Ostajat, Toimittajat, Muut. Katso kuva. 6.

1. Tässä vaiheessa sinun on määritettävä käyttöoikeusryhmä jokaiselle "vastapuolten" hakemiston elementille. Katso kuva. 7.

Vastapuolen käyttöoikeusryhmä on määritetty "Muu"-välilehdellä. Käytän yleensä apustandardia tietojen kohdistamiseen ryhmiin. "Hakemistojen ja asiakirjojen ryhmäkäsittely" mahdollistaa massaasennuksen haluttu ryhmä tälle rekvisiitille.

1. Tämä vaihe on kulminaatiovaihe. Tässä vaiheessa konfiguroidaan "käyttäjäryhmien" pääsy "vastapuolten käyttöoikeusryhmiin"; tämä konfiguroidaan käyttämällä "Käyttöoikeuksien asettaminen tietuetasolla" -käsittelyä, katso kuva. 8.

Käyttäjäryhmien suhde vastapuolten käyttöoikeusryhmiin on korostettu punaisella. "Ostopäällikkö"- ja "Myyntipäällikkö"-ryhmissä suhteet konfiguroidaan täsmälleen samalla tavalla, vain käyttöoikeusobjektit määritetään sellaisina kuin ne, joihin heillä pitäisi olla pääsy, esimerkiksi vain "Toimittajat" tai vain "Ostajat". Liput, esimerkiksi "Näkyvyys luettelossa" ovat "Pääsy-objektin" oikeudet. Nimen perusteella mielestäni näiden oikeuksien toimivuus on selvä.

Yllä mainittujen manipulointien jälkeen sinulla pitäisi olla rajoitettu pääsy "Vastapuolet" -hakemistoon.

Muut hakemistot on määritetty samalla tavalla.

Tärkeä:

Rajoitettu pääsy ei koske roolia "Täydet oikeudet";

Käyttäjäroolien joukossa on oltava "Käyttäjä"-rooli;

Jos sinulla on omat roolisi, sinun on lisättävä rooliisi malleja ja rajoituksia kuten "Käyttäjä"-roolissa suhteessa "Vastapuolet"-hakemistoon (katso koodi Käyttäjäroolissa napsauttamalla vastapuolihakemistoa).

1C:Enterprise 8 -alustalla on sisäänrakennettu mekanismi tietojen pääsyn rajoittamiseksi tietueella. Voit lukea yleistä tietoa aiheesta täältä. Lyhyesti sanottuna RLS antaa sinun rajoittaa pääsyä tietoihin tiettyjen kenttäarvojen ehtojen perusteella. Voit esimerkiksi rajoittaa käyttäjien pääsyä asiakirjoihin Organisaatio-attribuutin arvon mukaan. Jotkut käyttäjät käsittelevät "Management Company" -organisaation asiakirjoja ja toiset "Dairy Plant" -organisaation kanssa. Esimerkiksi.

Valmistautuminen

Toteutamme esimerkin SCP 1.3:n demokonfiguraatiossa. Luodaan käyttäjä "Storekeeper" ja lisätään hänelle samanniminen "Storekeeper" rooli.

Jatketaan nyt suoraan käyttöoikeuksien määrittämiseen tietueella. Siirrytään "Käyttäjän hallinta" -käyttöliittymään. Valitse päävalikosta "Tietotason käyttöoikeus -> Asetukset". Valitse tässä "Rajoita pääsyä tietuetasolla objektityypin mukaan" -kohdan vieressä oleva ruutu ja valitse objektiluettelosta "Organisaatiot".

Näin ollen sallimme RLS:n käytön. Nyt sinun on määritettävä se.

Tietuetason pääsynhallintaa ei ole määritetty erikseen kullekin käyttäjälle tai käyttöoikeusprofiilille. RLS on määritetty käyttäjäryhmille. Lisätään uusi ryhmä käyttäjille, kutsutaan sitä "kauppiaiksi"

Ryhmän kokoonpano lomakkeen oikealla puolella näyttää luettelon tähän ryhmään kuuluvista käyttäjistä. Lisätään luetteloon aiemmin luomamme käyttäjä. Vasemmalla on taulukko pääsyrajoituksista. RLS:ää määrittäessämme valitsimme, että pääsyä rajoittaa vain organisaatio, joten näemme vain yhden tyyppisen käyttöoikeusobjektin. Napsauta "Pääsyasetukset" -painiketta. Nykyisen ryhmän käyttöoikeuksien asetusten käsittely avautuu.

Lisätään organisaatio "IPE "Entrepreneur" ryhmän käyttöoikeusobjektien luetteloon. Oikeuksien perinnön tyyppi säilyy ennallaan. Asetamme käyttöoikeusobjektille oikeuden lukea ja kirjoittaa. Napsauta "OK", asetukset ovat valmiit. Olemme juuri määrittäneet RLS:n organisaatiotasolla.

Mitä käyttäjä näkee

Käynnistetään ohjelma aiemmin luodun käyttäjän alla ja avataan "Organisaatiot"-hakemisto. Tältä luettelo näyttää käyttäjällemme ja käyttäjälle, jolla on täydet oikeudet:

Kuten näemme, varastonpitäjän käyttäjä näkee vain yhden organisaation, jolle olemme myöntäneet lukuoikeudet. Sama koskee asiakirjoja, esimerkiksi tavaroiden ja palveluiden vastaanottoa.

Siten käyttäjä ei vain näe organisaatioita, joille ei ole asetettu pääsyä hänelle, vaan hän ei myöskään voi lukea/kirjoittaa asiakirjoja ja muita objekteja tietokannassa, joille on asetettu oikeudet "Organisaatio" -roolissa. attribuutti.

Tarkastelimme yksinkertaisinta esimerkkiä RLS:n määrittämisestä. Seuraavassa artikkelissa puhumme RLS-mekanismin toteutuksesta "Manufacturing Enterprise Management" -konfiguraatioversiossa 1.3.

Jokainen johtaja hyväksyy ehdoitta, että jokaisella yrityksen työntekijällä on pääsy vain niihin tietoihin, jotka kuuluvat hänen toimivaltaansa. Esimerkiksi varastonpitäjän ei välttämättä tarvitse nähdä, mitä toimintoja talousjohtaja tai pääkirjanpitäjä tekee. Usein syntyy kuitenkin melko hienovaraisia ​​tilanteita, esimerkiksi kun 1C: Enterprise 8 -ohjelmaa ei käytetä yhdelle, vaan useammalle yritykselle. Jokaisella heistä on omat työntekijänsä, joilla on oltava pääsy vain valtuutettuihin yritykseensä liittyviin tietoihin.

Tässä tapauksessa tekniikka on ihanteellinen avustaja tarvittavien käyttöoikeuksien tarjoamisessa. Ennätystason suojaus(RLS), jonka avulla voit tarjota pääsyn tietuetason tietoihin.

Katsotaanpa esimerkkiä tietystä tilanteesta. Yrityksemme koostuu kahdesta organisaatiosta. Ensimmäinen harjoittaa myyntiä ohjelmisto, toisessa - koulutus sen kanssa työskentelemiseen. Molempien organisaatioiden huomioon ottamiseksi käytämme 1C-ohjelmistotuotetta: Integrated Automation 8.

Tehtävämme on eriyttää kahden organisaation työntekijöiden tiedonsaantioikeudet siten, että samat oikeudet omaavat työntekijät näkevät vain sen, mikä liittyy organisaatioon, jossa he työskentelevät.

Ensimmäinen asia, joka tulee mieleen tätä ongelmaa esitettäessä, on valintojen määrittäminen organisaatioille. Tällä ratkaisulla on kuitenkin kaksi merkittävää haittaa:

• valintoja on mukautettava kaikissa ohjelman muodoissa;
• Enemmän tai vähemmän taitavalle käyttäjälle ei ole mitään ongelmaa poistaa ne käytöstä.

Varmin tapa on rajoittaa käyttäjien pääsyä tietuetasolla. Miten tämä toteutetaan?

Ensimmäinen asia, joka sinun on tehtävä, on sallia ohjelman käyttää tätä menetelmää. Tätä varten tarvitset:

Meidän tapauksessamme on välttämätöntä rajoittaa pääsyä organisaatioittain, mutta on selvää, että ohjelma tarjoaa paljon laajemmat mahdollisuudet. Rajoita esimerkiksi pääsyä hakemistoihin ja asiakirjoihin.

Samanlainen mekanismi on toteutettu muissa 1C-sovellusratkaisuissa:

• (versio 10.3)
• ja 1C: Palkat ja henkilöstöhallinto 8 (tarkistus 2.5).

Näissä ohjelmissa käyttöoikeudet erotellaan "Käyttäjäryhmät"-hakemiston avulla, johon pääsee "Työkalut"-valikon kohdasta "Käyttäjän käyttöoikeuksien määrittäminen".

• Näissä ohjelmissa meidän on siis jaettava kaikki yrityksen osana toimivat käyttäjämme ryhmiin organisaatioittain.
• Napsauta sitten "Pääsyasetukset" -painiketta.
• Napsauta näkyviin tulevassa ikkunassa "Lisää" -painiketta ja kirjoita käyttöoikeusobjekti (tilanteemme mukaan tämä on organisaatio).
• Jos meidän on sallittava organisaation työntekijöiden syöttää tietoja tietokantaan, meidän on valittava "Record" -sarakkeen valintaruutu.

Nämä vaiheet on suoritettava jokaisen organisaation osalta. Tämän jälkeen jokainen työntekijä näkee ohjelmaan tullessaan vain ne asiakirjat, jotka määräytyvät hänen käyttöoikeuksiensa perusteella ja jotka liittyvät hänen organisaatioonsa.

Klassinen ongelma: antaa käyttäjälle pääsyn esineeseen, mutta ei kaikkiin elementteihin/asiakirjoihin, vaan vain joihinkin.

Esimerkiksi, jotta johtaja näkee vain asiakkaidensa raportit.

Tai se voi olla rajoitus "kaikki paitsi jotkut".
Tai rajoitus ei koske hakuteoksia/asiakirjoja, vaan rekisteröidä tietoja…

Esimerkiksi, jotta käyttäjät eivät voi poimia tietoja kumppaneille suoritetuista maksuista millä tahansa raportilla.

Pohjimmiltaan tämä on hienovarainen ja erittäin joustava asetus "mitä tämä käyttäjä näkee ja mitä hänen ei tarvitse arvata".

Miksi RLS?

Useimmat toteutukset vaativat eri käyttäjien asettamaan tietokannan tietoihin eri käyttöoikeustasot.

Konfiguraatioissa erityiset metatieto-objektit - roolit - vastaavat mahdollisista pääsyoikeuksista dataan. Jokainen käyttäjä tietokanta yksi tai useampi rooli on määritetty. Ne määrittävät, ovatko tietyt metatieto-objektit mahdollisia (lukeminen, kirjoittaminen, lähettäminen jne.).

Mutta siinä ei vielä kaikki.

Se on usein tarpeen ei vain avaa/estä pääsyä tiettyyn objektiin, vaan rajoita pääsyä osaan sen sisältämistä tiedoista.

Tätä ongelmaa ei voida ratkaista pelkillä rooleilla.– tätä tarkoitusta varten on otettu käyttöön mekanismi pääsyn rajoittamiseksi tietuetasolla (RLS).

Rajoitukset edustavat ehtoja, joissa dataan kohdistuva toiminto (luku, kirjoittaminen jne.) sallitaan. – Näin voit rajoittaa pääsyä ei koko objektiin, vaan vain osaan sen tiedoista.

Tietoja RLS:stä - tarkemmin: 8 videota ja PDF

Koska tämä on yleinen 1C-hallintatehtävä, suosittelemme tarkastelemaan yksityiskohtaisempia materiaaleja:

Tietoihin pääsyn rajoittaminen rooleilla

Tässä videossa kerrotaan, kuinka tietojen käyttöä rajoitetaan rooleilla. Selvennetään, että roolit rajoittavat pääsyä tietyntyyppisiin tietokantaobjekteihin (erillinen hakemisto, mutta ei hakemiston tiettyjä elementtejä).

Ennätystason rajoitus (RLS)

Tämä video puhuu tietuetason (RLS) pääsyrajoitusten mekanismista, kun voit määrittää pääsyn ei koko hakemistoon kokonaisuutena, vaan sen yksittäisiin elementteihin tietokantaan tallennettujen tietojen mukaan. Samanlaisia ​​rajoituksia on määrätty rooleissa.

Pääsyrajoitusten toteuttaminen urakoitsijoiden hakemistoon tietueella

Tämä video selittää, kuinka demo-kokoonpano " Hallittu sovellus» määrittää johtajien pääsyn vain omille heille määrätyille vastapuolille.

Kuinka matalan tason tietuetason käyttörajoitukset toimivat

Tämä video selittää, kuinka alusta muuntaa DBMS-palvelimelle lähetetyt kyselyt suoritettavaksi, kun tietuetason käyttörajoituksia on.

Useiden tietuetason käyttörajoitusten soveltaminen yhdessä

Tietokannan käyttäjälle voidaan määrittää useita rooleja. Lisäksi jokaisella roolilla voi olla omat pääsyrajoituksensa tietuetasolla. Tämä video selittää, kuinka järjestelmä käyttäytyy, kun rajoituksia asetetaan.

Rajoitusten asettaminen ALL-menetelmällä

Tämä video kuvaa ensimmäistä tapaa asettaa rajoituksia tietuetasolla - KAIKKI-menetelmää. Tässä tapauksessa, jos valinta sisältää tietueita, joihin pääsy on rajoitettu, näyttöön tulee virheilmoitus.

Rajoitusten asettaminen SALLITTU-menetelmällä

Tämä video kuvaa ensimmäistä tapaa asettaa ennätystason rajoituksia - SALLITTU-menetelmää. Tässä tapauksessa vain ne tietueet, joihin käyttäjällä on käyttöoikeudet, otetaan mukaan valintaan.

Tässä muutamia aiheita kurssilta:

• 1C:Enterprise 8 -alustan asentaminen ja päivittäminen – manuaalinen ja automaattinen, Windowsille ja Linuxille
• Automaattinen käynnistys rutiinitoimintojen suorittamiseen
• Määrityksiä päivitetään käyttäjätilasta
• Ei-standardikokoonpanojen päivittäminen. Kuinka välttää ongelmia päivityksen aikana muokatut vakiokokoonpanot
• Luo omasi toimitus cfu-tiedostot
• BSP työkalut: ulkoiset lomakkeet, asiakirjojen täyttöjen käsittely jne.
• Käyttö ilmainen DBMS PostgreSQL
• Asennus ja käynnistys palvelinklusteri 1C: Yritys 8
• Hallinta-apuohjelma klusterin ja työpalvelimien perustamiseen
• asetukset RLS käyttäen esimerkkiä UPP 1.3 ja ERP 2
• Mitä tehdä, jos tietoturvan tiedot ovat vioittuneet
• asetukset tiedonvaihdot kokoonpanojen välillä
• Organisaatio ryhmän kehittäminen
• Asennus ja käyttö laitteiston suojausavaimet
• 1C ohjelmistolisenssit: asennus ja sitominen ulkoisiin laitteisiin

Joka tapauksessa sinun on jossain vaiheessa otettava käyttöön 1C, määritettävä varaukset, käyttöoikeudet, erilaiset käynnistystilat, testattava tietokantojen eheys, varmistettava palvelimien toiminta jne.

Ja on parempi tehdä se heti.

Jotta sitä ei tapahtuisi myöhemmin "...! No mitä ihmettä...! Sinun...!" - ja muita katumuksen ilmauksia :)