1c rol die toegang tot gegevens beperkt. RLS - flexibel en fine-tuning van datatoegangsbeperkingen. Sjablonen voor toegangsbeperkingen

Het configuratieobject "rol" geeft een set rechten aan bewerkingen (acties) over configuratieobjecten.

Rol "Volledige rechten".

Dit is slechts een rol (niet vooraf gedefinieerd) waarin de selectievakjes voor alle soorten rechten op alle configuratie-objecten zijn aangevinkt.

Het verschil met andere rollen is dat het het recht "Administratie" heeft.

Als er minstens één gebruiker is aangemaakt, begint het systeem te controleren op het recht "Beheer" - minstens één gebruiker moet dit hebben.

Toegang beperken op recordniveau

Rijniveaubeveiliging (RLS) is een beperking op recordniveau.

Met het mechanisme voor beperking van de gegevenstoegang kunt u toegangsrechten niet alleen beheren op het niveau van metadata-objecten, maar ook op het niveau van database-objecten. De volgende objecten kunnen worden gebruikt om de toegang tot gegevens te beperken:

• rollen,
• sessieparameters,
• functionele opties,
• bevoorrechte gedeelde modules,
• het trefwoord TOEGESTAAN in de zoektaal.

Het mechanisme is ontworpen om de toegang tot records van de tabel met metadata-objecten te beperken door willekeurige voorwaarden die worden opgelegd aan de waarden van de velden van de rijen van deze tabellen. Om bijvoorbeeld alleen records te zien van "eigen" tegenpartijen, organisaties, etc.

Technische implementatie van toegangsbeperkingen in 1C

1C genereert een verzoek aan het DBMS. Het servercluster voegt de WHERE-sectie toe aan het verzoek, dat de tekst bevat van de voorwaarde voor het beperken van toegang via RLS, vervolgens wordt dit verzoek verzonden naar het DBMS, de geëxtraheerde gegevens worden teruggestuurd naar de 1C-client.

Dit mechanisme werkt voor elk verzoek van de klant:

• in rapporten,
• in dynamische lijsten en in reguliere lijstvormen
• in willekeurige zoekopdrachten.

Deze implementatie van het mechanisme heeft grote invloed op de prestaties.

Manieren om toegangsbeperkingen te omzeilen.

Bij grote, resource-intensieve bewerkingen (bijvoorbeeld het verwerken van het opnieuw plaatsen van documenten), kan een deel van de code worden verplaatst naar geprivilegieerde modules.

EEN) Bevoorrechte module Is een veel voorkomende module met de vlag "Privileged" in de eigenschappen.

Zijn eigenaardigheid ligt in het feit dat de code erin wordt uitgevoerd zonder enige toegangscontrole, inclusief RLS.

B) Ook: bevoorrecht modus kan worden ingeschakeld voor documentobjectmodules... Dit wordt gedaan in de documenteigenschappen, de vlag

• Bevoorrechte modus bij het uitvoeren van
• Bevoorrechte modus bij annuleren

B) Methode: SetPrivilegedMode ()

Met het systeemcommando kunt u een deel van de code van elke module bevoorrecht maken.

Vanaf de volgende regel code is de bevoorrechte uitvoeringsmodus van kracht.

Het werkt tot de regel voor het uitschakelen van deze modus of tot het einde van de procedure / functie.

(Waarheid);

// elke code hier wordt uitgevoerd zonder rechtencontrole en RLS

Geprivilegieerde modus installeren(Leugen ); // ofwel einde van procedure / functie

Het aantal keren dat de bevoorrechte modus wordt ingeschakeld, moet overeenkomen met het aantal keren dat de modus is uitgeschakeld. Als echter binnen een procedure of functie de geprivilegieerde modus is ingeschakeld (een of meerdere keren), maar niet is uitgeschakeld, wordt het systeem automatisch net zo vaak uitgeschakeld als er in behandeling waren in de procedure of functie die moet worden verlaten .

Als een procedure of functie een methode aanroept Geprivilegieerde modus installeren(False) meer gedaan dan methodeaanroepen Geprivilegieerde modus installeren(Waar) dan wordt er een uitzondering gegenereerd

Functie Bevoorrechte modus() geeft True terug als de bevoorrechte modus nog steeds is ingeschakeld, en False als deze volledig is uitgeschakeld. Dit analyseert niet het aantal instellingen voor geprivilegieerde modus in een bepaalde functie.

Alle aangeroepen procedures en functies worden ook uitgevoerd in de bevoorrechte modus.

Het is ook mogelijk om een ​​bevoorrechte sessie te starten. Dit is een sessie waarin de bevoorrechte modus vanaf het allereerste begin van het systeem wordt ingesteld. Bovendien, tijdens bedrijf, de methode: Bevoorrechte modus() zal altijd True retourneren en de mogelijkheid om de bevoorrechte modus uit te schakelen wordt niet ondersteund. Alleen een gebruiker met beheerdersrechten (Administratierecht) kan een bevoorrechte sessie starten. De sessie kan worden gestart met behulp van de opdrachtregelschakelaar voor het starten van de clienttoepassing UsePrivilegedMode of de parameter van de verbindingsreeks met de prmod-infobase.

De vraag rijst natuurlijk: waarom zou je dan de moeite nemen om toegangsbeperkingen te configureren als het zo gemakkelijk kan worden omzeild?

Veilige modus.

Ja, het is mogelijk om externe verwerking te schrijven met geprivilegieerde uitvoeringsmodus en gegevens te verwijderen / corrupt te maken. Om dit te voorkomen, heeft het systeem een ​​globale contextmethode

Veilige modus instellen().

Veilige modus negeert ook de bevoorrechte modus.

Het moet worden geïnstalleerd voordat programmatisch externe handlers worden aangeroepen of procedures en functies uit hun modules worden geëxporteerd.

Genereert een uitzondering bij het uitvoeren van verboden bewerkingen tijdens runtime.

Daarnaast kunt u voor gebruikers de mogelijkheid uitschakelen om interactief externe rapporten en verwerkingen te starten op het rolconfiguratieniveau.

Toegangsbeperking configureren

RLS kan alleen worden geconfigureerd voor rechten:

• lezen (selecteren)
• toevoegen (invoegen)
• wijzigen (bijwerken)
• verwijderen

Voor leesbewerkingen: en verwijdering, moet het object dat zich in de database bevindt, voldoen aan de beperking van de gegevenstoegang.

Voor bewerking toevoegen: de beperking van de gegevenstoegang moet overeenkomen met het object dat u naar de database wilt schrijven.

Voor wijzigingsbewerking: Het object moet zowel vóór de wijziging (om het object te lezen) als na de wijziging (om het object te schrijven) aan de datatoegangsbeperking voldoen.

Voor alle andere rechten is dit niet mogelijk.

Laten we een nieuwe beperking toevoegen voor het "lees"-recht van het naslagwerk "Nomenclatuur". Er wordt een lijst met velden geopend waarvoor u de toegevoegde beperking kunt configureren.

Dit betekent dat wanneer u toegang probeert te krijgen tot de aangevinkte velden, de beperking zal werken, en wanneer u toegang probeert te krijgen tot niet-aangevinkte velden, zal de beperking niet werken.

Als u de vlag " Andere velden", De beperking wordt geconfigureerd voor alle velden in de tabel, behalve voor de velden waarvoor expliciet beperkingen zijn opgegeven.

* Feature: voor toevoegen, wijzigen, verwijderen rechten:

• De beperking kan alleen voor alle velden worden geconfigureerd.
• Er kan maar één beperking zijn.

Er kunnen verschillende voorwaarden worden geconfigureerd voor het "Lezen"-recht, deze worden gecombineerd met de logische operator "AND".

Bij beperkingen op databaseobjecten van de volgende typen kunnen niet alle velden van het hoofdgegevensobject van de beperking worden gebruikt:

• in accumulatieregisters kunnen toegangsbeperkingen alleen metingen van het hoofdobject van beperkingen bevatten;
• in boekhoudregisters in restricties kunnen alleen balansafmetingen van het hoofdobject van restricties worden gebruikt

Als in de voorwaarden voor het beperken van de toegang tot de gegevens van het omzetregister van accumulatie, dimensies worden gebruikt die niet in de totalen zijn opgenomen, dan worden bij toegang tot de virtuele omzettabel de opgeslagen totalen niet gebruikt en wordt de zoekopdracht volledig uitgevoerd volgens naar de transactietabel.

Het mechanisme voor het opleggen van toegangsbeperkingen.

Elke bewerking op gegevens die zijn opgeslagen in een database in 1C: Enterprise leidt uiteindelijk tot een oproep naar de database met een verzoek om gegevens te lezen of te wijzigen. Tijdens het uitvoeren van query's op de database leggen de interne mechanismen van 1C: Enterprise toegangsbeperkingen op. Waarin:

• Er wordt gewerkt aan een lijst met rechten(lezen, toevoegen, wijzigen, verwijderen), een lijst met databasetabellen en een lijst met velden die door deze query worden gebruikt.
• Van alle rollen van de huidige gebruiker toegangsbeperkingen zijn geselecteerd naar de gegevens voor alle rechten, tabellen en velden die bij de query betrokken zijn. Bovendien, als een rol geen beperkingen bevat voor toegang tot gegevens van een tabel of veld, dan betekent dit dat de waarden van de vereiste velden van elk record beschikbaar zijn in deze tabel. Met andere woorden, de afwezigheid van beperkingen op de toegang tot gegevens betekent dat er een echte beperking is.
• De huidige waarden van alle sessieparameters en functionele opties worden verkregen deelnemen aan de geselecteerde beperkingen.

Om de waarde van een sessieparameter of functionele optie van de huidige gebruiker te verkrijgen, is het niet vereist om het recht te hebben om deze waarde te krijgen. Als de waarde van een sessieparameter echter niet is ingesteld, treedt er een fout op en wordt de databasequery niet uitgevoerd.

Beperkingen die uit één rol zijn verkregen, worden gecombineerd met behulp van de AND-bewerking.

Beperkingen verkregen uit verschillende rollen worden samen ORed.

De geconstrueerde voorwaarden worden toegevoegd aan de SQL-query's waarmee 1C: Enterprise het DBMS adresseert. Bij het benaderen van gegevens vanaf de kant van de toegangsbeperkingsvoorwaarden, wordt er geen rechtencontrole uitgevoerd (noch naar metadata-objecten, noch naar database-objecten). Bovendien hangt het mechanisme voor het toevoegen van voorwaarden af ​​van de gekozen werkwijze van de beperkingen "alle" of "toegestaan".

* Functie: als de gebruiker toegang heeft tot meerdere rollen met geconfigureerde beperkingen op recordniveau voor één object, dan worden in dit geval de voorwaarden van de beperkingen toegevoegd door de logische "OF"-bewerking. Met andere woorden, de bevoegdheden van de gebruiker tellen op.

Dit leidt tot de volgende conclusie: laat de overlap van de toegangsbeperkingsvoorwaarde voor hetzelfde object in verschillende rollen niet toe, omdat in dit geval de vraagtekst zeer gecompliceerd zal zijn en dit de prestaties zal beïnvloeden.

De "Alle"-methode.

Wanneer beperkingen worden opgelegd in de "all"-methode, worden voorwaarden en velden toegevoegd aan SQL-query's zodat 1C: Enterprise informatie kan verkrijgen over of de voor deze gebruiker verboden gegevens zijn gebruikt tijdens het uitvoeren van een databasequery. Als de verboden gegevens zijn gebruikt, wordt een abnormale beëindiging van het verzoek gestart vanwege een toegangsschending.

Het opleggen van toegangsbeperkingen op de "alle" manier wordt schematisch weergegeven in de figuur:

Methode "Toegestaan".

Bij het opleggen van beperkingen op de "toegestane" manier, worden voorwaarden toegevoegd aan SQL-query's zodat de records die door de huidige gebruiker zijn verboden, het queryresultaat niet beïnvloeden. Met andere woorden, wanneer beperkingen worden opgelegd in de "toegestane" modus, worden de records die voor deze gebruiker zijn verboden, als afwezig beschouwd en wordt het bewerkingsresultaat niet beïnvloed, wat schematisch wordt weergegeven in de afbeelding:

Gegevenstoegangsbeperkingen worden opgelegd aan databaseobjecten wanneer 1C: Enterprise toegang heeft tot de database.

In de client-serverversie van 1C: Enterprise worden beperkingen opgelegd aan de 1C: Enterprise-server.

Deze optie (ALLOWED) werkt echter niet als we in de query verwijzen naar een tabel waarvoor geen toegangsbeperkingen zijn geconfigureerd, maar die koppelingen bevat naar tabelrijen met geconfigureerde beperkingen. In dit geval zal het zoekresultaat “<Объект не найден>... ... "in plaats van de waarde van het referentieveld.

Als u een rapport of verwerking ontwikkelt met behulp van typische of zelfgeschreven configuratiequery's, vink altijd "Toegestaan" aan om het rapport te laten werken onder elke gebruiker met enige set rechten.

In het geval van objectlezing van gegevens uit de database, is er geen manier om de vlag "Toegestaan" in te stellen. Daarom is het nodig configureer filters voor het lezen van objecten, rekening houdend met mogelijke toegangsrechtenbeperkingen voor de gebruiker. Er zijn geen middelen om alleen toegestane gegevens in objecttechnologie te verkrijgen.

Het is belangrijk dat als de query het trefwoord ALLOWED niet specificeert, alle selecties die in deze query zijn gespecificeerd, niet in tegenspraak mogen zijn met de beperkingen voor het lezen van database-objecten die in de query worden gebruikt. Als de query bovendien gebruikmaakt van virtuele tabellen, moeten de overeenkomstige selecties worden opgelegd aan de virtuele tabellen zelf.

Oefening 1. De constructor van queries in de RLS-instellingen.

Laten we de tekst van de sectie "WAAR" opstellen in het verzoek aan het naslagwerk. U kunt de queryontwerper gebruiken.
De constructeur heeft een uitgeklede look.

Tabblad "Tafels"

De hoofdtabel is de tabel van het object waarvoor de beperking wordt geconfigureerd.

U kunt ook andere tabellen selecteren en verschillende koppelingen tussen deze tabellen instellen op het tabblad "Links".

Tabblad Voorwaarden

Hier kunt u de daadwerkelijke toegangsbeperkingsvoorwaarden configureren.

Laten we voorwaarden toevoegen voor de variabele "Prijs" van het naslagwerk voor de nomenclatuur voor het recht om te "lezen" voor alle velden van de tabel.

"Nomenclatuur WHERE Nomenclatuur. Prijs> 500"

Laten we eens kijken hoe deze eenvoudige regel werkt. De referentietabel bevat de volgende elementen:

Na het configureren van de toegangsbeperking, toont de tabel alleen de elementen die aan de voorwaarde voldoen:

Ook de groepen verdwenen. De beperkingstekst wijzigen

"Nomenclatuur WAAR Nomenclatuur. Prijs> 500

OF Nomenclatuur. Dit is een groep "

Nou, dat is wat je nodig hebt.

Als u de weergave van het "code"-veld in de lijstinstellingen uitschakelt, worden alle elementen van de directory weergegeven, d.w.z. de beperking werkte niet. Als u de weergave instelt op het veld "Code", werkt de beperking.

Tegelijkertijd kan, ondanks het feit dat het catalogusitem zichtbaar is in het lijstveld, de vorm ervan niet worden geopend, omdat er een beperking op het kenmerk is geconfigureerd. Hetzelfde geldt voor een willekeurig verzoek: wanneer u probeert een "beperkt" kenmerk te krijgen, zal er een toegangsfout optreden.

Als u de "beperkte" rekwisieten programmatisch probeert te krijgen, wordt er ook een toegangsfout gegenereerd.

Bovendien is het niet mogelijk om via een link toegang te krijgen tot velden van een object, omdat wanneer een link wordt ontvangen, het systeem het hele object als geheel leest en als het "beperkte" details bevat, wordt het object niet gelezen .

Daarom moet u, wanneer u programmatisch met database-objecten werkt, rekening houden met mogelijke beperkingen op recordniveau en alle benodigde objectgegevens verkrijgen met een query en deze vervolgens in een structuur plaatsen of een deel van de code uitvoeren in een bevoorrechte module.

Na het instellen van de toegangsbeperking, veranderde de weergave van de regel in de lijst met rechten - deze werd grijs en het pictogram verscheen.

Beperkingen bij het configureren van toegang (RLS).

• Er is geen sectie Samenvatting;
• Virtuele registertabellen zijn niet toegankelijk;
• U kunt parameters niet expliciet gebruiken;
• Subquery's kunnen gebruiken any> / span> query taalfaciliteiten, behalve:
  • operator IN DE HIRARCHIE;
  • voorstellen RESULTATEN;
  • subquery resultaten mag geen tabulaire secties> / span> bevatten;
  • virtuele tafels, in het bijzonder Saldi en Omzet

Oefening 2. Nomenclatuur met de huidige prijs.

Beperk de toegang als u een artikel wilt weergeven waarvan de huidige prijs hoger is dan een bepaalde waarde, bijvoorbeeld 100.

Oplossing:

Voeg een nieuwe regel toe voor het beperken van de toegang tot het naslagwerk "Nomenclatuur" voor het recht "lezen".
We selecteren "andere velden".
Voeg in de constructor een subquery toe. Selecteer daarin de tabel van het informatieregister "Artikelprijzen".
Er is geen "bestelling"-tabblad - dit is een functie van de queryontwerper voor het maken van een toegangsbeperkingsquery.
Stel op het tabblad "Geavanceerd" "eerste 999999999" in, het tabblad "bestellen" is verschenen.
Stel de aflopende volgorde in op het veld "Periode".
Vervolgens stellen we de relatie van de hoofdtabel met de subquery door middel van verwijzing in.

Sjablonen voor toegangsbeperkingen.

Praktijk 3. Beperking van "tegenpartijen" door waarde in een constante.

Laten we toegangsbeperkingen configureren voor het opzoeken van aannemers op basis van de waarde die is opgeslagen in de constante.

Bovendien moet u een beperking instellen voor alle objecten met behulp van de map "Contractors" in de details.

Oplossing

Voor de zoekopdracht "Contractors" voor het recht "lezen", zullen we de beperking configureren door een subquery toe te voegen aan de constante in de sectie "Voorwaarden". Vergeet deze groep niet.

We zien het probleem, de map Tegenpartijen wordt correct gefilterd en alle documenten met het kenmerk "Tegenpartij" worden weergegeven, sommige met verbroken koppelingen in de variabele "Tegenpartij".

Nu moet u toegangsbeperkingen configureren voor alle objecten met behulp van de link naar "Contractors". Laten we ze vinden met de service "zoek naar links naar een object".

Laten we de tekst van de RLS-voorwaarde kopiëren en enigszins wijzigen uit het naslagwerk "Aannemers". Dit moet net zo vaak worden gedaan als het aantal gevonden objecten.

Of gebruik een toegangsbeperkingspatroon om problemen met codeduplicatie te voorkomen.

Sjablonen voor toegangsbeperkingen zijn configureerbaar op rolniveau en kunnen voor elk object binnen de bewerkte rol worden gebruikt.

U kunt elk stukje toegangsbeperkingstekst aan de sjabloon toevoegen. De sjabloon wordt opgeroepen via het "#"-symbool. Bijvoorbeeld # TemplateContractor.

Via # in 1C worden instructies naar de preprocessor geschreven. In het kader van het uitvoeren van instellingen voor toegangsbeperkingen vervangt het platform de sjabloonoproeptekst door de sjabloontekst.

Laten we de tekst na het woord WHERE in de sjabloon "TemplateContractor" plaatsen, behalve de tekst over ThisGroup.

Parameters in Sjablonen voor toegangsbeperkingen.

Laten we doorgaan met het oplossen van probleem 2.

Het probleem ligt nu in het feit dat de hoofdtabel in de directory "tegenpartij" wordt genoemd in het document "Ontvangst". Het aangevinkte veld in het naslagwerk heet "link", in het document - "Tegenpartij".

Wijzig de naam van de hoofdtabel in de tekst van de sjabloon in "#CurrentTable"

"#CurrentTable" is een vooraf gedefinieerde parameter.

En via een punt geven we het nummer van de invoerparameter aan - ". # Parameter (1)

"#Parameter" is ook een vooraf gedefinieerde waarde. Het kan een willekeurig aantal invoerparameters bevatten. Ze worden aangesproken met hun volgnummer.

In de tekst van de toegangsbeperking voor het naslagwerk geven we het volgende aan:

Voor een document geldt het volgende:

"Verkoop van goederen WAAR # TemplateContractor (" Tegenpartij ")"

Wanneer u een sjabloon voor toegangsbeperkingen aanroept, mogen parameters er alleen als tekenreeks aan worden doorgegeven, dat wil zeggen tussen aanhalingstekens.

Hoofdtabel - Nomenclatuur

De sjabloontekst is als volgt:

#CurrentTable WAAR #CurrentTable # Parameter (1) = # Parameter (2)

De sjabloontekst bevat een deel van de tekst in de taal voor gegevenstoegangsbeperking en kan parameters bevatten die zijn gemarkeerd met het "#"-symbool.

Het "#"-teken kan worden gevolgd door:

• Een van de trefwoorden:
  • Parameter, waarna tussen haakjes het nummer van de parameter in het sjabloon staat;
  • CurrentTable - geeft de invoeging aan in de tekst van de volledige naam van de tabel waarvoor de beperking wordt gebouwd;
  • NaamHuidigeTabel- geeft de invoeging aan in de tekst van de volledige naam van de tabel (als een tekenreekswaarde, tussen aanhalingstekens), waarop de instructie wordt toegepast, in de huidige versie van de ingebedde taal;
  • NaamHuidigeToegangsrechten- bevat de naam van het recht waarvoor de huidige beperking wordt uitgevoerd: READ / READ, ADD / INSERT, CHANGE / UPDATE, DELETE / DELETE;
• de naam van de sjabloonparameter - betekent het invoegen van de overeenkomstige sjabloonparameter in de tekst van de beperking;
• symbool "#" - geeft het invoegen van één symbool "#" in de tekst aan.

Een expressie voor toegangsbeperking kan het volgende bevatten:

• Sjabloon voor toegangsbeperkingen, die is opgegeven in de indeling #TemplateName ("Template parameterwaarde 1", "Template parameterwaarde 2", ...)... Elke sjabloonparameter staat tussen dubbele aanhalingstekens. Als u dubbele aanhalingstekens in de parametertekst moet opgeven, gebruikt u twee dubbele aanhalingstekens.
• Functie StrContains (WhereLooking, WhatLooking)... De functie is ontworpen om te zoeken naar een voorkomen van de regel WhatSeeking in de regel WhereSeeking. Retourneert True als een gebeurtenis wordt gevonden en anders False.
• Operator + voor aaneenschakeling van tekenreeksen.

Voor het gemak van het bewerken van de sjabloontekst, klikt u op het tabblad Beperkingssjablonen in het rolformulier op de knop Sjabloontekst instellen. Voer in het dialoogvenster dat wordt geopend de sjabloontekst in en klik op de knop OK.

Ze kunnen niet worden geïnstalleerd door de methode: Parameter instellen () of iets dergelijks.

De parameters in dit geval zijn:

• Sessie parameters
• Functionele opties

Het lezen van sessieparameters in een toegangsbeperkingsverzoek vindt plaats in de bevoorrechte modus, dat wil zeggen zonder de rechten om ermee te werken te controleren.

Praktijk 4. Toegang tot "eigen" tegenpartijen

Het is noodzakelijk om de toegang van de huidige gebruiker tot "eigen" tegenpartijen in te stellen.

Er is een map "Gebruikers", een map "Tegenpartijen", documenten met het kenmerk "Tegenpartij".

De huidige gebruiker zou alleen gegevens moeten zien van die tegenpartijen waarvoor een verbinding met hem tot stand is gebracht.

De verbinding moet ook worden geconfigureerd.

Mogelijke opties:

Verbindingen maken gebruiker + tegenpartij

• Vereisten in de directory tegenpartijen
• Informatie register

Mogelijke oplossingen voor het probleem:

• Het opslaan van de gebruiker in een constante is een slechte optie, de constante is beschikbaar voor alle gebruikers.
• Het opslaan van een vaste array van de huidige gebruikersaccounts in de sessieparameters is geen goede optie, er kunnen veel tegenpartijen zijn
• Het opslaan van de huidige gebruiker in de sessieparameters en het op verzoek ophalen van een lijst van "zijn" tegenpartijen is een acceptabele optie.
• Andere opties.

Oplossing.

Laten we een nieuwe sessieparameter "CurrentUser" maken en de vulling ervan registreren in de sessiemodule.

Laten we een informatieregister maken "Naleving van managers en aannemers"

Laten we een nieuwe rol maken en daarin een nieuwe toegangsbeperking voor het Factuurdocument.

Laten we in de tekst van het verzoek de hoofdtabel verbinden met het informatieregister door Tegenpartij = Tegenpartij en Manager = & Huidige Gebruiker. Verbindingstype Intern.

Indien mogelijk is het beter om geneste query's in toegangsbeperkingsteksten te vermijden, omdat deze elke keer worden uitgevoerd wanneer gegevens van dit object uit de database worden gelezen.

Controleren - de beperkingen werken

* Feature: Als u de lijst met tegenpartijen van de gebruiker in het register wijzigt, worden de toegangsbeperkingen onmiddellijk van kracht zonder de gebruikerssessie opnieuw te starten.

Praktijk 5. Datum van verbod op wijzigingen.

Het is noodzakelijk om de beperking op het bewerken van gegevens te implementeren vóór de vastgestelde datum van verbod op wijzigingen.
U moet beperken voor gebruikers.

Laten we een informatieregister "ChangeDateDates" maken met de dimensie Gebruiker, resourceDefaultDate.

Laten we de logica van de oplossing op deze manier bouwen:

• als een gebruiker niet is opgegeven, is de ban geldig voor alle gebruikers
• als er een beperking is voor alle gebruikers en een beperking voor een specifieke gebruiker, dan is er een beperking voor een specifieke gebruiker, en voor de rest volgens een algemeen principe.

Het is duidelijk dat een dergelijke beperking kan worden geconfigureerd voor database-objecten die een positie op de tijdas hebben. Het kan zijn

• Documentatie
• Periodieke informatieregisters

Laten we een nieuwe rol "ConstraintsByDateForbidChanges" maken.

Voeg daarin voor het document "Ontvangstfactuur" voor de juiste "wijziging" een nieuwe toegangsbeperking toe.

Voor alle velden geven we de instelling aan.

De restrictietekst is als volgt:

Inkomende factuur VAN Document Inkomende factuur ALS factuur

VerbodsdatumsVerbodsdatum wijzigen AS Verbodsdatum
VAN

INTERNE VERBINDING (SELECTIE
MAXIMUM (ProhibitedChange Dates.User) AS-gebruiker
VAN
Datasheet.DatesWijzigen-Verbieden AS DatumsWijzigen-Verbieden
WAAR
(ChangeProhibitionDates.User = & CurrentUser
OF DateProhibitingChanges.User = VALUE (Datasheet.users.EmptyRef))) AS OU_User
Op DateProhibitionDate.User = OT_User.User) AS NestedRequest
Op ontvangst factuur.Datum> NestedRequest.Inhibit Date

We controleren - de beperking werkt.

Preprocessor-instructies gebruiken

# Als Voorwaarde1 # Dan

Vraag fragment 1

# ElseIf Conditie2 # Dan

Vraag fragment 2

#Anders

Vraag fragment 3

#Stop als

In voorwaarden kunt u logische bewerkingen gebruiken (en. Of, niet, enz.) en toegang tot sessieparameters.

Deze benadering in de context van het construeren van toegangsbeperkingen is handig omdat, afhankelijk van de voorwaarden, een kortere vraagtekst zal worden samengesteld. En een eenvoudigere query belast het systeem minder.

Het nadeel is dat de queryconstructor niet werkt met dergelijke tekst.

* Eigenaardigheid :

In tegenstelling tot de instructies voor de ingebedde taal-preprocessor in de teksten van toegangsbeperkingen voor de operator Dan moet je een hash plaatsen - # Dan

Oefening 6. Schakel over naar "Gebruik RLS"

Laten we ons restrictiesysteem aanvullen met een schakelaar die het gebruik van restrictie op recordniveau in-/uitschakelt.

Voeg hiervoor een constante en een sessieparameter toe met de naam "Gebruik RLS".

Laten we in de sessiemodule schrijven en de sessieparameterwaarde instellen op basis van de constante waarde.

Voeg de volgende code toe aan alle toegangsbeperkingsteksten:

"# Als & RLS gebruiken # Dan ... .. # EndIf"

We controleren - alles werkt.

Nu echter, na het inschakelen van de vlag "radar gebruiken", worden de wijzigingen niet onmiddellijk van kracht. Waarom?

Omdat de sessieparameter wordt ingesteld wanneer de sessie start.

U kunt ervoor zorgen dat op het moment dat u een nieuwe waarde van de constante schrijft, de waarde van de sessieparameter wordt gereset, maar dit werkt alleen voor de huidige gebruikerssessie. Andere gebruikers moeten worden gevraagd om het systeem opnieuw op te starten.

Einde van het eerste deel.

Afdrukken (Ctrl + P)

Toegang tot gegevens beperken

Het mechanisme voor het beperken van toegang tot gegevens (ook wel RLS, Row Level Security genoemd) stelt u in staat om toegangsrechten niet alleen op het niveau van metadata-objecten te beheren, maar ook op het niveau van objecten in de 1C: Enterprise-database. Om de toegang tot gegevens te beperken, kunnen de volgende 1C: Enterprise-objecten worden gebruikt:
● rollen,
● sessieparameters,
● functionele opties,
● bevoorrechte gedeelde modules,
● het trefwoord TOEGESTAAN in de zoektaal.
Het delen van de vermelde objecten zorgt voor maximale flexibiliteit wanneer het nodig is om toegangsrechten tot gegevens te differentiëren tussen gebruikers die verschillende functies uitvoeren.
Gegevenstoegangsbeperkingen kunnen worden opgelegd aan de volgende bewerkingen met gegevens (toegangsrechten): lezen (rechts lezen), toevoegen (recht toevoegen), wijzigen (recht wijzigen) en verwijderen (recht verwijderen). De huidige gebruiker kan de vereiste bewerking in de volgende gevallen uitvoeren:
● Voor lees- en wisbewerkingen moet het object in de database voldoen aan de datatoegangsbeperking.
● Voor een toevoegbewerking moet de beperking van de gegevenstoegang overeenkomen met het object dat u naar de database wilt schrijven.
● Voor een wijzigingsbewerking moet het object zowel vóór de wijziging (om het object te lezen) als na de wijziging (om het object te schrijven) aan de datatoegangsbeperking voldoen.
Houd er bij het opleggen van gegevenstoegangsbeperkingen rekening mee dat er slechts één voorwaarde kan worden ingesteld voor bewerkingen voor bijwerken, toevoegen en verwijderen, en dat er meer dan één beperking voor gegevenstoegang kan worden ingesteld voor een leesbewerking. Dit betekent dat er verschillende voorwaarden kunnen worden opgegeven voor het lezen van verschillende velden van een object, en bij het specificeren van een voorwaarde kunt u zowel de naam van een specifiek veld als het speciale veld Overige velden specificeren. In het eerste geval wordt de voorwaarde alleen opgelegd als de selectie (die gegevens leest) een veld bevat waarvoor de beperking is ingesteld, en in het tweede geval wordt de beperking opgelegd aan alle velden van het object, behalve velden voor waarvan de beperkingen expliciet worden gespecificeerd. ...
Bij het instellen van een beperking voor een specifiek veld, wordt dit veld gelezen als aan de beperking wordt voldaan, en bij het instellen van een beperking voor Overige velden worden de objectgegevens alleen gelezen als aan de beperking wordt voldaan voor alle velden van het object dat is opgenomen in de gegevens leesverzoek.
Voor database-objecten van de volgende typen kunnen verschillende beperkingen worden opgelegd aan verschillende typen wijzigingen (toevoegen, wijzigen, verwijderen):
● Plannen uitwisselen,
● Directory's,
● Documenten,
● Plattegronden van karakteristieke typen,
● Rekeningschema's,
● Plannen van nederzettingstypes,
● Bedrijfsprocessen,
● Taken.
Voor de volgende typen databaseobjecten is het mogelijk beperkingen op te leggen voor het lezen van niet alleen het gehele object als geheel, maar ook de afzonderlijke velden:
● Plannen uitwisselen,
● Directory's,
● Documenten,
● Tijdschriften van documenten,
● Plattegronden van karakteristieke typen,
● Rekeningschema's,
● Plannen van nederzettingstypes,
● Registers van informatie,
● Bedrijfsprocessen,
● Taken.
AANDACHT! Bij toegang tot de velden van database-objecten met behulp van de eigenschappen van toegepaste objecten uit de ingebouwde 1C: Enterprise-taal, wordt het hele object gelezen en niet alleen de waarde van het gebruikte veld. Een uitzondering is het krijgen van een weergave wanneer alleen de waarden van de velden die deelnemen aan de vorming van de weergave worden gelezen.
Toegangsbeperkingen zijn opgenomen in rollen, kunnen worden gespecificeerd voor de meeste metadata-objecten en zijn geschreven in een speciale taal die een subset is van de querytaal.

Beperking taal voor gegevenstoegang

Beperkingen voor gegevenstoegang worden beschreven in een speciale taal die een subset is van de zoektaal (een gedetailleerde beschrijving van de zoektaal. De taal voor gegevenstoegangsbeperkingen heeft de volgende wijzigingen met betrekking tot de zoektaal:
● In een query voor beperking van gegevenstoegang is er altijd één tabel als gegevensbron - dit is de tabel van het object waarop de beperking wordt toegepast (het hoofdobject van de beperking).
● Verkorte omschrijving van de aanvraag. De taal voor beperking van gegevenstoegang gebruikt alleen de gedeelten FROM en WHERE van de querytaal. De beschrijving van de zoektaal is dus als volgt:
SELECTEER [TOEGESTAAN] [DIVERS] [ EERST<Количество> ]
<Lijst met selectievelden>
[VAN <Список источников> ]
[WAAR<Условие отбора> ]
[LADEN DOOR <Поля группировки> ]
[HEEFT<Условие отбора> ]
[VOOR DE VERANDERING [ <Список таблиц верхнего уровня> ]]
Hoewel de beschrijving van de querytaal voor gegevenstoegangsbeperkingen als volgt is:
[Tabelalias hoofdbeperkingsobject]
[VAN <Список источников> ]
[WAAR<Условие отбора> ]

De subquery's die worden gebruikt in de taal voor beperking van gegevenstoegang hebben een beperkt aantal toegestane opties;
● Sessieparameters en functionele opties kunnen worden gespecificeerd als conditie-elementen;
● Overal in een verzoek om beperking van gegevenstoegang kunt u sjablonen gebruiken die het gemakkelijker maken om beperkingen op te schrijven.
Het belangrijkste onderdeel van de beperking is de voorwaarde die wordt berekend voor elk record van de databasetabel waaraan de beperking voor gegevenstoegang wordt opgelegd. Een record wordt als beschikbaar beschouwd als, als gevolg van de werking van de voorwaarde voor één record van de tabel van het hoofdobject van beperking, een niet-lege tabel wordt verkregen (dwz een tabel waarin zich 1 of meer records bevinden) . Als de voorwaarde resulteert in een lege tabel, wordt het record waarvoor op deze manier aan de voorwaarde is voldaan, als niet-beschikbaar beschouwd. Bovendien, het wijzigen van het record van de tabel van het hoofdobject van beperking
wordt als geldig beschouwd als het record niet in strijd is met de beperking die voor het recht is gespecificeerd, zowel vóór het uitvoeren van de wijzigingsbewerking als na het uitvoeren van deze bewerking.

Tabelvelden

Bij gegevenstoegangsbeperkingen kunt u het volgende gebruiken:
● Velden van tabellen van het object waarvoor de beperking van de gegevenstoegang is beschreven.
Als er bijvoorbeeld een beperking wordt opgelegd aan het lezen van elementen van het woordenboek voor aannemers, dan kan de beperking de velden van het woordenboek voor aannemers en de secties in tabelvorm gebruiken. In het bijzonder kunnen de eenvoudigste beperkingen op het lezen van elementen van de Aannemerscatalogus er als volgt uitzien:

WHERE Naam = "Brick Factory"
Of zo:

WAAR Producten.= "Baksteenrood"
Where Products is een sectie in tabelvorm van de lijst met aannemers.
● Velden van tabellen met objecten die toegankelijk zijn via koppelingen in het hoofdobject van de beperking.
Als het kenmerk PrimaryManager van de catalogus Tegenpartijen bijvoorbeeld van het type koppeling naar de gebruikerscatalogus is, kan de toegangsbeperking bijvoorbeeld de volgende vorm hebben:

WAAR HoofdManager.Code= "Ivanov"
Of:

WAAR MainManager.PhysicalPerson.Description= "Petrovski"
● Velden van tabellen van objecten die zijn gekoppeld aan het hoofdobject van beperking door enkele voorwaarden en uitdrukkingen erboven.
Zo kan de volgende beperking worden opgelegd aan het lezen van elementen van de Aannemerscatalogus:

Aannemers
VAN
Directory. Aannemers AS Aannemers
LINKER GEWICHT Referentie: Gebruikers AS-gebruikers
Software = gebruikers.
WAAR = "Petrovski"
Deze beperking gebruikt de velden van items in de gebruikerscatalogus die zijn gekoppeld aan dit catalogusitem Aannemers door de waarde van de Naam-velden.

Geneste zoekopdrachten

Subquery's worden gebruikt om recordsets te vormen die kunnen worden gebruikt:
● om te linken naar de tabel van het hoofdobject van de beperking;
● te gebruiken als operand voor B- of NOT B-vergelijkingsbewerkingen.
Elk middel van de querytaal kan in subquery's worden gebruikt, behalve:
● operator IN DE HIRARCHIE;
● suggesties RESULTATEN;
● resultaten van geneste zoekopdrachten mogen geen secties in tabelvorm bevatten;
● in het bijzonder enkele virtuele tafels Saldi en Omzet.
In het volgende voorbeeld van een beperking bij het lezen uit de directory Contractors, wordt een subquery gebruikt als een recordset om te binden aan het hoofdobject van de beperking:

Aannemers
VAN
Directory. Aannemers AS Aannemers
LINKER GEWICHT
(SELECTIE
Gebruikers.Naam, Gebruikers.Persoon
VAN
Referentie: Gebruikers AS-gebruikers
WAAR
Gebruikerscode:> "Petechkin") AS-gebruikers
AAN Naam hoofdmanager tegenpartijen = Gebruikersnaam:
WAAR Gebruikers.Persoon.Naam= "Petrovski"
Het volgende voorbeeld toont de beperking voor het lezen uit de map PassportDataPhysPersons, waarin een subquery wordt gebruikt in
als de operand van de vergelijkingsoperator B:

WAAR
PaspoortgegevensPhysPhys.PhysFace V
(KIES DIVERSE
Workers.PhysFace ALS EEN PERSOON
VAN
Informatie Register.Medewerkers AS-werknemers)
Als het in een subquery nodig is om gegevens uit de tabelsectie te verkrijgen, dan is het in de FROM-sectie van de subquery noodzakelijk om rechtstreeks naar de tabelsectie te verwijzen. Bijvoorbeeld in plaats van:

KIES Koppeling ALS Koppeling.
Producten. HOE Productnaam
VAN Directory. Aannemers
als een query ingesloten in een beperking, moet u het volgende gebruiken:

Sessie parameters

Sessieparameters kunnen worden opgenomen in verzoeken tot beperking van gegevenstoegang. Om bijvoorbeeld de elementen van de directory te lezen E-mailgroepen de volgende toegangsbeperking kan worden ingesteld:

WAAR Owner.AccountAccess.User = & Huidige Gebruiker
EN Eigenaar.Accounttoegang.Administratie= WAAR

CurrentUser is een sessieparameter

Functionele opties

Verzoeken om gegevenstoegangsbeperking kunnen functionele opties bevatten. Alleen parameteronafhankelijke functie-opties kunnen worden gebruikt. Als de catalogus Nomenclatuur bijvoorbeeld het kenmerk BasicWarehouse heeft, kan de beperking voor het lezen van dit kenmerk er als volgt uitzien:

WAAR & Magazijnboekhouding = TRUE

Waar magazijnboekhouding een functionele optie is

Kenmerken van gebruik

Bij beperkingen op databaseobjecten van de volgende typen kunnen niet alle velden van het hoofdgegevensobject van de beperking worden gebruikt:
● in verzamelregisters kunnen toegangsbeperkingen alleen afmetingen van het hoofdobject van beperkingen bevatten;
● in boekhoudingsregisters in constraints kunt u alleen de saldodimensies van het hoofdconstraint-object gebruiken.
NOTITIE. Indien onder voorwaarden van beperking van de toegang tot de gegevens van het circulerend accumulatieregister metingen worden gebruikt die niet in de totalen zijn opgenomen, dan
bij toegang tot de virtuele omzettabel worden de opgeslagen totalen niet gebruikt en wordt de query volledig uitgevoerd op basis van de transactietabel.

Toegangsbeperkingsacties

Toegangsbeperkingen worden gecontroleerd wanneer de juiste bewerkingen worden uitgevoerd op database-objecten (van dialoogvensters, van ingesloten taal, via query's) en kunnen op twee manieren werken:
Alles. De "all"-methode houdt in dat een bewerking op gegevens (van dialogen, van een ingebouwde taal of door middel van query's) moet worden uitgevoerd op alle database-objecten die door deze bewerking worden geïmpliceerd. Als bij het uitvoeren van een dergelijke bewerking databaseobjecten moeten worden gelezen of gewijzigd waarvoor niet aan de bijbehorende toegangsbeperkingen wordt voldaan, is de bewerking voltooid.
noodgeval wegens schending van toegangsrechten.
● Toegestaan. De "toegestane" methode houdt in dat bij het uitvoeren van een bewerking op gegevens, alleen die database-objecten moeten worden gelezen die voldoen aan de bijbehorende toegangsbeperkingen. Databaseobjecten die niet voldoen aan de toegangsbeperkingen worden als ontbrekend beschouwd wanneer een dergelijke bewerking wordt uitgevoerd en het resultaat van de bewerking wordt niet beïnvloed.
Gegevenstoegangsbeperkingen worden opgelegd aan databaseobjecten wanneer 1C: Enterprise toegang heeft tot de database. In de client-serverversie van 1C: Enterprise worden beperkingen opgelegd aan de 1C: Enterprise-server.
Het werkingsmechanisme van de beperkingen die worden gekozen voor het uitvoeren van elke bewerking op gegevens wordt bepaald door het doel van deze bewerking en de mate van verantwoordelijkheid voor de resultaten. In het bijzonder wordt de "toegestane" methode gebruikt bij het weergeven van dynamische lijsten en enkele andere interactieve acties. De "all"-methode wordt gebruikt bij het uitvoeren van bewerkingen met toegepaste objecten uit de ingebouwde 1C: Enterprise-taal, inclusief bij het wijzigen van database-objecten. Daarom kunnen er bijvoorbeeld moeilijkheden optreden bij het construeren van een selectie voor de Select ()-methode van beheerders van mappen, documenten en anderen, gevolgd door een bypass van het resultaat als een voldoende complexe beperking is ingesteld op het overeenkomstige object, aangezien niet elke voorwaarde bij het beperken van toegangsrechten kan adequaat worden weergegeven als een selectie voor de methode Select () .
In query's kunt u bepalen hoe beperkingen voor gegevenstoegang werken. Om dit te doen, biedt de zoektaal een trefwoord TOEGESTAAN... Als het verzoek TOEGESTAAN niet specificeert, worden de beperkingen op de "alle" manier toegepast. Als het woord ALLOWED is opgegeven, wordt de methode "allowed" geselecteerd.
Het is belangrijk dat als de query het trefwoord ALLOWED niet specificeert, alle selecties die in deze query zijn gespecificeerd, niet in tegenspraak mogen zijn met de beperkingen voor het lezen van database-objecten die in de query worden gebruikt. Als de query bovendien gebruikmaakt van virtuele tabellen, moeten de overeenkomstige selecties worden opgelegd aan de virtuele tabellen zelf.
Voorbeeld:

KIES
ContactgegevensSliceFirst.View
VAN InformationRegister.ContactInformation.SliceLast (, Type = & Type)
HOE ContactgegevensSliceFirst
WAAR
ContactInformationSliceFirst.Type = & Type
Toegang tot gegevens in de modus TOEGESTAAN wordt niet ondersteund bij gebruik van de objecttechniek. Aangenomen wordt dat de objecttechniek wordt gebruikt voor de meest kritische bewerkingen op data, ook voor het wijzigen ervan. Om alle gegevens te verkrijgen met behulp van de objecttechniek, ongeacht de vastgestelde beperkingen, kunt u de nodige acties uitvoeren in een bevoorrechte module of namens een gebruiker met volledige rechten. Er zijn geen middelen om alleen toegestane gegevens in objecttechnologie te verkrijgen.

beperking mechanisme:

Elke bewerking op gegevens die zijn opgeslagen in een database in 1C: Enterprise leidt uiteindelijk tot toegang tot de database met sommigen
een verzoek tot inzage of wijziging van gegevens. Tijdens het uitvoeren van query's op de database leggen de interne mechanismen van 1C: Enterprise toegangsbeperkingen op. Waarin:
● Er wordt een lijst met rechten (lezen, toevoegen, wijzigen, verwijderen), een lijst met databasetabellen en een lijst met velden die door deze query worden gebruikt, gevormd.
● Uit alle rollen van de huidige gebruiker worden gegevenstoegangsbeperkingen geselecteerd voor alle rechten, tabellen en velden die in de query worden gebruikt. Bovendien, als een rol geen beperkingen bevat voor toegang tot gegevens van een tabel of veld, dan betekent dit dat de waarden van de vereiste velden van elk record beschikbaar zijn in deze tabel. Met andere woorden, het ontbreken van een beperking op de toegang tot gegevens betekent dat er een beperking is
WAAR is de waarheid.
● De huidige waarden van alle sessieparameters en functionele opties die deelnemen aan de geselecteerde beperkingen worden verkregen.
Om de waarde van een sessieparameter van de huidige gebruiker te krijgen, hoeft u niet het recht te hebben om die waarde te krijgen. Als de waarde van een sessieparameter echter niet is ingesteld, treedt er een fout op en wordt de databasequery niet uitgevoerd.
De ontvangst van functionele opties wordt bij ontvangst beïnvloed door de eigenschap van de functionele optie Bevoorrechte modus.
Als deze eigenschap is gewist, moet de huidige gebruiker leestoegang hebben tot het object waarin de functionele optie is opgeslagen.
● Beperkingen verkregen uit één rol worden gecombineerd met de AND-bewerking.
● Beperkingen die zijn afgeleid van verschillende rollen, worden samen in een OR geplaatst.
● De geconstrueerde voorwaarden worden toegevoegd aan de SQL-query's waarmee 1C: Enterprise het DBMS adresseert. Bij het benaderen van gegevens vanaf de kant van de toegangsbeperkingsvoorwaarden, wordt er geen rechtencontrole uitgevoerd (noch naar metadata-objecten, noch naar database-objecten). Bovendien hangt het mechanisme voor het toevoegen van voorwaarden af ​​van de gekozen werkwijze van de beperkingen "alle" of "toegestaan".
De "alle" methode
Wanneer beperkingen worden opgelegd in de "all"-methode, worden voorwaarden en velden toegevoegd aan SQL-query's zodat 1C: Enterprise informatie kan verkrijgen over of de voor deze gebruiker verboden gegevens zijn gebruikt tijdens het uitvoeren van een databasequery. Als de verboden gegevens zijn gebruikt, wordt een abnormale beëindiging van het verzoek in gang gezet. Het opleggen van toegangsbeperkingen met behulp van de "alle"-methode wordt schematisch weergegeven in Fig. een:

Rijst. 1. De "alle" methode

Methode "toegestaan"
Bij het opleggen van beperkingen op de "toegestane" manier, worden voorwaarden toegevoegd aan SQL-query's zodat records die door de huidige gebruiker zijn verboden, het queryresultaat niet beïnvloeden. Met andere woorden, wanneer beperkingen worden opgelegd in de "toegestane" modus, worden de records die voor een bepaalde gebruiker zijn verboden, als afwezig beschouwd, wat schematisch wordt weergegeven in Fig. 3

Andere objecten met betrekking tot gegevenstoegangsbeperkingen

Bij het ontwikkelen van configuraties met gegevenstoegangsbeperkingen, kunnen metagegevensobjecten zoals sessieparameters, functionele opties en algemene modules met het selectievakje Privileged handig zijn.
Sessie parameters
Sessieparameters kunnen op dezelfde manier worden gebruikt in gegevenstoegangsbeperkingen als queryparameters in een aanvraag.
Functionele opties
Parameteronafhankelijke functie-opties kunnen op dezelfde manier worden gebruikt in gegevenstoegangsbeperkingen als queryparameters in een query kunnen worden gebruikt.
Bevoorrechte gedeelde modules

Als het selectievakje Bevoorrecht is geselecteerd voor een gemeenschappelijke module, krijgt de uitvoering van de procedures en functies van deze module belangrijke details:
● In de client-serverversie van 1C: Enterprise kan alleen de module die op de server wordt uitgevoerd, worden bevoorrecht.
● Uitvoering van de procedures en functies van de geprivilegieerde module en alles wat daaruit wordt aangeroepen, wordt uitgevoerd wanneer het restrictiesysteem is uitgeschakeld
rechten op zowel metadata-objecten als data. Dus vanaf de geprivilegieerde module kan elke bewerking op
alle objecten, zelfs als de huidige gebruiker niet over de juiste rechten beschikt.
Bevoorrechte modules zijn bedoeld voor de initiële instelling van sessieparameterwaarden die worden gebruikt in gegevenstoegangsbeperkingen.
Gemeenschappelijke modules kunnen ook worden gebruikt voor een aantal holistische gegevensmanipulatie door een gebruiker met beperkte rechten.
Als de gebruikersfuncties bijvoorbeeld het invoeren en posten van documenten omvatten, maar de gebruiker geen toegang zou moeten hebben tot gegevens die worden beïnvloed door het posten van documenten, dan kan de boekingsbewerking worden verplaatst naar een bevoorrechte module. Hierdoor kan de gebruiker documenten posten zonder hem rechten te verlenen op andere informatie (bijvoorbeeld registers).
Bevoorrechte modus
Het is mogelijk om de bevoorrechte modus programmatisch in te stellen bij het werken met gegevens. Programmatisch bevoorrechte modus
kan nodig zijn in het geval van massale operaties met infobase-gegevens, en het heeft geen zin om de toegangsrechten voor gegevens te controleren.
Zie hier voor een beschrijving van de bevoorrechte modus.

De preprocessor gebruiken

Bij het bewerken van tekst met beperking van gegevenstoegang kunnen preprocessor-instructies worden gebruikt. De volgende instructies zijn beschikbaar:

#ALS<Выражение>#DAN
# ANDERS<Выражение>#DAN
#ANDERS
# STOP ALS
<Выражение>- een willekeurige logische uitdrukking in de ingebouwde taal, waarvan het resultaat van het Booleaanse type is. De uitdrukking kan bevatten:
● vergelijkingsbewerkingen<, >, <=, >= , =, <> ;
● logische bewerkingen AND, OR, NOT;
● sessieparameters - de syntaxis is & Parameter, waarbij Parameter de naam is van de sessieparameter.
Als het resultaat van de instructieexpressie #IF of # ELSE IF True is, wordt de tekst na het sleutelwoord # THEN in de resulterende tekst van de toegangsbeperkingsinstructie geplaatst. Als de expressie False oplevert, wordt de tekst na het sleutelwoord # THEN niet in de tekst van de toegangsbeperkingsverklaring geplaatst. De tekst na de # ELSE-instructie wordt in de resulterende toegangsbeperkingstekst geplaatst als aan geen van de eerdere voorwaarden is voldaan.
NOTITIE... Als de tekst voor de beperking van gegevenstoegang preprocessor-instructies bevat, komt de beperking niet door de syntaxiscontrole tijdens het bewerken en kan deze niet worden gewijzigd met behulp van de constructor.
Voorbeeld:

#IF & huidige gebruiker<>"Klimova" # DAN
<текст ограничения доступа>
# STOP ALS
Hier Huidige gebruiker- sessieparameter van het type ReferentieRef.Gebruikers.
Dit ontwerp houdt in dat de voorwaarde voor het instellen van toegangsbeperkingen wordt gecontroleerd voor alle gebruikers uit de directory, behalve voor de gebruiker Klimova.

Tekstsjablonen voor toegangsbeperkingen

Een rol kan een lijst met sjablonen voor toegangsbeperkingen bevatten, die worden beschreven op het tabblad Beperkingssjablonen van het rolformulier. Ook kunnen toegangsbeperkingssjablonen worden bewerkt in de editor voor groepsbewerking van toegangsbeperkingen en sjablonen.
Elke sjabloon voor toegangsbeperkingen heeft een naam en tekst. De sjabloonnaam volgt de gebruikelijke regels voor namen die worden gebruikt in het 1C: Enterprise-systeem.
De sjabloontekst bevat een deel van de tekst in de taal voor gegevenstoegangsbeperking en kan parameters bevatten die zijn gemarkeerd met het symbool
“#”.
Na het symbool “#” kan volgen:
● Een van de trefwoorden:
● Een parameter, waarna het nummer van de parameter in het sjabloon tussen haakjes staat;
● CurrentTable - geeft de invoeging in de tekst aan van de volledige naam van de tabel waarvoor de beperking wordt gemaakt;
● NaamHuidigeTabel- geeft de invoeging aan in de tekst van de volledige naam van de tabel (als een tekenreekswaarde, tussen aanhalingstekens), waarop de instructie wordt toegepast, in de huidige versie van de ingebedde taal;
● CurrentAccessRightName - bevat de naam van het recht waarvoor de huidige beperking wordt uitgevoerd: LEZEN / LEZEN, TOEVOEGEN / INVOEREN, WIJZIGEN /
BIJWERKEN, VERWIJDEREN / VERWIJDEREN;
● sjabloonparameternaam - betekent invoeging van de corresponderende sjabloonparameter in de beperkingstekst;
● "#"-symbool - geeft het invoegen van één "#"-symbool in de tekst aan.

Een expressie voor toegangsbeperking kan het volgende bevatten:

● Sjabloon voor toegangsbeperkingen, die is gespecificeerd in het formaat
#TemplateName (“Template parameterwaarde 1”, “Template parameterwaarde 2”, ...). Elke sjabloonparameter staat tussen dubbele aanhalingstekens. Als u dubbele aanhalingstekens in de parametertekst moet opgeven, gebruikt u twee dubbele aanhalingstekens.
● Functie StrContains (WhereLooking, WhatLooking)... De functie is ontworpen om te zoeken naar een voorkomen van de regel WhatSeeking in de regel WhereSeeking. Retourneert True als een gebeurtenis wordt gevonden en anders False.

● Operator + voor aaneenschakeling van tekenreeksen.
Voor het gemak van het bewerken van de sjabloontekst, klikt u op het tabblad Beperkingssjablonen in het rolformulier op de knop Sjabloontekst instellen. Voer in het dialoogvenster dat wordt geopend de sjabloontekst in en klik op de knop OK.
Het 1C: Enterprise-systeem controleert de syntaxis van sjabloonteksten, controleert de syntaxis van het gebruik van sjablonen en macrovervangingen van sjabloonteksten voor het beperken van roltoegang tot de aanvraagtekst.
Sjabloonmacrovervanging bestaat uit:
● bij het vervangen van parameters in de tekst van de sjabloon door de waarden van parameters uit de uitdrukking van het gebruik van de sjabloon in de tekst van de beperking;
● bij het vervangen van de uitdrukking van het gebruik van de sjabloon in de verzoektekst door de resulterende sjabloontekst.
Wanneer de queryconstructor wordt aangeroepen voor een voorwaarde die toegangsbeperkingspatronen bevat, wordt een waarschuwing gegeven over het vervangen van alle patronen.
Hieronder volgen voorbeelden van beperkingspatronen:

Om de gebruikerstoegang tot gegevens flexibel te beheren in overeenstemming met de functies bij het instellen van gegevenstoegangsbeperkingen, wordt aanbevolen:
houden zich aan de volgende principes:
● Het is noodzakelijk om een ​​set informatie te selecteren (kan afhankelijk zijn van de huidige gebruiker) waarvoor voorbereidende voorbereiding raadzaam is. De geselecteerde informatie moet enerzijds de toegangsbeperkingen zoveel mogelijk vereenvoudigen en anderzijds niet te groot zijn. Verdeel het op sessieparameters.
● Stel de sessieparameters in de SessionParametersSetting () -handler van de sessiemodule in.
● Stel toegangsbeperkingen in voor die gegevens waarvoor dit gerechtvaardigd is (gegevens zijn geheim of het belangrijkste voor het behoud van de integriteit van het systeem). Houd er rekening mee dat het instellen van toegangsbeperkingen de toegang tot deze gegevens kan vertragen. Te complexe beperkingen kunnen ook leiden tot vertragingen.
● Als het nodig is om de uitvoering van een bepaald beperkt aantal bewerkingen op gegevens te garanderen door een gebruiker die onpraktisch is om volledige toegang tot deze gegevens te geven, verplaats deze acties dan naar bevoorrechte modules of schakel de bevoorrechte modus expliciet in en uit in de juiste plaatsen in de programmacode.
● Toegang tot gegevens tijdens verschillende controles die door het systeem worden uitgevoerd bij het schrijven van objecten wordt uitgevoerd in de bevoorrechte modus.

Hiermee kunt u beperkingen in rechten op het niveau van records voor de bijbehorende velden niet uitschakelen, als de configuratie met deze gegevens werkt
alleen gepland in beheerde modus:

● ter referentie bij het controleren van de ouder, eigenaar en uniciteit van de code;
● voor documenten, bedrijfsprocessen en taken bij het controleren van de uniciteit van het nummer;
● uitgeschakeld voor uitwisselingsplannen bij het controleren van de uniciteit van de code;
● voor rekeningschema's en grafieken van kenmerkende typen bij het controleren van de ouder en uniciteit van de code.

Houd bij het maken van een gegevensbeperkingsquery rekening met enkele beperkingen en eigenaardigheden:

● Als gegevenstoegangsbeperkingen zijn opgegeven voor een objecttabel en een join met een dergelijke tabel wordt gebruikt in een gegevensquery, dan is het gebruik van het tabelgedeelte van het object met de opgegeven toegangsbeperking niet toegestaan ​​in de join-voorwaarde (softwarequery sectie).
● Als de query een tabel specificeert die geen velden in de query gebruikt, worden alle gegevenstoegangsbeperkingen aan deze tabel opgelegd. Bijvoorbeeld het verzoek SELECTEER HOEVEELHEID (*) UIT Directory.Contractors wordt uitgevoerd rekening houdend met alle toegangsbeperkingen die zijn opgegeven voor de Test-directory. Beperkingen worden opgelegd "door OR". Dit betekent dat alle records die beschikbaar zijn voor ten minste één aandoening beschikbaar zullen zijn. Als er voor sommige velden geen voorwaarden zijn opgegeven, wordt de query uitgevoerd voor alle tabelrecords.
Als de query een tabel op het hoogste niveau gebruikt, worden de beperkingen die zijn opgegeven voor de kolommen van geneste tabellen niet toegepast.
Als de query een geneste tabel gebruikt, worden er beperkingen opgelegd aan zowel de geneste tabel als de tabel op het hoogste niveau.
Bijvoorbeeld het verzoek SELECTEER HOEVEELHEID (*) UIT Directory.Contractors.Agreement zal worden uitgevoerd rekening houdend met alle beperkingen voor de directory Aannemers, evenals rekening houdend met de beperkingen met betrekking tot het tabelgedeelte van de Overeenkomst.

● Als toegang tot de velden die nodig zijn om een ​​representatie van het metadata-object waarnaar wordt verwezen, wordt geweigerd door:
gegevens of toegang tot een object is verboden op het niveau van toegangsrechten, dan heeft het verkrijgen van een weergave van een dergelijk object geen invloed op het verloop van de huidige transactie.

Constructor voor gegevenstoegangsbeperking

Om de constructor aan te roepen in het tabelveld Beperkingen gegevenstoegang in de kolom Toegangsbeperking, gaat u naar de bewerkingsmodus en
druk op de selectieknop en druk in het geopende formulier op de knop Queryconstructor....
Het constructorformulier wordt op het scherm weergegeven:

Rijst. 3. Tabblad "Tabellen en velden" van de constructor van beperkingen

Met haar hulp worden voorwaarden gevormd voor het stellen van beperkingen aan de toegang tot data.
Selecteer op het tabblad Tabellen en velden de vereiste objecten in de lijst Database en breng ze over naar de lijst Tabellen. Als er meerdere tabellen zijn opgegeven, wordt het tabblad Koppelingen toegevoegd in het ontwerpformulier.

Rijst. 4. Tabblad "Links" van de constructor van beperkingen

Op het tabblad Koppelingen worden voorwaarden gevormd die worden opgelegd aan de koppelingen tussen de velden van de tabellen. Om een ​​nieuwe voorwaarde in te voeren, klikt u op de knop Toevoegen en selecteert u een van de tabellen in de kolom Tabel1. Selecteer in de kolom Tabel2 de tabel waarvan de velden zijn gekoppeld aan de velden van de eerste. Onder de lijst met voorwaarden staan ​​bedieningselementen waarmee een voorwaarde voor het koppelen van tabellen wordt gevormd.
Als een eenvoudig voorwaardetype is geselecteerd, worden in Veld1 en Veld2 de gerelateerde velden van de opgegeven tabellen geselecteerd en wordt de vergelijkingsvoorwaarde ingesteld. Als de geselecteerde velden, waarvan de vergelijking niet wordt uitgevoerd, dan wordt in de regel van de lijst met voorwaarden in de kolom Koppelingsvoorwaarde de volgende tekst weergegeven: Ongeldig ingevulde voorwaarde.
Op het tabblad Voorwaarden moet u, indien nodig, de voorwaarden specificeren waaronder de selectie van brongegevens zal worden uitgevoerd.

Rijst. 5. Tabblad "Voorwaarden" van de constraint-constructor

Voor elk geselecteerd veld moet u het type voorwaarde selecteren en de naam van de parameter aangeven. Een sessieparameter kan als parameter worden gebruikt. Er zijn verschillende voorwaarden toegestaan. In dit geval wordt in de kolom Voorwaarde van het veld voorwaardentabel de tekst van de voorwaarde in meerdere regels weergegeven.
Op elk moment tijdens het aanmaken van een verzoek kan de tekst van het verzoek worden bekeken door op de knop Aanvragen te klikken.

Bulkbewerking van toegangsrechtenbeperkingen en sjablonen

De modus voor groepsbewerking van toegangsrechtenbeperkingen en sjablonen wordt aangeroepen door de opdracht Alle toegangsbeperkingen van het contextmenu van de vertakking Rollen. Het formulier dat wordt geopend, bevat twee tabbladen: Toegangsbeperkingen en Beperkingssjablonen.

Rijst. 6 Alle toegangsbeperkingen en sjablonen

Op een bladwijzer Toegangsrestricties u kunt alle ingevoerde toegangsbeperkingen bekijken in de algemene lijst (voor alle rollen, objecten, rechten, veldcombinaties).
Het is mogelijk om toegangsbeperkingen toe te voegen voor meerdere rollen, objecten, rechten en rolcombinaties tegelijk.
U kunt de lijst filteren op verschillende criteria.

Rijst. 7. Selectie van toegangsbeperkingen

Met de groepsbewerkingsmodus kunt u de in de lijst geselecteerde beperkingen verwijderen.
Het is mogelijk om de geselecteerde beperkingen te bewerken. In dit geval kunt u de samenstelling van de velden en/of de toegangsbeperking wijzigen.
Met de groepsbewerkingsmodus kunt u ook de geselecteerde beperkingen naar andere rollen kopiëren.

Op een bladwijzer Beperkingssjablonen u kunt alle sjablonen voor toegangsbeperkingen zien die aanwezig zijn in de toegepaste oplossing, terwijl van de daadwerkelijke sjabloontekst in de tabel alleen de eerste 10 regels worden weergegeven, die eindigen met het "..."-symbool als de sjabloontekst meer dan 10 regels is . Het sjabloonbewerkingsvenster geeft de volledige tekst van de sjabloon weer.

Fig 8. Alle sjablonen voor toegangsbeperking

Het is mogelijk om een ​​toegangsbeperkingssjabloon voor meerdere rollen tegelijk toe te voegen.

Vaak is het nodig om de toegang tot gegevens gedeeltelijk te beperken. Bijvoorbeeld wanneer een gebruiker alleen documenten voor zijn organisatie zou moeten zien. In dergelijke gevallen gebruikt 1C een mechanisme om de toegang op recordniveau te beperken (de zogenaamde RLS - Record Level Security).

Laten we bijvoorbeeld zeggen dat we voor de volgende taak staan. Het bedrijf voert een boekhouding voor meerdere bedrijven en elke tegenpartij en databasegebruiker behoort tot een specifieke organisatie. Het is noodzakelijk om toegang te verlenen tot de directory “Aannemers” op een zodanige manier dat elke gebruiker alleen voor zijn eigen organisatie aannemers kan bekijken, bewerken en toevoegen.

Om het probleem op te lossen, gebruiken we het 1C: Enterprise 8.2-platform. Laten we een nieuwe configuratie maken in de eigenschappen waarvan de optie "Beheerde applicatie" wordt geselecteerd als de hoofdstartmodus.

Vervolgens maken we een map "Organisaties" en nog twee mappen - "Aannemers" en "Gebruikers" met het kenmerk "Organisatie". Naast de mappen hebben we twee sessieparameters nodig: "Organisatie" en "Gebruiker" (van de overeenkomstige typen). De waarden van deze parameters worden ingesteld wanneer u een configuratiesessie start en worden opgeslagen totdat deze eindigt. Het zijn de waarden van deze parameters die we zullen gebruiken bij het toevoegen van voorwaarden voor het beperken van toegang op recordniveau.

Sessieparameters worden ingesteld in een speciale module - "Sessiemodule"

In deze module beschrijven we de voorgedefinieerde procedure “SettingSessionParameters” waarin we de functie van de eerder voorbereide algemene module “FullRights” noemen. Dit is nodig vanwege de eigenaardigheden van de databasebewerking in de beheerde toepassingsmodus, wanneer een deel van de programmacode alleen op de server kan worden uitgevoerd (ik zal in dit artikel niet ingaan op de uitleg van deze principes).

Code 1C v 8.x Procedure voor het instellen van sessieparameters (vereiste parameters)
FullRights.SetSessionParameters ();
Einde van de procedure

Vink in de eigenschappen van de module "FullRights" de selectievakjes "Server", "Serveroproep" en "Privileged" aan (dit laatste betekent dat de procedures en functies van deze module worden uitgevoerd zonder controle van toegangsrechten). De moduletekst ziet er als volgt uit:

Code 1C v 8.x Functie Bepaal Huidige Gebruiker ()
CurrentUser = Directories.Users.FindByDesign (Gebruikersnaam (), True);
TekGebruiker retourneren;
Eindfunctie

Procedure SetSessionParameters () Exporteren
CurrentUser = DefineCurrentUser ();
CurrentOrganization = Directories.Organizations.EmptyLink ();
Indien ValueFilled (huidige gebruiker) dan
CurrentOrganization = CurrentUser.Organization;
Stop als;
Sessie-opties. Gebruiker = Huidige Gebruiker;
Sessieparameters.Organisatie = HuidigeOrganisatie;
Einde van de procedure

Functie SessionParameter Set (OptionName) Export
Return ValueFilled (SessionParameters [ParameterName]);
Eindfunctie

Functie Rolgebruiker beschikbaar (rolnaam) Exporteren
RolBeschikbaar retourneren (rolnaam);
Eindfunctie

In de beheerde applicatiemodule zullen we controleren op de aanwezigheid van een configuratiegebruiker in de map "Gebruikers" (voor de eenvoud zoeken we deze op naam) en sluiten het systeem af als het niet wordt gevonden. Dit is nodig om ervoor te zorgen dat de sessieparameters worden ingevuld.

Code 1C v 8.x Procedure voordat de systeemwerking wordt gestart (storing)
// we zullen iedereen, behalve de beheerder, controleren op aanwezigheid in de map "Gebruikers"
Indien niet FullRights.RoleGebruiker beschikbaar ("FullRights"), dan
Indien NIET FullRight.SessionParameterSetted ("Gebruiker") Dan
Waarschuwing ("Gebruiker" "" + Gebruikersnaam () + "" "niet gevonden in de directory!");
Weigering = waar;
Opbrengst;
Stop als;
Stop als;
Einde van de procedure

Nu kunnen we direct naar de beschrijving van toegangsbeperkingen gaan. Om dit te doen, maakt u de rol "Gebruiker" aan en gaat u naar het tabblad "Constraint-sjablonen", waar we een nieuwe "AccountsReadEdit"-sjabloon toevoegen met de volgende sjabloontekst: WHERE Organisatie = Organisatie # Parameter (1)

De tekst van de beperkingssjabloon is een uitbreiding van de querytaal. In tegenstelling tot een regulier verzoek, moet de tekst van de beperking noodzakelijkerwijs de voorwaarde "WAAR" bevatten. De waarden van de sessieparameters met dezelfde naam worden gebruikt als de waarden van de queryparameters (in ons geval is dit "& Organization"). Constructie van het formulier # Parameter (1) betekent dat het systeem deze plaats zal vervangen door de tekst die als eerste parameter is doorgegeven op de plaats waar de sjabloon wordt gebruikt. Met behulp van de gegeven sjabloon wordt elk record van de tabel gecontroleerd (in ons geval is dit de map "Aannemers"). Voor records waarvan de waarde van het attribuut "Organisatie" overeenkomt met de waarde die is opgegeven in de overeenkomstige parameter van de sessie, wordt voldaan aan de voorwaarde die wordt beschreven in de sjabloon. Deze records zijn dus beschikbaar voor lezen, wijzigen of toevoegen (afhankelijk van op welke van deze rechten het sjabloon van toepassing is). Ik zal het bovenstaande demonstreren met ons voorbeeld.

Laten we naar het tabblad "Rechten" van de rol "Gebruiker" gaan en de lijst met rechten openen in de map "Aannemers". We zullen de beperkingssjabloon "AccountsReadingChange" gebruiken voor de rechten "Lezen", "Wijzigen" en "Toevoegen".

Voor het recht "Lezen" gebruiken we een sjabloon met de parameter "OF ThisGroup". In dit geval mogen gebruikers van deze rol niet alleen de items van de directory "Contractors" van hun organisatie lezen, maar ook alle groepen van deze directory.

#BusinessReadingChange ("OF deze groep")

Aangezien het systeem bij het toevoegen van nieuwe elementen van de directory impliciet vooraf gedefinieerde attributen leest (dit is bijvoorbeeld nodig voor nummering), moet ervoor worden gezorgd dat deze velden ongehinderd kunnen worden gelezen. Om dit te doen, voegt u een extra regel met een lege beperkingstekst toe aan de beperkingstabel voor gegevenstoegang en vermeldt u de velden waarvoor deze regel van toepassing is - Link, Gegevensversie, Bovenliggend, Code.

Zo is de taak van het beperken van toegang op recordniveau opgelost. Gebruikers met actieve beperkingen hebben alleen toegang tot het bekijken en bewerken van gegevens vanuit hun eigen organisatie.

De achtste versie van het 1C: Enterprise-platform (vandaag 8.3) bracht veel veranderingen met zich mee ten opzichte van de "zeven", waaronder het mechanisme voor het beperken van toegangsrechten op recordniveau. Hoewel u in theorie zonder kunt, door alleen rollen te gebruiken, kunt u met RLS de toegang nauwkeuriger afstemmen. Maar voor de juiste werking van dit mechanisme, moet je de essentie ervan goed begrijpen en voldoende ervaring hebben met ontwikkeling in 1C.

Wat is RLS?

De essentie van deze functionaliteit is het vermogen van de ontwikkelaar om te voorkomen dat een bepaalde gebruiker of groep gebruikers toegang krijgt tot tabellen of velden van databasetabellen. Meestal worden beperkingen gebruikt om te voorkomen dat 1C-gebruikers vertrouwelijke, geheime informatie kunnen zien en bewerken, bijvoorbeeld om werknemers van een bedrijf dat tot een groep behoort te beperken door documenten alleen voor hun organisatie te bekijken. Ook kan het mechanisme voor het beperken van toegangsrechten op recordniveau worden gebruikt om onnodige informatie uit de interface te verwijderen.

Om verzoeken voor RLS-beperkingen te kunnen schrijven, moet u een rol maken of een bestaande nemen. De RLS-instelling in 1C 8.3 kan worden gebruikt voor de volgende gebruikersacties:

• toevoegen;
• Lezing;
• Verwijdering;
• De verandering.

Naast de breedste mogelijkheden om toegang te configureren, heeft RLS ook nadelen:

1. Vereisten voor de kwalificaties van de ontwikkelaar, aangezien het verzoek in een ingebedde taal moet worden geschreven, rekening houdend met de syntaxisregels;
2. Onvermogen om de voorwaarde snel te debuggen;
3. Beperkte mogelijkheden om de logica te beschrijven: er zullen nog te complexe voorwaarden in de modules van documenten en naslagwerken geschreven moeten worden;
4. In de client-serverversie van de databases is de impliciete groei van de tabellen in de query mogelijk. Bovendien is het erg moeilijk om dit proces te volgen;
5. Benodigde bronnen. RLS-beperkingen verbruiken veel client- en serververmogen;
6. Schaarse documentatie in het publieke domein.

Rapporten kunnen een ander probleem worden dat zich kan voordoen na het instellen van 1C RLS. Feit is dat de ontwikkelaars voorzien in mogelijke RLS-beperkingen en rapporten zo bouwen dat ze alleen toegestane gegevens tonen. Als gebruikers verschillende RLS-beperkingen hebben geconfigureerd, kunnen de gegevens in het rapport voor dezelfde parameters voor hen verschillen. Dit kan twijfelachtig zijn, dus houd rekening met deze situaties bij het ontwerpen van rapporten of het schrijven van query's in RLS.

Een RLS-beperking maken

Om een ​​RLS-beperking toe te voegen, moet u de vereiste rol zoeken en erop dubbelklikken om deze te openen.

Het geopende venster bevat 2 tabbladen: "Rechten" en "Sjablonen met beperkingen". Om bepaalde beperkingen op te leggen aan een specifieke actie, moet u deze selecteren en op het groene plusje rechtsonder klikken. Er verschijnt een regel waarin we de beperkingen van 1C RLS kunnen instellen in de taal die in 1C is ingebouwd.

Als u de 1C-syntaxis kent (zoals uw broekzak), dan kunt u rechtstreeks in het veld "Toegangsbeperking" schrijven. 1C-ontwikkelaars hebben de mogelijkheid geboden om een ​​queryontwerper te openen, die u zal helpen en u zal vertellen waarop de beperking kan worden toegepast. Om het te openen, moet u op de knop met drie stippen (Selecteren) of F4 klikken en er verschijnt een venster met de knop "Query constructor ...".

In het venster dat verschijnt, kunt u beperkingen configureren, niet alleen voor dit naslagwerk, maar ook voor andere objecten van het systeem. Om dit te doen, voegt u ze toe op het tabblad "Tabellen en velden". We registreren de beperkingen op de velden van het naslagwerk "Nomenclatuur" en klikken op "OK". Let op de namen van de variabelen: RLS-parameters worden ingesteld aan het begin van een gebruikerssessie en moeten in het metadata-object zijn opgenomen.

Op het tabblad "Beperkingssjablonen" kunt u de verzoeken instellen die nodig zijn bij het kopiëren van dezelfde RLS-instellingen in 1C 8.3. Nadat u uw sjabloon hebt toegevoegd, kunt u de naam ervan raadplegen in de instellingen voor toegangsrechten.

Het is ook mogelijk om tegelijkertijd beperkingen op meerdere rollen toe te voegen. Om dit te doen, klikt u in de configuratiestructuur met de rechtermuisknop op het gedeelte "Rollen" en selecteert u "Alle rollen".

Als conclusie wil ik opmerken dat dit artikel gericht is op consultants-ontwikkelaars van 1C en in de eerste plaats degenen kan helpen die al ervaring hebben met ontwikkeling op 1C: Enterprise. Ondanks de ogenschijnlijke eenvoud vereist kennis van de semantiek en begrip van de inrichting van bedrijfsprocessen van uw eigen onderneming of de organisatie van de klant voor de juiste verdeling van rechten een bepaald niveau van kennis en ervaring.

In dit artikel zal ik je vertellen hoe het configuratiemechanisme "toegangsbeperking op recordniveau" werkt in 1C: UPP 1.3. De informatie voor het artikel is verzameld voor mei 2015. Sindsdien is de UPP niet radicaal vernieuwd, want 1C koos voor 1C: ERP als vlaggenschip. Toch werkt het SCP in veel ondernemingen goed, daarom plaats ik de resultaten van mijn onderzoek naar RLS in het SCP in dit artikel. Er komt vast wel iemand van pas.

Alles is droog, gecomprimeerd en zonder water. Wat hou ik van))).

Instellingen voor toegangsrechten.

Het schema van interactie van objecten.

In UPP 1.3 wordt de toegangscontrole uitgevoerd door het subsysteem "Toegangscontrole" vanaf BSP versie 1.2.4.1.

Metadata gebruikt in het SCP toegangscontrolesysteem:

1. Referentie voor gebruikersautoriteitprofielen
2. Informatieregister "Waarden aanvullende gebruikersrechten"
3. Plan van kenmerkende typen "Gebruikersrechten"
4. Directory "Gebruikers"
5. Systeemmap "Informatiebeveiliging gebruikers"
6. Directory "Gebruikersgroepen"
7. Register van informatie "Gebruikersinstellingen"
8. Plattegrond kenmerktypes "Gebruikersinstellingen"
9. Opsomming "Soorten toegangsobjecten"
10. Informatieregister "Toewijzing van toegangsbeperkingen"
11. Toegang tot objectgegevensgebieden Opsomming
12. Informatieregister "Instellingen gebruikerstoegangsrechten"
13. Sessieparameter "Gebruik beperking door"<ВидДоступа>».

Schakelt toegangsbeperkingen in op recordniveau.

Toegangsbeperking op recordniveau (RLS) is ingeschakeld op de interface
Gebruikersbeheer -> Toegang op recordniveau -> Opties.

Toegang op recordniveau wordt gedefinieerd via toegangsobjecttypen. Lijst met typen toegangsobjecten (overeenkomstige naslagwerken staan ​​tussen haakjes):

• "Tegenpartijen" ("Tegenpartijen")
• "Organisaties" ("Organisaties")
• "Individuen" ("Individuen")
• "Projecten" ("Projecten")
• "Magazijnen (" Magazijnen (opslaglocaties) ")
• "Kandidaten" ("Kandidaten")
• "Notities" ("Soorten notities")
• "Onderverdelingen" ("Onderverdelingen")
• "Onderdelen van organisaties" ("Onderdelen van de organisatie")
• "Nomenclatuur (wijziging)" ("Nomenclatuur")
• "Specificaties" ("Specificaties")
• "Artikelprijzen" ("Artikelprijssoorten")
• "Externe behandelingen" ("Externe behandelingen")

* De lijst met mogelijke soorten toegang is vast en is opgenomen in de opsomming "Soorten toegangsobjecten".

Zie "Gebruikersbevoegdheidsprofielen".

Het configureren van toegang tot infobase-objecten begint met het configureren van een gebruikersmachtigingsprofiel.

Profiel brengt samen

• set rollen - toegangsrechten tot objecten
• aanvullende gebruikersrechten - rechten op de functionaliteit van het programma.

Het resultaat van het aanmaken van een profiel is een inschrijving in het informatieregister "Waarden aanvullende gebruikersrechten".
Dit register wordt niet gebruikt in de radaropstelling.

Voor een profiel of gebruiker kunnen aanvullende rechten worden vastgelegd. Als er bovendien aanvullende rechten voor het profiel zijn geconfigureerd en het profiel is gekoppeld aan de gebruiker, kunnen de aanvullende rechten niet afzonderlijk voor de gebruiker worden geconfigureerd.
* De lijst met rechten is weergegeven in termen van de soorten kenmerken "Gebruikersrechten"

Het profiel zelf in de tabelsectie "samenstelling van rollen" bevat al die rollen die ervoor zijn ingeschakeld. Wanneer de samenstelling van de rollen van het profiel wordt gewijzigd, wordt de tabelsectie "Rollen" van alle gebruikers van de infobase (niet de directory "Gebruikers") aan wie dit profiel is toegewezen, opnieuw gevuld.

De koppeling tussen de map "Gebruikers" en "Gebruikers van de informatiebank" wordt geïmplementeerd via het kenmerk "IBUserID" van het referentieboek "Gebruikers", waarin de IB-gebruikers-GUID is opgeslagen.

De samenstelling van gebruikersrollen kan ook niet worden bewerkt als aan de gebruiker een specifiek profiel is toegewezen.

Het is mogelijk voor de gebruiker om "Gebruikersinstellingen" te specificeren. Dit zijn verschillende service-instellingen voor het typische automatische gedrag van het systeem in bepaalde situaties.

Het resultaat van de instellingen wordt in het informatieregister "Gebruikersinstellingen" geschreven.

De lijst met instellingen en hun mogelijke waarden is opgenomen in de tabel met kenmerkende typen "Gebruikersinstellingen".
* Niet gebruikt in de instellingen voor het beperken van toegang op recordniveau.

Directory "Gebruikersgroepen".

Wordt gebruikt om gebruikers te groeperen en onder andere om toegangsbeperkingen op recordniveau in te stellen.

Een gebruiker kan in meerdere groepen worden opgenomen.

In de vorm van een gebruikersgroep kunt u een lijst met toegangstypen configureren.

Objectmachtigingen op recordniveau worden alleen geconfigureerd voor groepen gebruikers, niet voor individuele gebruikers.

Als de configuratie toegangsbeperkingen op recordniveau gebruikt, moet elke gebruiker in een van de groepen worden opgenomen.

BELANGRIJK! Gebruikers die niet in een groep zijn opgenomen, kunnen niet met die objecten werken, waarvan de toegang op recordniveau is gedefinieerd. Dit geldt voor alle objecten - ongeacht of de bijbehorende toegangsobjecttypen worden gebruikt of niet.

Indien een gebruiker tot meerdere groepen behoort die verschillende instellingen hebben voor toegangsrechten op recordniveau, dan wordt de toegankelijkheid van het object voor de gebruiker bepaald door de instellingen uit meerdere gebruikersgroepen te combineren met "OF".

BELANGRIJK! Het opnemen van een gebruiker in een groot aantal groepen kan leiden tot prestatieverlies. Daarom moet u de gebruiker niet in een groot aantal groepen opnemen.

Nadat de wijzigingen in de gebruikersgroep zijn vastgelegd, wordt het Informatieregister "Toewijzing van toegangsbeperkingen" gevuld. In dit register worden de nalevingsgegevens van een groep gebruikers voor een bepaald type toegang opgeslagen.

* Case wordt gebruikt in sjablonen voor toegangsbeperkingen

Toegang tot het instellingenformulier.

Het formulier voor het instellen van toegangsbeperkingen op het niveau van records wordt opgeroepen door het commando "Toegang instellen" van het formulier van de lijst van de directory "Gebruikersgroepen".

De tabbladen aan de rechterkant van het formulier bevatten tabellen met instellingen voor elk type toegang gemarkeerd met selectievakjes in de vorm van een gebruikersgroep.

Het formulier voor het instellen van toegangsrechten heeft een aparte formulierpagina voor elk type toegang met zijn eigen set instellingen. De gewenste pagina is geactiveerd wanneer het bijbehorende toegangstype is aangevinkt in de gebruikersgroep.

Vergelijking van soorten toegang en mogelijke instellingen:

Toegangstype	Instellingen voor toegangstype
	Lezing	Opnemen	Overervingstype toegangsrechten	Zichtbaarheid lijst	Aanvullende informatie bekijken	Aanvullende informatie bewerken	Gegevens bekijken	Gegevens bewerken	Bedrijfsprijzen		Partnerprijzen
									Lezing	Opnemen	Lezing	Opnemen
Aannemers
De organisatie
Individuen
projecten
Magazijnen
Kandidaten
Opmerkingen:
onderverdelingen
Onderverdelingen van organisaties
Nomenclatuur
Specificaties:
Artikelprijzen
Externe behandelingen

Toegangsrechten.

"Lezen" - de gebruiker zal het referentieboekitem in de lijst zien en zal het kunnen openen om het te bekijken, hij zal het ook uit de lijst kunnen selecteren bij het invullen van de details van andere objecten.

"Opnemen" - de gebruiker kan het volgende wijzigen:

• elementen van sommige woordenboeken - soorten toegangsobjecten (niet alle - er zijn uitzonderingen, zie hieronder),
• gegevens (documenten, registers, ondergeschikte directory's) die aan deze directory-elementen zijn gekoppeld

Uitzondering: toegang tot elementen van sommige mappen - soorten toegangsobjecten - is niet afhankelijk van het recht "Schrijven". Dit zijn directory's van Organisaties, Afdelingen, Organisatieafdelingen, Magazijnen, Projecten. Ze verwijzen naar de objecten van referentiegegevens, daarom kunnen ze alleen worden gewijzigd door een gebruiker met de rol "Referentiegegevens configureren ...".

Voor het toegangsobjecttype " Nomenclatuur (wijzigen)"Het" schrijf "toegangsrecht is alleen gedefinieerd op groepsniveau van de" Nomenclatuur "directory, er is geen manier om het" schrijf "recht in te stellen voor individueel element naslagwerk.

Beperking van de toegang tot het "lezen" van het naslagwerk "Nomenclatuur" en aanverwante informatie wordt niet verstrekt, omdat het in het algemeen niet duidelijk is wat voor soort toegang tot het document moet zijn, als de lijst van de nomenclatuur in het document, bevat zowel "toegestane" als "verboden »Positie.

Toegangsbeperking voor de directories "Afdelingen" en "Afdelingen van organisaties" is niet van toepassing op informatie over personeelsgegevens, over persoonsgegevens van werknemers en gegevens op de loonlijst.

Gegevensgebieden.

Voor de volgende typen toegangsobjecten zijn gegevensgebieden gedefinieerd:

• Aannemers
• Individuen
• Artikelprijzen

Voor het type toegangsobject "Aannemers"

• Aannemers (lijst)- bepaalt de zichtbaarheid van aannemers in de lijst van de lijst "Aannemers". Hangt af van de waarde van het selectievakje in de kolom "Zichtbaarheid in de lijst".
• Tegenpartijen (aanvullende informatie)- bepaalt de mogelijkheid om een ​​element van de directory "Contractors" en gerelateerde add te "lezen" / "schrijven". informatie (contracten, contactpersonen, enz.). Afhankelijk van de waarde van het selectievakje in de bijbehorende kolommen "Bekijk extra. informatie "/" Bewerken toevoegen. informatie ".
• Aannemers (gegevens)- bepaalt de mogelijkheid om gegevens te "lezen" / "schrijven" (directories, documenten, registers) die verband houden met de directory "Aannemers". Afhankelijk van de waarde van het selectievakje in de kolom "Gegevens bekijken" / "Gegevens bewerken".

Voor het type toegangsobject "Personen" de volgende gegevensgebieden zijn beschikbaar:

• Individuen (lijst)- bepaalt de zichtbaarheid van een persoon in de lijst van de directory "Individuen". Hangt af van de waarde van het selectievakje in de kolom "Zichtbaarheid in de lijst".
• Individuen (gegevens)- bepaalt de mogelijkheid om gegevens te "lezen" / "schrijven" (directories, documenten, registers) die verband houden met de directory "particulieren". Afhankelijk van de waarde van het selectievakje in de kolom "Gegevens bekijken" / "Gegevens bewerken".

Voor het toegangsobjecttype "Artikelprijzen" de volgende gegevensgebieden zijn beschikbaar:

• Bedrijfsprijzen - definieert de mogelijkheid om de prijzen van een bedrijfsartikel te "lezen" / "schrijven".
• Tegenpartijprijzen- bepaalt de mogelijkheid om de prijzen van de nomenclatuur van tegenpartijen te "lezen" / "schrijven".

* Data Areas is een gesloten lijst van elementen, opgenomen in de opsomming "Data Areas of Access Objects"

Toegang tot groepen.

Voor de volgende typen toegangsobjecten worden rechten alleen geconfigureerd via toegangsgroepen (de namen van de directory staan ​​tussen haakjes):

• "Tegenpartijen" ("Tegenpartijtoegangsgroepen")
• "Individuen" ("Individuen hebben toegang tot groepen")
• "Kandidaten" ("Groepen van kandidaten")
• "Artikelspecificaties" ("Gebruiksdoeleinden van de specificatie")

Voor elk element van de directory wordt een toegangsgroep gespecificeerd (in een speciaal attribuut).

Toegangsinstellingen van de "toegangsgroep ..." worden uitgevoerd in de aanvullende vorm van toegangsrechteninstellingen, die wordt aangeroepen door een van de twee opdrachten:

• "Toegang tot de huidige items",
• "Toegang tot de directory als geheel"

in de vorm van een lijst met mappen "Toegang tot groepen ..."

Voorbeeld: Het document "Ontvangstorder voor goederen" wordt beperkt door de soorten toegangsobjecten "Aannemers", "Organisaties", "Magazijnen".

Als u toegang geeft tot een lege waarde voor het toegangstype "Aannemers", ziet de gebruiker documenten waarin de variabele "Aannemer" niet is ingevuld.

Toegang tot een catalogusitem of -groep.

Afhankelijk van waartoe de toegang is geconfigureerd - tot een catalogusitem of tot een groep, werkt de instelling ofwel op het item zelf of op ondergeschikte groepen.

Dienovereenkomstig worden in het formulier "Toegangsrechten instellen" in de kolom "Type overerving van toegangsrechten van hiërarchische mappen" de volgende waarden ingesteld:

• Alleen voor huidig ​​recht- voor een catalogusitem gelden de rechten op het opgegeven item
• Uitbreiden naar ondergeschikten- voor een directorygroep gelden de rechten voor alle ondergeschikte elementen

Na het vastleggen van de instellingen voor toegangsbeperkingen voor gebruikersgroepen in het systeem, wordt het informatieregister "Instellingen gebruikerstoegangsrechten" gevuld.

* Het register wordt gebruikt in sjablonen voor toegangsbeperking.

Sjablonen gebruiken.

Templates in SCP 1.3 worden voor elk type toegang apart geschreven en voor mogelijke combinaties van soorten toegang, in de regel per gebruikersgroep.

bijvoorbeeld , in de demoversie van de UPP is de gebruikersgroep "Aankopen" geconfigureerd. Voor deze groep is het gebruik van de toegangstypes "Organisaties", "Aannemers", "Magazijnen" ingeschakeld. Daarom zijn er in het systeem een ​​aantal sjablonen voor toegangsbeperkingen aangemaakt:

• "Organisatie"
• "Organisatie_Record"
• "Tegenpartijen"
• "Contractors_Record"
• "Magazijnen"
• "Magazijnen_Record"
• "TegenpartijOrganisatie"
• "TegenpartijOrganization_Record"
• "Organisatie Magazijn"
• "OrganisatieWarehouse_Record"
• "TegenpartijOrganisatieWarehouse_Record"
• "Tegenpartij Magazijn"
• "TegenpartijWarehouse_Record"

Dat wil zeggen, alle mogelijke combinaties van toegangstypes die in toegangsbeperkingsteksten kunnen worden gebruikt.

Over het algemeen is het sjabloonconstructieschema hetzelfde voor alle soorten toegang en ziet het er als volgt uit:

1. Het controleren van de opname van het aangevinkte type toegang.
2. De zoekopdracht "Gebruikersgroepen" is gekoppeld aan de hoofdtabel en er wordt gecontroleerd of de gebruiker in ten minste één groep is opgenomen.
3. Aan het informatieregister "Toewijzing van soorten toegangswaarden" is de registertabel "Instellingen van gebruikerstoegangsrechten" volgens de verbindingsvoorwaarden toegevoegd - Het toegangsobject is de toegangswaarde die is doorgegeven aan de sjabloonparameter. - Access-objecttype - hangt af van de context van sjabloonontwikkeling - Gegevensgebied.- Gebruiker.

Het resultaat van de verbinding bepaalt of toegang wordt toegestaan ​​of niet.

Einde van het tweede deel.