1c rolle som begrenser tilgang til data. RLS - fleksibel og finjustering av begrensninger for datatilgang. Tilgangsbegrensningsmaler

"Rolle"-konfigurasjonsobjektet gir et sett med rettigheter til operasjoner (handlinger) over konfigurasjonsobjekter.

Rolle "Fulle rettigheter".

Dette er bare en rolle (ikke forhåndsdefinert) der avmerkingsboksene for alle typer rettigheter til alle konfigurasjonsobjekter er merket.

Forskjellen fra andre roller er at den har rettigheten "Administrasjon".

Hvis minst én bruker er opprettet, begynner systemet å se etter "Administrasjon"-rettigheten - minst én bruker må ha den.

Begrensning av tilgang på rekordnivå

Row Level Security (RLS) er en begrensning på rekordnivå.

Mekanismen for begrensning av datatilgang lar deg administrere tilgangsrettigheter ikke bare på nivå med metadataobjekter, men også på nivå med databaseobjekter. Følgende objekter kan brukes til å begrense tilgangen til data:

• roller,
• øktparametere,
• funksjonelle alternativer,
• privilegerte delte moduler,
• søkeordet TILLAT på søkespråket.

Mekanismen er designet for å begrense tilgangen til poster i tabellen over metadataobjekter av vilkårlige betingelser som er pålagt verdiene til feltene i radene i disse tabellene. For eksempel å se poster kun for "egne" motparter, organisasjoner osv.

Teknisk implementering av tilgangsbegrensninger i 1C

1C genererer en forespørsel til DBMS. Serverklyngen legger til WHERE-delen til forespørselen, som inneholder teksten til betingelsen for å begrense tilgang via RLS, så sendes denne forespørselen til DBMS, de utpakkede dataene returneres til 1C-klienten.

Denne mekanismen vil fungere for enhver forespørsel fra klienten:

• i rapporter,
• i dynamiske lister og i vanlige listeformer
• i vilkårlige spørsmål.

Denne implementeringen av mekanismen påvirker ytelsen i stor grad.

Måter å omgå tilgangsbegrensninger.

Ved store ressurskrevende operasjoner (for eksempel behandling av dokumentrepostering) kan en del av koden flyttes til privilegerte moduler.

EN) Priviligert modul Er en felles modul med "Privileged"-flagget i egenskapene.

Dens særegenhet ligger i det faktum at koden i den utføres uten noen tilgangskontroll, inkludert RLS.

B) Også privilegert modus kan slås på for dokumentobjektmoduler... Dette gjøres i dokumentegenskapene, flagget

• Privilegert modus når du dirigerer
• Privilegert modus ved avbestilling

B) Metode SetPrivilegedMode ()

Systemkommandoen lar deg gjøre en del av koden til enhver modul privilegert.

Fra neste kodelinje vil den privilegerte utførelsesmodusen være i kraft.

Den vil fungere til linjen for å deaktivere denne modusen eller til slutten av prosedyren / funksjonen.

(Sannhet);

// enhver kode her vil bli utført uten rettighetskontroll og RLS

Installer Privileged Mode(Å ligge ); // hver ende av prosedyre / funksjon

Antallet privilegerte modus slår på må samsvare med antallet avstengninger. Imidlertid, hvis den privilegerte modusen ble slått på (en gang eller flere) innenfor en prosedyre eller funksjon, men den ikke ble slått av, vil systemet automatisk slå seg av så mange ganger som det var ventende påslag i prosedyren eller funksjonen som skal forlates .

Hvis en prosedyre eller funksjon kaller en metode Installer Privileged Mode(False) gjort mer enn metodekall Installer Privileged Mode(True) da vil et unntak bli kastet

Funksjon Privilegert modus() returnerer True hvis privilegert modus fortsatt er aktivert, og False hvis den er fullstendig deaktivert. Dette analyserer ikke antall privilegerte modusinnstillinger i en bestemt funksjon.

Alle kalte prosedyrer og funksjoner vil også bli utført i privilegert modus.

Det er også mulig å starte en privilegert økt. Dette er en økt der privilegert modus er etablert helt fra begynnelsen av systemet. Dessuten, under drift, metoden Privilegert modus() vil alltid returnere True, og muligheten til å deaktivere privilegert modus støttes ikke. Bare en bruker med administrative rettigheter (Administrasjonsrettigheter) kan starte en privilegert økt. Sesjonen kan startes ved å bruke kommandolinjebryteren for å starte klientapplikasjonen UsePrivilegedMode eller parameteren til tilkoblingsstrengen med prmod infobase.

Spørsmålet dukker naturligvis opp: Hvorfor da bry seg med å konfigurere tilgangsbegrensninger hvis det kan omgås så enkelt?

Sikkerhetsmodus.

Ja, det er mulig å skrive ekstern behandling med privilegert utførelsesmodus og laste ut / korrupte data. For å forhindre dette har systemet en global kontekstmetode

Still inn sikker modus().

Sikker modus ignorerer også privilegert modus.

Den må installeres før du programmerer eksterne behandlere eller eksporterer prosedyrer og funksjoner fra deres moduler.

Kaster et unntak når du utfører forbudte operasjoner under kjøring.

I tillegg, for brukere, kan du deaktivere muligheten til interaktivt å starte eksterne rapporter og behandlinger på rollekonfigurasjonsnivå.

Konfigurere tilgangsbegrensning

RLS kan bare konfigureres for rettigheter:

• les (velg)
• legge til (sett inn)
• endre (oppdatering)
• slette

For leseoperasjoner og sletting, må objektet som ligger i databasen overholde datatilgangsbegrensningen.

For å legge til operasjon datatilgangsbegrensningen må samsvare med objektet du planlegger å skrive til databasen.

For endringsoperasjon Objektet må overholde datatilgangsbegrensningen både før endringen (for at objektet skal leses) og etter endringen (for at objektet skal skrives).

For alle andre rettigheter er dette ikke mulig.

La oss legge til en ny begrensning for «lese»-retten til oppslagsboken «Nomenklatur». En liste over felt som du kan konfigurere den ekstra begrensningen for, åpnes.

Dette betyr at når du prøver å få tilgang til de avmerkede feltene, vil begrensningen fungere, og når du prøver å få tilgang til uavmerket felt, vil ikke begrensningen fungere.

Hvis du velger flagget " Andre felt", Begrensningen vil bli konfigurert for alle felt i tabellen, bortsett fra feltene som begrensninger er eksplisitt spesifisert for.

* Funksjon: for å legge til, endre, slette rettigheter:

• Begrensningen kan bare konfigureres for alle felt.
• Det kan bare være én begrensning.

Flere betingelser kan konfigureres for "Les" høyre, de vil bli kombinert med den logiske operatoren "AND".

I begrensninger på databaseobjekter av følgende typer, kan ikke alle feltene i hoveddataobjektet til begrensningen brukes:

• i akkumuleringsregistre kan tilgangsbegrensninger kun inneholde målinger av hovedobjektet for restriksjoner;
• i regnskapsregistre i restriksjoner kan kun saldodimensjoner av hovedobjektet for restriksjoner brukes

Hvis det i betingelsene for å begrense tilgangen til dataene i omsetningsregisteret for akkumulering brukes dimensjoner som ikke er inkludert i totalsummene, blir ikke de lagrede totalene brukt ved tilgang til den virtuelle omsetningstabellen, og spørringen utføres helt i henhold til til transaksjonstabellen.

Mekanismen for å pålegge tilgangsbegrensninger.

Enhver operasjon på data lagret i en database i 1C: Enterprise fører til slutt til et kall til databasen med en forespørsel om å lese eller endre data. I prosessen med å utføre spørringer til databasen, pålegger de interne mekanismene til 1C: Enterprise tilgangsbegrensninger. Hvori:

• En liste over rettigheter er under utarbeidelse(les, legg til, endre, slett), en liste over databasetabeller og en liste over felt som brukes av denne spørringen.
• Av alle rollene til gjeldende bruker tilgangsbegrensninger er valgt til dataene for alle rettigheter, tabeller og felt som er involvert i spørringen. Videre, hvis en rolle ikke inneholder begrensninger på tilgang til data i en tabell eller et felt, betyr dette at verdiene til de nødvendige feltene fra en hvilken som helst post er tilgjengelig i denne tabellen. Med andre ord betyr fraværet av restriksjoner på tilgang til data at det er en WHERE sann begrensning.
• De gjeldende verdiene for alle sesjonsparametere og funksjonelle alternativer oppnås deltar i de valgte begrensningene.

For å få verdien av en sesjonsparameter eller funksjonelt alternativ fra gjeldende bruker, er det ikke nødvendig å ha rett til å få denne verdien. Men hvis verdien til en sesjonsparameter ikke ble angitt, vil det oppstå en feil og databasespørringen vil ikke bli utført.

Begrensninger hentet fra én rolle kombineres ved å bruke OG-operasjonen.

Begrensninger oppnådd fra forskjellige roller ELLER sammen.

De konstruerte betingelsene legges til SQL-spørringene som 1C: Enterprise adresserer DBMS med. Ved tilgang til data fra siden av tilgangsbegrensningsvilkår, utføres ingen rettighetskontroll (verken til metadataobjekter eller databaseobjekter). Dessuten avhenger mekanismen for å legge til betingelser av den valgte handlingsmetoden for restriksjonene "alle" eller "tillatt".

* Funksjon: Hvis brukeren har tilgang til flere roller med konfigurerte restriksjoner på postnivå til ett objekt, blir i dette tilfellet betingelsene for restriksjonene lagt til av den logiske "ELLER"-operasjonen. Med andre ord, brukerens krefter går opp.

Dette fører til følgende konklusjon: ikke tillat overlapping av tilgangsbegrensningsbetingelsen til det samme objektet i forskjellige roller, fordi i dette tilfellet vil spørringsteksten være svært komplisert og dette vil påvirke ytelsen.

"Alle"-metoden.

Når det pålegges restriksjoner på «alle»-måten, legges vilkår og felt til SQL-spørringer slik at 1C: Enterprise kan få informasjon om hvorvidt dataene som er forbudt for denne brukeren ble brukt under utføringen av en spørring til databasen. Hvis de forbudte dataene ble brukt, igangsettes en unormal avslutning av forespørselen på grunn av tilgangsbrudd.

Innføringen av tilgangsbegrensninger på "alle"-måten er vist skjematisk i figuren:

Metode "Tillat".

Når det pålegges begrensninger på den "tillatte" måten, legges betingelser til SQL-spørringer slik at poster som er forbudt av gjeldende bruker ikke påvirker søkeresultatet. Med andre ord, når begrensninger pålegges i "tillatt" modus, anses postene som er forbudt for denne brukeren fraværende og resultatet av operasjonen ikke påvirkes, som er skjematisk vist i figuren:

Datatilgangsbegrensninger pålegges databaseobjekter når 1C: Enterprise får tilgang til databasen.

I klient-serverversjonen av 1C: Enterprise pålegges begrensninger på 1C: Enterprise-serveren.

Dette alternativet (TILLATT) vil imidlertid ikke fungere hvis vi i spørringen viser til en tabell som det ikke er konfigurert tilgangsbegrensninger for, men som inneholder lenker til tabellrader med konfigurerte begrensninger. I dette tilfellet vil søkeresultatet returnere "<Объект не найден>... ... "i stedet for verdien til referansefeltet.

Hvis du utvikler en rapport eller behandler ved å bruke typiske eller selvskrevne konfigurasjonsspørringer, sjekk alltid "Tillatt" for å få rapporten til å fungere under enhver bruker med ethvert sett med rettigheter.

Ved objektlesing av data fra databasen er det ingen måte å sette flagget "Tillatt". Derfor er det nødvendig konfigurere filtre for objektlesing under hensyntagen til mulige tilgangsrettighetsbegrensninger for brukeren. Det er ingen midler for å innhente kun tillatte data innen objektteknologi.

Det er viktig at hvis spørringen ikke spesifiserer nøkkelordet ALLOWED, så må ikke alle valgene som er spesifisert i denne spørringen motsi noen av begrensningene for lesing av databaseobjekter som brukes i spørringen. Dessuten, hvis spørringen bruker virtuelle tabeller, må de tilsvarende valgene pålegges selve de virtuelle tabellene.

Øvelse 1. Konstruktøren av spørringer i RLS-innstillingene.

La oss komponere teksten til "HVOR"-delen i forespørselen til oppslagsboken. Du kan bruke spørringsdesigneren.
Konstruktøren har et nedstrippet utseende.

Fanen "tabeller"

Hovedtabellen vil være tabellen for objektet som begrensningen konfigureres for.

Du kan også velge andre tabeller og sette opp ulike lenker mellom dem på fanen "Koblinger".

Betingelser-fanen

Her kan du konfigurere de faktiske tilgangsbegrensningsforholdene.

La oss legge til betingelser for "Pris"-variabelen i nomenklaturreferanseboken for rett til å "lese" til alle felt i tabellen.

"Nomenklatur HVOR Nomenklatur. Pris> 500"

La oss se hvordan denne enkle regelen fungerer. Referansetabellen inneholder følgende elementer:

Etter å ha konfigurert tilgangsbegrensningen, vil tabellen bare vise elementene som oppfyller betingelsen:

Gruppene forsvant også. Endre restriksjonsteksten

"Nomenklatur HVOR Nomenklatur. Pris> 500

ELLER Nomenklatur. Dette er en gruppe "

Vel, nå er det det du trenger.

Hvis du deaktiverer visningen av "kode"-feltet i listeinnstillingene, vil alle elementene i katalogen vises, dvs. begrensningen virket ikke. Hvis du setter skjermen til "Kode"-feltet, vil begrensningen fungere.

På samme tid, til tross for at katalogelementet er synlig i listefeltet, kan ikke skjemaet åpnes, fordi en begrensning på attributtet er konfigurert. Det samme er i en vilkårlig forespørsel: når du prøver å få et "begrenset" attributt, vil det være en tilgangsfeil.

Hvis du prøver å få de "begrensede" rekvisittene programmatisk, vil det også bli kastet en tilgangsfeil.

Dessuten vil det ikke være mulig å få tilgang til noen felt i et objekt gjennom en lenke, fordi når en lenke mottas, leser systemet hele objektet som en helhet, og hvis det inneholder "begrensede" detaljer, vil objektet ikke bli lest .

Derfor, når du arbeider programmatisk med databaseobjekter, må du huske på mulige begrensninger på postnivå og få alle nødvendige objektdata med en spørring og deretter plassere dem i en struktur eller kjøre en del av koden i en privilegert modul.

Etter å ha satt opp tilgangsbegrensningen, endret visningen av linjen i listen over rettigheter - den ble grå og ikonet dukket opp.

Begrensninger ved konfigurering av tilgang (RLS).

• Det er ingen sammendragsseksjon;
• Virtuelle registertabeller kan ikke åpnes;
• Du kan ikke eksplisitt bruke parametere;
• Undersøk kan bruke alle> / span> søkespråkfasiliteter, unntatt:
  • operatør I HIERARKIET;
  • forslag RESULTATER;
  • resultater for undersøk må ikke inneholde tabellseksjoner> / span>;
  • virtuelle tabeller, spesielt saldoer og omsetninger

Praksis 2. Nomenklatur med gjeldende pris.

Begrens tilgang hvis du vil vise en vare med gjeldende pris høyere enn en viss verdi, for eksempel 100.

Løsning:

Legg til en ny regel for å begrense tilgangen til "Nomenklatur"-oppslagsboken for "lese"-rettigheten.
Vi velger "andre felt".
I konstruktøren legger du til en underspørring. I den velger du tabellen til informasjonsregisteret "Varepriser".
Det er ingen "ordre"-fane - dette er en funksjon i spørringsdesigneren for å bygge en tilgangsbegrensningsspørring.
På "Avansert"-fanen, sett "først 999999999", fanen "ordre" har dukket opp.
Sett opp synkende rekkefølge etter "Periode"-feltet.
Deretter setter vi opp forholdet til hovedtabellen med underspørringen ved referanse.

Tilgangsbegrensningsmaler.

Praksis 3. Restriksjon på "motparter" etter verdi i en konstant.

La oss konfigurere tilgangsbegrensninger for Contractors-oppslaget etter verdien som er lagret i konstanten.

I tillegg må du sette opp en begrensning for alle objekter ved å bruke katalogen "Entreprenører" i detaljene.

Løsning

For "Contractors"-oppslag for "les"-rettigheten, vil vi konfigurere begrensningen ved å legge til en underspørring til konstanten i "Betingelser"-delen. Ikke glem denne gruppen.

Vi ser problemet, Counterpartyes-katalogen er filtrert riktig, og alle dokumenter med "Counterparty"-attributtet vises, noen med brutte koblinger i "Counterparty"-variabelen.

Nå må du konfigurere tilgangsbegrensninger for alle objekter ved å bruke lenken til "Entreprenører". La oss finne dem med tjenesten "søk etter lenker til et objekt".

La oss kopiere og endre teksten til RLS-tilstanden litt fra referanseboken "Entreprenører". Dette må gjøres like mange ganger som antall gjenstander som er funnet.

Eller bruk et tilgangsbegrensningsmønster for å unngå problemer med kodeduplisering.

Tilgangsbegrensningsmaler kan konfigureres på rollenivå og kan brukes for ethvert objekt innenfor den redigerte rollen.

Du kan legge til hvilken som helst del av tilgangsbegrensningsteksten i malen. Malen kalles opp gjennom "#"-symbolet. For eksempel # Malentreprenør.

Gjennom # i 1C skrives instruksjoner til forprosessoren. I sammenheng med utførelse avr, erstatter plattformen malteksten med malteksten.

La oss legge teksten etter ordet WHERE inn i malen "TemplateContractor", bortsett fra teksten om ThisGroup.

Parametere i tilgangsbegrensningsmaler.

La oss fortsette å løse oppgave 2.

Problemet ligger nå i at hovedtabellen i katalogen heter "motpart" i dokumentet "Kvittering". Det avkryssede feltet i oppslagsboken kalles "lenke", i dokumentet - "Motpart".

Endre navnet på hovedtabellen i teksten til malen til "#CurrentTable"

"#CurrentTable" er en forhåndsdefinert parameter.

Og gjennom en prikk indikerer vi nummeret på inngangsparameteren - ". # Parameter (1)

"#Parameter" er også en forhåndsdefinert verdi. Den kan inneholde et vilkårlig antall inndataparametere. De blir adressert med sitt ordinære nummer.

I teksten til tilgangsbegrensningen for oppslagsboken vil vi indikere følgende:

For et dokument, følgende:

"Salg av varer HVOR # Malentreprenør (" Motpart ")"

Når du kaller en tilgangsbegrensningsmal, må parametere bare sendes til den som en streng, det vil si i anførselstegn.

Hovedtabell - Nomenklatur

Malteksten er som følger:

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

Malteksten inneholder en del av teksten på språket for datatilgangsbegrensning og kan inneholde parametere som er uthevet med "#"-symbolet.

Tegnet "#" kan følges av:

• Et av nøkkelordene:
  • Parameter, hvoretter nummeret til parameteren i malen er angitt i parentes;
  • CurrentTable - betegner innsetting i teksten av det fulle navnet på tabellen som begrensningen bygges for;
  • NameCurrentTable- angir innsettingen i teksten av det fulle navnet på tabellen (som en strengverdi, i anførselstegn), som instruksjonen brukes på, i gjeldende versjon av det innebygde språket;
  • NameCurrentAccess Rights- inneholder navnet på rettigheten som gjeldende begrensning utføres for: LES / LES, LEGG TIL / INSERT, ENDRE / OPPDATERING, SLETT / SLETT;
• navnet på malparameteren - betyr innsetting av den tilsvarende malparameteren i teksten til begrensningen;
• symbol "#" - angir innsetting av ett symbol "#" i teksten.

Et tilgangsbegrensningsuttrykk kan inneholde:

• Tilgangsbegrensningsmal, som er spesifisert i formatet #TemplateName ("Malparameterverdi 1", "Malparameterverdi 2", ...)... Hver malparameter er omgitt av doble anførselstegn. Hvis du trenger å angi et dobbelt anførselstegn i parameterteksten, bruk to doble anførselstegn.
• Funksjon StrContains (WhereLooking, WhatLooking)... Funksjonen er laget for å søke etter en forekomst av linjen WhatSeeking i linjen WhereSeeking. Returnerer True hvis en forekomst blir funnet og False ellers.
• Operator + for strengsammenkobling.

For å gjøre det enklere å redigere malteksten, klikk på Angi maltekst-knappen i kategorien Begrensningsmaler i rolleskjemaet. I dialogen som åpnes skriver du inn malteksten og klikker på OK-knappen.

De kan ikke installeres med metoden SetParameter () eller noe lignende.

Parametrene i dette tilfellet er:

• Sesjonsparametere
• Funksjonelle alternativer

Lesing av øktparametere i en tilgangsbegrensningsforespørsel skjer i privilegert modus, det vil si uten å kontrollere rettighetene til å operere med dem.

Praksis 4. Tilgang til "egne" motparter

Det er nødvendig å sette opp begrensning av tilgang for gjeldende bruker til "egne" motparter.

Det er en katalog "Brukere", en katalog "Motparter", dokumenter med attributtet "Motpart".

Den nåværende brukeren skal kun se data for de motpartene som det er opprettet en forbindelse for.

Tilkoblingen må også konfigureres.

Mulige alternativer:

Etablere forbindelser bruker + motpart

• Requisites i katalogen motparter
• Informasjonsregister

Mulige løsninger på problemet:

• Å lagre brukeren i en konstant er et dårlig alternativ, konstanten er tilgjengelig for alle brukere.
• Å lagre en fast rekke av gjeldende brukers kontoer i sesjonsparametrene er ikke et godt alternativ, det kan være mange motparter
• Å lagre gjeldende bruker i sesjonsparametrene, og deretter hente en liste over "hans" motparter etter forespørsel er et akseptabelt alternativ.
• Andre muligheter.

Løsning.

La oss lage en ny sesjonsparameter "CurrentUser" og registrere utfyllingen i øktmodulen.

La oss opprette et register med informasjon "Overholdelse av ledere og entreprenører"

La oss opprette en ny rolle og i den en ny tilgangsbegrensning for Fakturadokumentet.

I teksten til forespørselen, la oss koble hovedtabellen med informasjonsregisteret etter Counterparty = Counterparty og Manager = & CurrentUser. Tilkoblingstype Intern.

Hvis det er mulig, er det bedre å unngå nestede spørringer i tilgangsbegrensningstekster, siden det vil bli utført hver gang data leses fra dette objektet fra databasen.

Kontroller - restriksjonene fungerer

* Funksjon: Hvis du endrer listen over brukerens motparter i registeret, vil tilgangsbegrensningene tre i kraft umiddelbart uten å starte brukerøkten på nytt.

Praksis 5. Dato for forbud mot endringer.

Det er nødvendig å implementere begrensningen på dataredigering før den fastsatte datoen for forbud mot endringer.
Du må begrense for brukere.

La oss lage et register med informasjon "ChangeDateDates" med dimensjonen User, resourceDefaultDate.

La oss bygge logikken til løsningen på denne måten:

• hvis en bruker ikke er spesifisert, er forbudet gyldig for alle brukere
• dersom det er en begrensning for alle brukere og en begrensning for en bestemt bruker, så er det en begrensning for en bestemt bruker, og for resten etter et generelt prinsipp.

Åpenbart kan en slik begrensning konfigureres for databaseobjekter som har en eller annen posisjon på tidsaksen. Det kan bli

• Dokumentene
• Periodiske registre over opplysninger

La oss opprette en ny rolle "ConstraintsByDateForbidChanges".

I den, for dokumentet "Kvittering Faktura" for rett "endring" legg til en ny tilgangsbegrensning.

Vi angir innstillingen for alle felt.

Begrensningsteksten er som følger:

Inbound Invoice FROM Document Inbound Invoice AS Faktura

ForbudsdatoEndre forbudsdato AS Forbudsdato
FRA

INTERN TILKOBLING (VELG
MAKSIMUM (Prohibited Change Dates.User) AS Bruker
FRA
Datasheet.DatesChange-Prohibit AS DatesChange-Prohibit
HVOR
(ChangeProhibition Dates.User = & CurrentUser
ELLER DatesProhibitingChanges.User = VALUE (Datasheet.users.EmptyRef))) AS OU_User
By DateProhibitionDate.User = OT_User.User) AS NestedRequest
Ved kvittering Invoice.Date> NestedRequest.Inhibit Date

Vi sjekker - begrensningen fungerer.

Bruke instruksjoner for forbehandler

# Hvis betingelse1 # Da

Forespørselskodebit 1

# ElseIf Tilstand2 # Da

Forespørselskodebit 2

#Ellers

Forespørselskodebit 3

#Slutt om

Under forhold kan du bruke logiske operasjoner (og. Eller, ikke, etc.) og tilgang til sesjonsparametere.

Denne tilnærmingen i sammenheng med å konstruere tilgangsbegrensninger er praktisk fordi, avhengig av forholdene, vil en kortere spørringstekst bli kompilert. Og en enklere spørring legger mindre belastning på systemet.

Ulempen er at spørringskonstruktøren ikke vil fungere med slik tekst.

*Særlighet:

I motsetning til instruksjonene for den innebygde språkforbehandleren i tekstene til tilgangsbegrensninger før operatøren Da må du sette en hash - # Deretter

Øvelse 6. Bytt "Bruk RLS"

La oss supplere vårt restriksjonssystem med en bryter som aktiverer/deaktiverer bruk av restriksjon på rekordnivå.

For å gjøre dette, legg til en konstant og en øktparameter kalt "Bruk RLS".

La oss skrive inn sesjonsmodulen og sette sesjonsparameterverdien fra konstantverdien.

Legg til følgende kode i alle tekster for tilgangsbegrensninger:

"# If & Use RLS # Then ... .. # EndIf"

Vi sjekker – alt fungerer.

Men nå etter å ha slått på "bruk radar"-flagget, vil ikke endringene tre i kraft umiddelbart. Hvorfor?

Fordi sesjonsparameteren settes når økten starter.

Du kan gjøre det slik at når du skriver en ny verdi av konstanten, nullstilles verdien av sesjonsparameteren, men dette vil kun fungere for gjeldende brukersesjon. Andre brukere må bli bedt om å starte systemet på nytt.

Slutt på første del.

Skriv ut (Ctrl + P)

Begrensning av tilgang til data

Mekanismen for å begrense tilgangen til data (også kjent som RLS, Row Level Security) lar deg administrere tilgangsrettigheter ikke bare på nivå med metadataobjekter, men også på nivå med objekter i 1C: Enterprise-databasen. For å begrense tilgangen til data kan følgende 1C: Enterprise-objekter brukes:
● roller,
● øktparametere,
● funksjonelle alternativer,
● privilegerte delte moduler,
● nøkkelordet TILLATT på søkespråket.
Deling av de listede objektene gir maksimal fleksibilitet når det er nødvendig å differensiere tilgangsrettigheter til data mellom brukere som utfører forskjellige funksjoner.
Datatilgangsbegrensninger kan pålegges følgende operasjoner med data (tilgangsrettigheter): les (Les høyre), legg til (Legg til høyre), endre (Endre rett) og slett (Slett høyre). Den nåværende brukeren vil kunne utføre den nødvendige operasjonen i følgende tilfeller:
● For lese- og sletteoperasjoner, må objektet i databasen overholde datatilgangsbegrensningen.
● For en add-operasjon må datatilgangsbegrensningen samsvare med objektet du planlegger å skrive til databasen.
● For en endringsoperasjon må objektet overholde datatilgangsbegrensningen både før endringen (for at objektet skal leses) og etter endringen (for at objektet skal skrives).
Når du pålegger datatilgangsbegrensninger, husk at bare én betingelse kan settes for oppdatering, legg til og sletting, og mer enn én datatilgangsbegrensning kan angis for en leseoperasjon. Dette betyr at det kan spesifiseres ulike betingelser for lesing av ulike felt av et objekt, og når man spesifiserer en betingelse kan man spesifisere både navnet på et spesifikt felt og spesialfeltet Andre felt. I det første tilfellet vil betingelsen bare bli pålagt hvis utvalget (som leser data) inneholder et felt som begrensningen er satt for, og i det andre vil begrensningen pålegges alle felt i objektet, bortsett fra felt for som begrensningene er eksplisitt spesifisert. ...
Når du setter en begrensning på et spesifikt felt, vil dette feltet bli lest hvis begrensningen er tilfredsstilt, og når du setter en begrensning på Andre felt, vil objektdata kun leses hvis begrensningen er oppfylt for alle feltene til objektet som er inkludert i forespørsel om datalesing.
For databaseobjekter av følgende typer kan ulike begrensninger pålegges ulike typer endringer (tilføyelse, endring, sletting):
● Utvekslingsplaner,
● Kataloger,
● Dokumenter,
● Planer av karakteristiske typer,
● Kontoplaner,
● Planer over bosettingstyper,
● Forretningsprosesser,
● Oppgaver.
For følgende typer databaseobjekter er det mulig å legge restriksjoner på lesing av ikke bare hele objektet som helhet, men også dets individuelle felt:
● Utvekslingsplaner,
● Kataloger,
● Dokumenter,
● Journaler over dokumenter,
● Planer av karakteristiske typer,
● Kontoplaner,
● Planer over bosettingstyper,
● Register over informasjon,
● Forretningsprosesser,
● Oppgaver.
MERK FØLGENDE! Når du får tilgang til feltene til databaseobjekter ved å bruke egenskapene til brukte objekter fra det innebygde 1C: Enterprise-språket, leses hele objektet, og ikke bare verdien til feltet som brukes. Et unntak er å få en visning når bare verdiene til feltene som deltar i dannelsen av visningen leses.
Tilgangsbegrensninger er inneholdt i roller, de kan spesifiseres for de fleste metadataobjekter, og er skrevet på et spesielt språk som er en undergruppe av spørringsspråket.

Begrensningsspråk for datatilgang

Restriksjoner for datatilgang er beskrevet på et spesielt språk som er en delmengde av spørringsspråket (en detaljert beskrivelse av spørringsspråket. Språket for datatilgangsbegrensning har følgende endringer angående spørringsspråket:
● I en datatilgangsbegrensningsspørring er det alltid én tabell som datakilde – dette er tabellen for objektet som begrensningen brukes på (hovedobjektet for begrensningen).
● Forkortet beskrivelse av forespørselen. Begrensningsspråket for datatilgang bruker bare FROM- og WHERE-delene av spørringsspråket. Så beskrivelsen av søkespråket er som følger:
VELG [TILLATT] [DIVERSE] [ FØRST<Количество> ]
<Utvalgsfeltliste>
[FRA <Список источников> ]
[HVOR<Условие отбора> ]
[LAST AV <Поля группировки> ]
[HA<Условие отбора> ]
[FOR ENDRING [ <Список таблиц верхнего уровня> ]]
Mens beskrivelsen av spørringsspråket for begrensninger for datatilgang er som følger:
[Alias ​​for hovedbegrensningsobjekttabell]
[FRA <Список источников> ]
[HVOR<Условие отбора> ]

Underspørringene som brukes i språket for datatilgangsbegrensning har et begrenset sett med tillatte alternativer;
● Sesjonsparametere og funksjonelle alternativer kan spesifiseres som betingelseselementer;
● Hvor som helst i en begrensning for datatilgang kan du bruke maler som gjør det enklere å skrive restriksjoner.
Hoveddelen av begrensningen er betingelsen som beregnes for hver post i databasetabellen som begrensningen for datatilgang er pålagt. En post anses som tilgjengelig hvis, som et resultat av driften av betingelsen for én post i tabellen for hovedobjektet for restriksjon, en ikke-tom tabell oppnås (dvs. en tabell der det er 1 eller flere poster) . Hvis betingelsen resulterer i en tom tabell, anses posten som betingelsen er oppfylt for på denne måten som utilgjengelig. I tillegg endrer oppføringen av tabellen over hovedobjektet for begrensning
anses som gyldig dersom posten ikke er i strid med begrensningen som er spesifisert for rettigheten, både før endringsoperasjonen utføres, og etter at denne operasjonen er utført.

Tabellfelt

I datatilgangsbegrensninger kan du bruke:
● Tabellfelt for objektet som begrensningen for datatilgang er beskrevet for.
For eksempel, hvis det pålegges en begrensning på lesing av elementer i Contractors-ordboken, kan begrensningen bruke feltene i Contractors-ordboken og dens tabelldeler. Spesielt kan de enkleste restriksjonene for lesing av elementer i Contractors-katalogen se slik ut:

WHERE Name = "Brick Factory"
Eller slik:

HVOR Produkter.= "Mursteinrød"
Where Products er en tabelldel av Contractors-katalogen.
● Felt med tabeller over objekter som er tilgjengelige via lenker i hovedobjektet til begrensningen.
For eksempel, hvis PrimaryManager-attributtet til Counterpartyes-katalogen er av typen lenke til Users-katalogen, kan tilgangsbegrensningen for eksempel ha følgende form:

HVOR MainManager.Code= "Ivanov"
Eller:

HVOR MainManager.PhysicalPerson.Description= "Petrovsky"
● Felt med tabeller over objekter knyttet til hovedobjektet for begrensning av noen betingelser og uttrykk over dem.
For eksempel kan følgende begrensninger pålegges for lesing av elementer i entreprenørkatalogen:

Entreprenører
FRA
Katalog, entreprenører AS entreprenører
VENSTRE LEDD Referanse: Brukere AS-brukere
Programvare = Brukere.
HVOR = "Petrovsky"
Denne begrensningen bruker feltene til varer i brukerkatalogen som er knyttet til denne katalogartikkelen Contractors etter verdien av Navn-feltene.

Nestede søk

Underspørringer brukes til å danne postsett som kan brukes:
● for kobling til tabellen over hovedobjektet for begrensningen;
● brukes som en operand for B- eller NOT B-sammenligningsoperasjoner.
Alle midler for spørringsspråket kan brukes i underspørringer, bortsett fra:
● operatør I HIERARKIET;
● forslag RESULTATER;
● resultater av nestede søk skal ikke inneholde tabelldeler;
● noen virtuelle tabeller, spesielt Saldo og omsetning.
I følgende eksempel på en restriksjon på lesing fra Contractors-katalogen, brukes en underspørring som et postsett for å binde til hovedobjektet for begrensningen:

Entreprenører
FRA
Katalog, entreprenører AS entreprenører
VENSTRE LEDD
(PLUKKE UT
Users.Name, Users.Person
FRA
Referanse: Brukere AS-brukere
HVOR
Brukerkode> "Petechkin") AS-brukere
PÅ Motparter Hovedledernavn = Brukernavn
HVOR Users.Person.Name= "Petrovsky"
Følgende eksempel viser begrensningen på lesing fra PassportDataPhysPersons-katalogen, der en underspørring brukes i
som operanden til sammenligningsoperatoren B:

HVOR
PassdataPhysPhys.PhysFace V
(VELG DIVERSE
Workers.PhysFace SOM EN PERSON
FRA
Informasjonsregister.Ansatte AS Workers)
Hvis det i en underspørring er nødvendig å hente data fra tabelldelen, er det nødvendig å henvise direkte til tabellseksjonen i FROM-delen av underspørringen. For eksempel, i stedet for:

VELG Link AS Link.
Produkter. HVORDAN Navn på produksjon
FRA Katalog, entreprenører
som en spørring omsluttet av en begrensning, bør du bruke:

Sesjonsparametere

Sesjonsparametere kan inkluderes i forespørsler om datatilgangsbegrensning. For eksempel for å lese elementene i katalogen E-postgrupper følgende tilgangsbegrensning kan settes:

HVOR Owner.AccountAccess.User = & CurrentUser
OG Eier.Kontotilgang.Administrasjon= SANN

CurrentUser er en sesjonsparameter

Funksjonelle alternativer

Forespørsler om begrensning av datatilgang kan inkludere funksjonelle alternativer. Kun parameteruavhengige funksjonsalternativer kan brukes. For eksempel, hvis nomenklaturkatalogen har BasicWarehouse-attributtet, kan begrensningen for lesing av dette attributtet se ut som følger:

HVOR & Lagerregnskap = SANN

Hvor Lagerregnskap er et funksjonelt alternativ

Funksjoner ved bruk

I begrensninger på databaseobjekter av følgende typer, kan ikke alle feltene i hoveddataobjektet til begrensningen brukes:
● i akkumuleringsregistre kan tilgangsbegrensninger kun inneholde dimensjoner av hovedobjektet for restriksjoner;
● i regnskapsregistre i begrensninger kan du bare bruke saldodimensjonene til hovedbegrensningsobjektet.
MERK. Hvis det, under betingelser for å begrense tilgangen til dataene i det sirkulerende akkumuleringsregisteret, brukes målinger som ikke er inkludert i totalsummen, da
Når du får tilgang til den virtuelle omsetningstabellen, brukes ikke de lagrede totalsummene, og spørringen utføres utelukkende mot transaksjonstabellen.

Handlinger for tilgangsbegrensninger

Tilgangsbegrensninger kontrolleres når passende operasjoner utføres på databaseobjekter (fra dialogbokser, fra innebygd språk, gjennom spørringer) og kan handle på en av to måter:
● Alt. "Alle"-metoden innebærer at noen operasjoner på data (fra dialoger, fra et innebygd språk eller ved hjelp av spørringer) må utføres på alle databaseobjekter som er implisert av denne operasjonen. Hvis, når du utfører en slik operasjon, må databaseobjekter leses eller endres som de tilsvarende tilgangsbegrensningene ikke er oppfylt for, er operasjonen fullført.
nødsituasjon på grunn av brudd på tilgangsrettigheter.
● Tillatt. Den "tillatte" metoden betyr at når du utfører en operasjon på data, skal bare de databaseobjektene som oppfyller de tilsvarende tilgangsbegrensningene leses. Databaseobjekter som ikke oppfyller tilgangsbegrensningene anses som manglende når en slik operasjon utføres og resultatet av operasjonen ikke påvirkes.
Datatilgangsbegrensninger pålegges databaseobjekter når 1C: Enterprise får tilgang til databasen. I klient-serverversjonen av 1C: Enterprise pålegges begrensninger på 1C: Enterprise-serveren.
Handlingsmåten for restriksjoner som er valgt for å utføre hver operasjon på data, bestemmes av formålet med denne operasjonen og graden av ansvar for resultatene. Spesielt brukes "tillatt"-metoden når du viser dynamiske lister og noen andre interaktive handlinger. "Alle"-metoden brukes når du utfører operasjoner med brukte objekter fra det innebygde 1C: Enterprise-språket, inkludert når du endrer databaseobjekter. Derfor kan det for eksempel oppstå vanskeligheter når du konstruerer et utvalg for Select ()-metoden til ledere av kataloger, dokumenter og andre, etterfulgt av en omgåelse av resultatet hvis en tilstrekkelig kompleks begrensning er satt på det tilsvarende objektet, siden ikke alle betingelser ved å begrense tilgangsrettigheter kan representeres tilstrekkelig som et utvalg for Velg ()-metoden.
I spørringer kan du kontrollere hvordan begrensninger for datatilgang fungerer. For å gjøre dette gir spørringsspråket et nøkkelord TILLATT... Hvis forespørselen ikke spesifiserer TILLATT, brukes begrensningene på "alle"-måten. Hvis ordet TILLAT er spesifisert, velges metoden "tillatt".
Det er viktig at hvis spørringen ikke spesifiserer nøkkelordet ALLOWED, så må ikke alle valgene som er spesifisert i denne spørringen motsi noen av begrensningene for lesing av databaseobjekter som brukes i spørringen. Dessuten, hvis spørringen bruker virtuelle tabeller, må de tilsvarende valgene pålegges selve de virtuelle tabellene.
Eksempel:

PLUKKE UT
KontaktinformasjonSliceFirst.View
FRA InfoRegister.ContactInformation.SliceLast (, Type = & Type)
HVORDAN KontaktinformasjonSliceFirst
HVOR
ContactInformationSliceFirst.Type = & Type
Tilgang til data i TILLATT-modus støttes ikke når du bruker objektteknikken. Det forutsettes at objektteknikken brukes til de mest kritiske operasjonene på data, inkludert for å endre dem. For å få all data ved hjelp av objektteknikken, uavhengig av de etablerte restriksjonene, kan du utføre de nødvendige handlingene i en privilegert modul eller på vegne av en bruker med fulle rettigheter. Det er ingen midler for å innhente kun tillatte data innen objektteknologi.

Begrensningsmekanisme

Enhver operasjon på data lagret i en database i 1C: Enterprise fører til slutt til tilgang til databasen med noen
en forespørsel om å lese eller endre data. I prosessen med å utføre spørringer til databasen, pålegger de interne mekanismene til 1C: Enterprise tilgangsbegrensninger. Hvori:
● Det dannes en liste over rettigheter (lese, legge til, endre, slette), en liste over databasetabeller og en liste over felt som brukes av denne spørringen.
● Fra alle rollene til gjeldende bruker velges datatilgangsbegrensninger for alle rettigheter, tabeller og felt som brukes i spørringen. Videre, hvis en rolle ikke inneholder begrensninger på tilgang til data i en tabell eller et felt, betyr dette at verdiene til de nødvendige feltene fra en hvilken som helst post er tilgjengelig i denne tabellen. Fravær av begrensning på tilgang til data betyr med andre ord at det foreligger en begrensning
HVOR er sannheten.
● Gjeldende verdier for alle øktparametere og funksjonelle alternativer som deltar i de valgte begrensningene, innhentes.
For å få verdien av en sesjonsparameter fra gjeldende bruker, trenger du ikke å ha rett til å få denne verdien. Men hvis verdien til en sesjonsparameter ikke ble angitt, vil det oppstå en feil og databasespørringen vil ikke bli utført.
Mottak av funksjonelle alternativer påvirkes av egenskapen til funksjonsalternativet Privilegert modus ved mottak.
Hvis denne egenskapen slettes, må gjeldende bruker ha lesetilgang til objektet som lagrer det funksjonelle alternativet.
● Begrensninger hentet fra én rolle kombineres ved å bruke OG-operasjonen.
● Begrensninger avledet fra forskjellige roller ELLER sammen.
● De konstruerte betingelsene legges til SQL-spørringene som 1C: Enterprise adresserer DBMS med. Ved tilgang til data fra siden av tilgangsbegrensningsvilkår, utføres ingen rettighetskontroll (verken til metadataobjekter eller databaseobjekter). Dessuten avhenger mekanismen for å legge til betingelser av den valgte handlingsmetoden for restriksjonene "alle" eller "tillatt".
"alle"-metoden
Når det pålegges restriksjoner på «alle»-måten, legges vilkår og felt til SQL-spørringer slik at 1C: Enterprise kan få informasjon om hvorvidt dataene som er forbudt for denne brukeren ble brukt under utføringen av en spørring til databasen. Hvis de forbudte dataene ble brukt, igangsettes en unormal avslutning av forespørselen. Innføringen av tilgangsbegrensninger ved bruk av "alle"-metoden er vist skjematisk i fig. 1:

Ris. 1. "alle"-metoden

Metode "tillatt"
Når det pålegges begrensninger på den "tillatte" måten, legges betingelser til SQL-spørringer slik at poster som er forbudt av gjeldende bruker ikke påvirker søkeresultatet. Med andre ord, når restriksjoner pålegges i "tillatt"-modus, anses postene som er forbudt for en gitt bruker som fraværende, som er skjematisk vist i fig. 3

Andre objekter relatert til begrensninger for datatilgang

Når du utvikler konfigurasjoner ved bruk av begrensninger for datatilgang, kan metadataobjekter som øktparametere, funksjonelle alternativer og vanlige moduler med avmerkingsboksen Privileged være nyttige.
Sesjonsparametere
Sesjonsparametere kan brukes i datatilgangsbegrensninger på samme måte som spørringsparametere kan brukes i en forespørsel.
Funksjonelle alternativer
Parameteruavhengige funksjonsalternativer kan brukes i datatilgangsbegrensninger på samme måte som spørringsparametere kan brukes i en spørring.
Privilegerte delte moduler

Hvis avmerkingsboksen Privileged er valgt for en felles modul, får utførelsen av prosedyrene og funksjonene til denne modulen viktige detaljer:
● I klient-serverversjonen av 1C: Enterprise kan bare modulen som kjøres på serveren ha privilegier.
● Utførelse av prosedyrene og funksjonene til den privilegerte modulen og alt som kalles fra dem utføres når restriksjonssystemet er av
rettigheter til både metadataobjekter og data. Dermed, fra den privilegerte modulen, vil enhver operasjon på
eventuelle objekter, selv om den nåværende brukeren ikke har de nødvendige rettighetene.
Privilegerte moduler er ment for innledende innstilling av sesjonsparameterverdier som brukes i datatilgangsbegrensninger.
Vanlige moduler kan også brukes til noe helhetlig datamanipulering av en bruker med begrensede rettigheter.
For eksempel, hvis brukerens funksjoner inkluderer å legge inn og poste dokumenter, men brukeren ikke skal ha tilgang til data som påvirkes av dokumentpostering, så kan posteringsoperasjonen flyttes til en privilegert modul. Dette vil tillate brukeren å legge ut dokumenter uten å gi ham rettigheter til annen informasjon (for eksempel registre).
Privilegert modus
Det er mulig å programmere stille inn privilegert modus når du arbeider med data. Privilegert modus programmatisk
kan være nødvendig ved massive operasjoner med infobasedata, og det er ingen vits i å sjekke datatilgangsrettigheter.
For en beskrivelse av privilegert modus, se her.

Bruke forprosessoren

Når du redigerer tekst for datatilgangsbegrensning, kan forbehandlerinstruksjoner brukes. Følgende instruksjoner er tilgjengelige:

#HVIS<Выражение>#DERETTER
# ELLERS<Выражение>#DERETTER
#ELLERS
# SLUTT OM
<Выражение>- et vilkårlig logisk uttrykk i det innebygde språket, hvis resultat er av boolsk type. Uttrykket kan inneholde:
● sammenligningsoperasjoner<, >, <=, >= , =, <> ;
● logiske operasjoner OG, ELLER, IKKE;
● sesjonsparametere - syntaksen er & Parameter, der Parameter er navnet på sesjonsparameteren.
Hvis resultatet av setningsuttrykket #IF eller # ELSE IF er True, plasseres teksten etter nøkkelordet # THEN i den resulterende teksten i tilgangsbegrensningssetningen. Hvis uttrykket evalueres til False, blir ikke teksten etter nøkkelordet # THEN plassert i teksten til tilgangsbegrensningssetningen. Teksten etter # ELSE-setningen vil bli plassert i den resulterende tilgangsbegrensningsteksten hvis ingen av de tidligere betingelsene var oppfylt.
MERK... Hvis teksten for datatilgangsbegrensning inneholder forbehandlerinstruksjoner, passerer ikke begrensningen syntakskontroll under redigering og kan ikke endres ved hjelp av konstruktøren.
Eksempel:

#IF & CurrentUser<>"Klimova" # DA
<текст ограничения доступа>
# SLUTT OM
Her Nåværende bruker- sesjonsparameter av typen ReferanseRef.Brukere.
Denne utformingen betyr at betingelsen for å sette tilgangsbegrensninger vil bli sjekket for alle brukere fra katalogen, bortsett fra brukeren Klimova.

Tekstmaler for tilgangsbegrensninger

En rolle kan inneholde en liste over tilgangsbegrensningsmaler, som er beskrevet på fanen Begrensningsmaler i rolleskjemaet. I tillegg kan tilgangsbegrensningsmaler redigeres i redigeringsprogrammet for grupperedigering av tilgangsbegrensninger og maler.
Hver tilgangsbegrensningsmal har et navn og en tekst. Malnavnet følger de vanlige reglene for navn som brukes i 1C: Enterprise-systemet.
Malteksten inneholder en del av teksten på språket for datatilgangsbegrensning og kan inneholde parametere som er uthevet med symbolet
“#”.
Etter symbolet “#” kan følge:
● Ett av søkeordene:
● En parameter, hvoretter nummeret til parameteren i malen er angitt i parentes;
● CurrentTable - indikerer innsetting i teksten av det fulle navnet på tabellen som begrensningen opprettes for;
● NameCurrentTable- angir innsettingen i teksten av det fulle navnet på tabellen (som en strengverdi, i anførselstegn), som instruksjonen brukes på, i gjeldende versjon av det innebygde språket;
● CurrentAccessRightName – inneholder navnet på rettigheten som gjeldende begrensning utføres for: LES / LES, LEGG TIL / INSERT, ENDRE /
OPPDATERING, SLETT / SLETT;
● malparameternavn - betyr innsetting av den tilsvarende malparameteren i restriksjonsteksten;
● "#"-symbol - angir innsetting av ett "#"-symbol i teksten.

Et tilgangsbegrensningsuttrykk kan inneholde:

● Tilgangsbegrensningsmal, som er spesifisert i formatet
#TemplateName ("Malparameterverdi 1", "Malparameterverdi 2", ...). Hver malparameter er omgitt av doble anførselstegn. Hvis du trenger å angi et dobbelt anførselstegn i parameterteksten, bruk to doble anførselstegn.
● Funksjon StrContains (WhereLooking, WhatLooking)... Funksjonen er laget for å søke etter en forekomst av linjen WhatSeeking i linjen WhereSeeking. Returnerer True hvis en forekomst blir funnet og False ellers.

● Operator + for strengsammenkobling.
For å gjøre det enklere å redigere malteksten, klikk på Angi maltekst-knappen i kategorien Begrensningsmaler i rolleskjemaet. I dialogen som åpnes skriver du inn malteksten og klikker på OK-knappen.
1C: Enterprise-systemet sjekker syntaksen til maltekster, kontrollerer syntaksen for bruk av maler og makroerstatninger av maltekster for å begrense rolletilgang til forespørselsteksten.
Malmakroerstatning består av:
● ved å erstatte forekomster av parametere i teksten til malen med verdiene til parametere fra uttrykket for bruk av malen i teksten til begrensningen;
● ved å erstatte uttrykket for å bruke malen i forespørselsteksten med den resulterende malteksten.
Når spørringskonstruktøren kalles for en betingelse som inneholder tilgangsbegrensningsmønstre, utstedes en advarsel om å erstatte alle mønstre.
Følgende er eksempler på begrensningsmønstre:

For å fleksibelt administrere brukertilgang til data i samsvar med funksjonene ved innstilling av datatilgangsbegrensninger, anbefales det
følge følgende prinsipper:
● Det er nødvendig å velge et sett med informasjon (kan være avhengig av den aktuelle brukeren) som foreløpig forberedelse er tilrådelig. Den valgte informasjonen skal på den ene siden forenkle datatilgangsbegrensninger så mye som mulig, og på den andre siden ikke være for store. Distribuer det etter øktparametere.
● Angi sesjonsparameterverdiene i SessionParametersSetting ()-behandleren til sesjonsmodulen.
● Sett tilgangsbegrensninger for de dataene det er berettiget for (data er hemmelige eller de viktigste for å opprettholde systemets integritet). Det bør huskes at innstilling av tilgangsbegrensninger kan redusere all tilgang til disse dataene. Altfor komplekse begrensninger kan også føre til nedganger.
● Hvis det er nødvendig å sikre ytelsen til et visst begrenset antall operasjoner på data fra den delen av en bruker som er upraktisk å gi full tilgang til disse dataene, flytte disse handlingene til privilegerte moduler eller eksplisitt aktiver og deaktiver privilegert modus i passende steder i programkoden.
● Tilgang til data under ulike kontroller utført av systemet når skriving av objekter utføres i privilegert modus.

Dette lar deg ikke deaktivere begrensninger i rettigheter på postnivå for de tilsvarende feltene, hvis konfigurasjonen fungerer med disse dataene
bare planlagt i administrert modus:

● for referanse når du sjekker overordnet, eieren og unikheten til koden;
● for dokumenter, forretningsprosesser og oppgaver ved kontroll av nummerets unike karakter;
● deaktivert for utvekslingsplaner når du sjekker kodens unikhet;
● for kontoplaner og diagrammer av karakteristiske typer ved kontroll av overordnet og unikt til koden.

Når du oppretter en databegrensningsspørring, bør du huske på noen begrensninger og særegenheter:

● Hvis datatilgangsbegrensninger er spesifisert for en objekttabell og en sammenføyning med en slik tabell brukes i en dataspørring, er bruken av tabelldelen av objektet med den angitte tilgangsbegrensningen ikke tillatt i sammenføyningsbetingelsen (programvarespørring) seksjon).
● Hvis spørringen spesifiserer en tabell som ikke bruker noen felt i spørringen, blir alle datatilgangsbegrensninger pålagt denne tabellen. For eksempel forespørselen VELG ANTALL (*) FRA Directory.Contractors vil bli utført under hensyntagen til alle tilgangsbegrensninger spesifisert for testkatalogen. Restriksjoner pålegges "av OR". Dette betyr at alle poster som er tilgjengelige for minst én tilstand vil være tilgjengelige. Hvis betingelser ikke er spesifisert for noen felt, vil spørringen bli utført for alle tabellposter.
Hvis spørringen bruker en toppnivåtabell, brukes ikke begrensningene som er spesifisert for kolonnene i nestede tabeller.
Hvis spørringen bruker en nestet tabell, pålegges begrensninger både for den nestede tabellen og toppnivåtabellen.
For eksempel forespørselen VELG ANTALL (*) FRA Directory.Contractors.Agreement vil bli utført under hensyntagen til alle begrensningene for katalogentreprenører, samt med hensyn til begrensningene knyttet til tabelldelen av avtalen.

● Hvis tilgang til feltene som kreves for å få en representasjon av det refererte metadataobjektet nektes av
data eller tilgang til et objekt er forbudt på nivået av tilgangsrettigheter, og innhenting av en representasjon av et slikt objekt påvirker ikke forløpet av den gjeldende transaksjonen.

Konstruktør for datatilgangsbegrensninger

For å kalle opp konstruktøren i tabellfeltet Data Access Restrictions i kolonnen Access Restriction, gå til redigeringsmodus og
trykk på valgknappen, og i skjemaet som åpnes, trykk på Spørringskonstruktør...-knappen.
Konstruktørskjemaet vises på skjermen:

Ris. 3. Fanen "Tabeller og felt" til konstruktøren av begrensninger

Med dens hjelp dannes det vilkår for å sette begrensninger på tilgang til data.
I kategorien Tabeller og felt velger du de nødvendige objektene i databaselisten og overfører dem til listen Tabeller. Hvis flere tabeller er spesifisert, legges fanen Lenker til i designskjemaet.

Ris. 4. "Koblinger"-fanen til konstruktøren av begrensninger

På fanen Lenker dannes det betingelser som pålegges koblingene mellom feltene i tabellene. For å angi en ny betingelse, klikk på Legg til-knappen og velg en av tabellene i Tabell1-kolonnen. I Tabell2-kolonnen velger du tabellen hvis felt er knyttet til feltene til den første. Under listen over betingelser er det kontrollelementer ved hjelp av hvilke en betingelse for kobling av tabeller dannes.
Hvis en enkel betingelsestype er valgt, velges de relaterte feltene til de spesifiserte tabellene i felt1 og felt2, og sammenligningsbetingelsen settes. Hvis de valgte feltene, hvis sammenligning ikke er utført, vises følgende tekst på linjen i listen over betingelser i kolonnen Koblingsbetingelse: Ugyldig fylt betingelse.
På fanen Betingelser må du om nødvendig spesifisere betingelsene som valget av kildedata skal utføres i henhold til.

Ris. 5. "Betingelser"-fanen i begrensningskonstruktøren

For hvert valgt felt må du velge tilstandstype og angi navnet på parameteren. En sesjonsparameter kan brukes som en parameter. Flere forhold er tillatt. I dette tilfellet, i tilstandskolonnen i vilkårstabellfeltet, vises teksten til betingelsen på flere linjer.
Når som helst under opprettelsen av en forespørsel, kan teksten til forespørselen ses ved å klikke på knappen Forespørsel.

Masseredigering av tilgangsrettighetsbegrensninger og maler

Modusen for grupperedigering av tilgangsrettighetsbegrensninger og maler aktiveres av kommandoen Alle tilgangsbegrensninger i kontekstmenyen til Rollegrenen. Skjemaet som åpnes inneholder to faner: Tilgangsbegrensninger og Begrensningsmaler.

Ris. 6 Alle tilgangsbegrensninger og maler

På et bokmerke Tilgangsbegrensninger du kan se alle angitte tilgangsbegrensninger i den generelle listen (for alle roller, objekter, rettigheter, feltkombinasjoner).
Det er mulig å legge til tilgangsbegrensninger for flere roller, objekter, rettigheter og rollekombinasjoner samtidig.
Du kan filtrere listen etter ulike kriterier.

Ris. 7. Valg av tilgangsbegrensninger

Grupperedigeringsmodus lar deg slette begrensningene som er valgt i listen.
Det er mulig å redigere de valgte begrensningene. I dette tilfellet kan du endre sammensetningen av feltene og/eller tilgangsbegrensningen.
Grupperedigeringsmodusen lar deg også kopiere de valgte begrensningene til andre roller.

På et bokmerke Begrensningsmaler du kan se alle tilgangsbegrensningsmaler som finnes i den anvendte løsningen, mens fra selve malteksten i tabellen vises kun de første 10 linjene, som slutter med "..."-symbolet hvis malteksten er på mer enn 10 linjer . Malredigeringsvinduet vil vise hele teksten til malen.

Fig 8. Alle maler for tilgangsbegrensninger

Det er mulig å legge til en tilgangsbegrensningsmal for flere roller samtidig.

Det er ofte nødvendig å delvis begrense tilgangen til data. For eksempel når en bruker bare skal se dokumenter for sin organisasjon. I slike tilfeller bruker 1C en mekanisme for å begrense tilgangen på postnivå (den såkalte RLS - Record Level Security).

La oss for eksempel si at vi står overfor følgende oppgave. Selskapet fører regnskap for flere selskaper og hver motpart og databasebruker tilhører en bestemt organisasjon. Det er nødvendig å gi tilgang til katalogen "Entreprenører" på en slik måte at hver bruker kan se, redigere og legge til kontraktører kun for sin egen organisasjon.

For å løse problemet vil vi bruke 1C: Enterprise 8.2-plattformen. La oss lage en ny konfigurasjon i egenskapene som alternativet "Administrert applikasjon" vil bli valgt som hovedstartmodus.

Deretter vil vi opprette en katalog "Organisasjoner" og to kataloger til - "Entreprenører" og "Brukere" med attributtet "Organisasjon". I tillegg til katalogene trenger vi to sesjonsparametere - "Organisasjon" og "Bruker" (av tilsvarende typer). Verdiene til disse parameterne settes når du starter en konfigurasjonsøkt og lagres til den avsluttes. Det er verdiene til disse parameterne vi vil bruke når vi legger til betingelser for å begrense tilgangen på rekordnivå.

Sesjonsparametere settes i en spesiell modul - "Session module"

I denne modulen vil vi beskrive den forhåndsdefinerte prosedyren "SettingSessionParameters" der vi vil kalle funksjonen til den tidligere utarbeidede generelle modulen "FullRights". Dette er nødvendig på grunn av særegenhetene ved databaseoperasjonen i administrert applikasjonsmodus, når en del av programkoden bare kan kjøres på serversiden (jeg vil ikke dvele ved forklaringen av disse prinsippene i denne artikkelen).

Kode 1C v 8.x Prosedyre for innstilling av øktparametere (påkrevde parametre)
FullRights.SetSessionParameters ();
Slutt på prosedyre

I egenskapene til "FullRights"-modulen, merk av for "Server", "Server call" og "Privileged" (sistnevnte betyr at prosedyrene og funksjonene til denne modulen vil bli utført uten kontroll av tilgangsrettigheter). Modulteksten vil se slik ut:

Kode 1C v 8.x Funksjon DetermineCurrentUser ()
CurrentUser = Directories.Users.FindByDesign (Brukernavn (), True);
Returner TekUser;
EndFunction

Prosedyre SetSessionParameters () Eksport
CurrentUser = DefineCurrentUser ();
CurrentOrganization = Directories.Organizations.EmptyLink ();
Hvis ValueFilled (CurrentUser) Da
CurrentOrganization = CurrentUser.Organization;
Slutt om;
Session Options.User = CurrentUser;
Session Parameters.Organization = CurrentOrganization;
Slutt på prosedyre

Funksjon SessionParameter Set (OptionName) Eksport
Return ValueFilled (SessionParameters [ParameterName]);
EndFunction

Funksjon RolleBruker tilgjengelig (RoleName) Eksport
Returner RoleAvailable (RoleName);
EndFunction

I den administrerte applikasjonsmodulen vil vi se etter tilstedeværelsen av en konfigurasjonsbruker i katalogen "Brukere" (for enkelhets skyld vil vi se etter den ved navn) og slå av systemet hvis det ikke blir funnet. Dette er nødvendig for å sikre at sesjonsparametrene er fylt ut.

Kode 1C v 8.x Prosedyre før start av systemdrift (feil)
// vi vil sjekke alle unntatt administratoren for tilstedeværelse i "Brukere"-katalogen
Hvis ikke FullRights.RoleUser tilgjengelig ("FullRights") Da
Hvis IKKE FullRight.SessionParameterSeted ("Bruker") Da
Advarsel ("Bruker" "" + Brukernavn () + "" "finnes ikke i katalogen!");
Avslag = Sant;
Komme tilbake;
Slutt om;
Slutt om;
Slutt på prosedyre

Nå kan vi gå direkte til beskrivelsen av tilgangsbegrensninger. For å gjøre dette, opprett "Bruker"-rollen og gå til fanen "Begrensningsmaler", hvor vi vil legge til en ny "AccountsReadEdit"-mal med følgende maltekst: HVOR organisasjon = organisasjonsnr. parameter (1)

Begrensningsmalteksten er en utvidelse av spørringsspråket. I motsetning til en vanlig forespørsel, må teksten til begrensningen nødvendigvis inneholde betingelsen "HVOR". Verdiene til sesjonsparametrene med samme navn brukes som verdiene til spørringsparametrene (i vårt tilfelle er det "& Organisasjon"). Konstruksjon av skjemaet # Parameter (1) betyr at systemet vil erstatte dette stedet med teksten som sendes som første parameter på stedet der malen brukes. Ved hjelp av den gitte malen vil hver post i tabellen bli sjekket (i vårt tilfelle vil det være katalogen "Entreprenører"). For poster, hvis verdien av attributtet "Organisasjon" sammenfaller med den som er spesifisert i den tilsvarende parameteren for økten, vil betingelsen beskrevet i malen være oppfylt. Dermed vil disse postene være tilgjengelige for lesing, endring eller tilføyelse (avhengig av hvilken av disse rettighetene malen gjelder for). Jeg vil demonstrere det ovenfor med vårt eksempel.

La oss gå til "Rettigheter"-fanen i "Bruker"-rollen og åpne listen over rettigheter i "Kontraktører"-katalogen. Vi vil bruke begrensningsmalen "AccountsReadingChange" for rettighetene "Les", "Endre" og "Legg til".

For "Lese"-rettigheten vil vi bruke en mal med parameteren "OR ThisGroup". I dette tilfellet vil brukere av denne rollen få lov til å lese ikke bare elementene i katalogen "Entreprenører" til organisasjonen deres, men også alle gruppene i denne katalogen.

#BusinessReadingChange ("ELLER denne gruppen")

Siden når du legger til nye elementer i katalogen, leser systemet implisitt forhåndsdefinerte attributter (dette er for eksempel nødvendig for nummerering), er det nødvendig å sikre uhindret lesing av disse feltene. For å gjøre dette, legg til en ekstra linje med en tom restriksjonstekst til begrensningstabellen for datatilgang og lister opp feltene som denne regelen gjelder for - Link, Dataversjon, Overordnet, Kode.

Dermed er oppgaven med å begrense tilgangen på rekordnivå løst. Brukere med aktive begrensninger vil kun ha tilgang til å se og redigere data fra sin egen organisasjon.

Den åttende versjonen av 1C: Enterprise-plattformen (i dag 8.3) gjennomførte mange endringer i forhold til de "syv", blant hvilke mekanismen for å begrense tilgangsrettigheter på rekordnivå skilte seg ut. Selv om du i teorien kan klare deg uten det, bare ved å bruke roller, lar RLS deg oppnå mer finjustering av tilgangen. Men for riktig drift av denne mekanismen, må du tydelig forstå essensen og ha tilstrekkelig erfaring med utvikling i 1C.

Hva er RLS?

Essensen av denne funksjonaliteten er utviklerens evne til å hindre en viss bruker eller gruppe brukere fra å få tilgang til tabeller eller felt i databasetabeller. Vanligvis brukes restriksjoner for å hindre 1C-brukere fra å se og redigere konfidensiell, hemmelig informasjon, for eksempel for å begrense ansatte i et selskap som tilhører en gruppe ved å se dokumenter kun for deres organisasjon. Mekanismen for å begrense tilgangsrettigheter på postnivå kan også brukes til å fjerne unødvendig informasjon fra grensesnittet.

For å kunne skrive forespørsler om RLS-begrensninger, må du opprette en rolle eller ta en eksisterende. RLS-innstillingen i 1C 8.3 kan brukes til følgende brukerhandlinger:

• Legger til;
• Lesning;
• fjerning;
• Forandringen.

I tillegg til de bredeste alternativene for å konfigurere tilgang, har RLS også ulemper:

1. Krav til utviklerens kvalifikasjoner, siden forespørselen må skrives på et innebygd språk, under hensyntagen til syntaksreglene;
2. Manglende evne til raskt å feilsøke tilstanden;
3. Begrensede muligheter for å beskrive logikken: for komplekse forhold vil fortsatt måtte skrives i modulene til dokumenter og oppslagsverk;
4. I klient-serverversjonen av databasene er den implisitte veksten av tabellene som er inkludert i spørringen mulig. Dessuten er det svært vanskelig å spore denne prosessen;
5. Ressurskrav. RLS-restriksjoner bruker mye klient- og serverkraft;
6. Lite dokumentasjon i allmennheten.

Rapporter kan bli et annet problem som kan oppstå etter å ha satt opp 1C RLS. Faktum er at utviklerne sørger for mulige RLS-begrensninger og bygger rapporter på en slik måte at de kun viser tillatte data. Hvis brukere har konfigurert forskjellige RLS-begrensninger, kan dataene i rapporten for de samme parameterne være forskjellige for dem. Dette kan være tvilsomt, så vær oppmerksom på disse situasjonene når du designer rapporter eller skriver spørsmål i RLS.

Opprett en RLS-begrensning

For å legge til en RLS-begrensning, må du finne den nødvendige rollen og dobbeltklikke på den for å åpne den.

Vinduet som åpnes inneholder 2 faner: "Rettigheter" og "Maler for begrensninger". For å legge visse begrensninger på en spesifikk handling, må du velge den og klikke på det grønne pluss nederst til høyre. En linje vil vises der vi kan sette begrensningene for 1C RLS på språket som er innebygd i 1C.

Hvis du kjenner 1C-syntaksen (som din egen bukselomme), så kan du skrive direkte i "Access restriction"-feltet. 1C-utviklere har sørget for muligheten til å åpne en spørringsdesigner, som vil hjelpe og fortelle deg hva begrensningen kan brukes på. For å åpne den, må du klikke på knappen med tre prikker (Velg) eller F4 og et vindu med "Query constructor ..."-knappen vises.

I vinduet som vises, kan du konfigurere begrensninger ikke bare for denne oppslagsboken, men også for andre objekter i systemet. For å gjøre dette, legg dem til i kategorien "Tabell og felt". Vi registrerer begrensningene på feltene i oppslagsboken "Nomenklatur" og klikker på "OK". Vær oppmerksom på navnene på variablene: RLS-parametere settes ved starten av en brukerøkt og må finnes i metadataobjektet.

På fanen "Begrensningsmaler" kan du angi forespørslene som er nødvendige når du kopierer de samme RLS-innstillingene i 1C 8.3. Etter at du har lagt til malen din, kan du referere til navnet i innstillingene for tilgangsrettigheter.

Det er også mulig å legge til begrensninger på flere roller samtidig. For å gjøre dette, høyreklikk på "Roller"-delen i konfigurasjonstreet og velg "Alle roller".

Som en konklusjon vil jeg bemerke at denne artikkelen er rettet mot konsulenter-utviklere av 1C og kan hjelpe, for det første, de som allerede har erfaring med utvikling av 1C: Enterprise. Til tross for den tilsynelatende enkelheten, krever kunnskap om semantikk og forståelse av strukturen til forretningsprosesser i din egen bedrift eller kundens organisasjon for riktig fordeling av rettigheter et visst nivå av kunnskap og erfaring.

I denne artikkelen vil jeg fortelle deg hvordan konfigurasjonsmekanismen for "rekordnivåtilgangsbegrensning" fungerer i 1C: UPP 1.3. Informasjon for artikkelen ble samlet for mai 2015. Siden den gang har ikke UPP blitt radikalt oppdatert, fordi 1C valgte 1C: ERP som flaggskipet. Likevel fungerer SCP bra i mange bedrifter, så jeg legger ut resultatene av min forskning på RLS i SCP i denne artikkelen. Noen vil definitivt komme godt med.

Alt er tørt, komprimert og uten vann. Hvordan jeg elsker))).

Innstillinger for tilgangsrettigheter.

Ordningen for samhandling av objekter.

I UPP 1.3 utføres tilgangskontroll av undersystemet "Access Control" fra BSP versjon 1.2.4.1.

Metadata brukt i SCP-tilgangskontrollsystemet:

1. Referanse for brukerautoritetsprofiler
2. Informasjonsregister "Verdier av tilleggsbrukerrettigheter"
3. Plan over karakteristiske typer "Brukerrettigheter"
4. Katalog "Brukere"
5. Systemkatalog "Informasjonssikkerhetsbrukere"
6. Katalog "Brukergrupper"
7. Register over informasjon "Brukerinnstillinger"
8. Plan over karakteristiske typer "Brukerinnstillinger"
9. Oppregning "Typer tilgangsobjekter"
10. Register over opplysninger "Tildeling av tilgangsbegrensningstyper"
11. Access Object Data Areas Enumeration
12. Register over informasjon "Innstillinger for brukerrettigheter"
13. Sesjonsparameter "Bruk begrensning av<ВидДоступа>».

Aktiverer tilgangsbegrensninger på postnivå.

Record Level Access Restriction (RLS) er aktivert på grensesnittet
Brukeradministrasjon -> Rekordnivåtilgang -> Alternativer.

Tilgang på rekordnivå defineres via tilgangsobjekttyper. Liste over tilgangsobjekttyper (tilsvarende oppslagsverk er angitt i parentes):

• "motparter" ("motparter")
• "Organisasjoner" ("Organisasjoner")
• "Enkeltpersoner" ("Enkeltpersoner")
• "Prosjekter" ("Prosjekter")
• "Warehouses ("Warehouses (lagersteder) ")
• "Kandidater" ("Kandidater")
• "Notater" ("Typer noteoppføringer")
• "Underavdelinger" ("Underavdelinger")
• "Underavdelinger av organisasjoner" ("Underavdelinger av organisasjonen")
• "Nomenklatur (endring)" ("Nomenklatur")
• "Spesifikasjoner" ("Spesifikasjoner")
• «Varepriser» («Varepristyper»)
• "Eksterne behandlinger" ("Eksterne behandlinger")

* Listen over mulige tilgangstyper er fast og finnes i oppregningen "Typer av tilgangsobjekter".

Referanse "Brukerautoritetsprofiler".

Konfigurering av tilgang til infobaseobjekter begynner med å konfigurere en brukertillatelsesprofil.

Profil samler

• sett med roller - tilgangsrettigheter til objekter
• ekstra brukerrettigheter - rettigheter til funksjonaliteten til programmet.

Resultatet av å sette opp en profil er en oppføring i informasjonsregisteret "Verdier av tilleggsbrukerrettigheter".
Dette registeret brukes ikke i radaroppsettet.

Ytterligere rettigheter kan registreres for en profil eller bruker. Dessuten, hvis tilleggsrettigheter er konfigurert for profilen og profilen er knyttet til brukeren, kan ikke tilleggsrettighetene konfigureres individuelt for brukeren.
* Listen over rettigheter er oppført i form av typene egenskaper "Brukerrettigheter"

Selve profilen i tabelldelen "sammensetning av roller" inneholder alle de rollene som er aktivert for den. Når sammensetningen av profilens roller endres, fylles «Roler»-tabelldelen av alle brukere av infobasen (ikke «Brukere»-katalogen) som denne profilen er tildelt til på nytt.

Koblingen mellom "Brukere"-katalogen og "Informasjonsbase-brukere" implementeres gjennom "IBUserID"-attributtet til "Users"-referanseboken, som lagrer IB-bruker-GUID.

Sammensetningen av brukerroller er heller ikke tilgjengelig for redigering hvis brukeren er tildelt en bestemt profil.

Det er mulig for brukeren å spesifisere "Brukerinnstillinger". Dette er ulike tjenesteinnstillinger for den typiske automatiske oppførselen til systemet i visse situasjoner.

Resultatet av innstillingene skrives inn i informasjonsregisteret "Brukerinnstillinger".

Listen over innstillinger og deres mulige verdier er inneholdt i diagrammet over karakteristiske typer "Brukerinnstillinger".
* Ikke brukt i innstillingene for å begrense tilgang på rekordnivå.

Katalog "Brukergrupper".

Brukes til å gruppere brukere og blant annet sette opp tilgangsbegrensninger på rekordnivå.

Én bruker kan inkluderes i flere grupper.

I form av en brukergruppe kan du konfigurere en liste over tilgangstyper.

Objekttillatelser på postnivå konfigureres bare for grupper av brukere, ikke for individuelle brukere.

Hvis konfigurasjonen bruker tilgangsbegrensninger på rekordnivå, må hver bruker inkluderes i en av gruppene.

VIKTIG! Brukere som ikke er inkludert i noen gruppe, vil ikke kunne jobbe med disse objektene, tilgangen til disse er definert på postnivå. Dette gjelder for alle objekter – uavhengig av om tilsvarende tilgangsobjekttyper benyttes eller ikke.

Hvis en bruker tilhører flere grupper som har ulike innstillinger for tilgangsrettigheter på postnivå, så vil tilgjengeligheten til objektet for brukeren bli bestemt ved å kombinere innstillingene fra flere brukergrupper med "ELLER".

VIKTIG! Inkludering av en bruker i et stort antall grupper kan føre til redusert ytelse. Derfor bør du ikke inkludere brukeren i et stort antall grupper.

Etter at endringene i brukergruppen er registrert, vil Informasjonsregisteret "Tildeling av tilgangsbegrensningstyper" fylles ut. Dette registeret lagrer registreringer av samsvar med en gruppe brukere for en bestemt type tilgang.

* Case brukes i tilgangsbegrensningsmaler

Få tilgang til innstillingsskjema.

Skjemaet for å angi tilgangsbegrensninger på postnivå kalles av kommandoen "Innstilling av tilgang" i skjemaet til listen over katalogen "Brukergrupper".

Fanene på høyre side av skjemaet inneholder tabeller med innstillinger for hver type tilgang markert med avmerkingsbokser i form av en brukergruppe.

Skjemaet for innstilling av tilgangsrettigheter har en egen skjemaside for hver type tilgang med sitt eget sett med innstillinger. Den ønskede siden aktiveres når den tilknyttede tilgangstypen er krysset av i brukergruppen.

Sammenligning av tilgangstyper og mulige innstillinger:

Tilgangstype	Innstillinger for tilgangstype
	Lesning	Innspilling	Tilgangsrettsarvetype	Listesynlighet	Se tilleggsinformasjon	Redigering av tilleggsinformasjon	Se data	Redigering av data	Bedriftspriser		Partnerpriser
									Lesning	Innspilling	Lesning	Innspilling
Entreprenører
Organisasjonen
Enkeltpersoner
Prosjekter
Varehus
Kandidater
Notater
Underavdelinger
Underavdelinger av organisasjoner
Nomenklatur
Spesifikasjoner
Varepriser
Eksterne behandlinger

Tilgangsrettigheter.

"Leser" - brukeren vil se referansebokelementet i listen og vil kunne åpne det for visning, han vil også kunne velge det fra listen når han fyller ut detaljene til andre objekter.

"Record" - brukeren vil kunne endre:

• elementer i noen ordbøker - typer tilgangsobjekter (ikke alle - det er unntak, se nedenfor),
• data (dokumenter, registre, underordnede kataloger) knyttet til disse katalogelementene

Unntak: tilgang til elementer i enkelte kataloger - typer tilgangsobjekter - er ikke avhengig av "Skrive"-rettigheten. Dette er kataloger over organisasjoner, avdelinger, organisasjoners avdelinger, varehus, prosjekter. De refererer til objektene til referansedata, derfor kan de bare endres av en bruker med rollen "Konfigurere referansedata ...".

For tilgangsobjekttypen " Nomenklatur (endring)"Tilgangsrettigheten" til å skrive " er bare definert på gruppenivået til" nomenklaturen "katalogen, det er ingen måte å sette" skrive "rett for individuelle element oppslagsverk.

Begrensning av tilgang til å "lese" oppslagsboken "Nomenklatur" og relatert informasjon er ikke gitt, fordi det generelt sett ikke er klart hva slags tilgang til dokumentet skal være, hvis listen over nomenklaturen, som er i dokumentet, inneholder både «tillatt» og «forbudt »posisjon.

Begrensning av tilgang for katalogene "Avdelinger" og "Organisasjoners avdelinger" gjelder ikke informasjon om personaldata, om personopplysninger om ansatte og data om lønn.

Dataområder.

Dataområder er definert for følgende typer tilgangsobjekter:

• Entreprenører
• Enkeltpersoner
• Varepriser

For typen tilgangsobjekt "Entreprenører"

• Entreprenører (liste)- bestemmer synligheten til entreprenører i listen over "Entreprenører"-katalogen. Avhenger av verdien til avmerkingsboksen i kolonnen "Synlighet i listen".
• Motparter (tilleggsinformasjon)- bestemmer muligheten til å "lese" / "skrive" et element i katalogen "Entreprenører" og relatert tillegg. informasjon (kontrakter, kontaktpersoner osv.). Avhenger av verdien til avkrysningsboksen i de tilsvarende kolonnene "Se flere. informasjon "/" Redigering add. informasjon ".
• Entreprenører (data)- bestemmer muligheten til å "lese" / "skrive" data (kataloger, dokumenter, registre) knyttet til katalogen "Entreprenører". Avhenger av verdien av avmerkingsboksen i kolonnen "Se data" / "Rediger data".

For typen tilgangsobjekt "Enkeltpersoner" følgende dataområder er gitt:

• Enkeltpersoner (liste)- bestemmer synligheten til en person i listen over katalogen "Individer". Avhenger av verdien til avmerkingsboksen i kolonnen "Synlighet i listen".
• Enkeltpersoner (data)- bestemmer muligheten til å "lese" / "skrive" data (kataloger, dokumenter, registre) knyttet til katalogen "Individer". Avhenger av verdien av avmerkingsboksen i kolonnen "Se data" / "Rediger data".

For tilgangsobjekttypen "Varepriser" følgende dataområder er gitt:

• Firmapriser - definerer muligheten til å "lese" / "skrive" prisene på en firmavare.
• Motpartspriser- bestemmer muligheten til å "lese" / "skrive" prisene i nomenklaturen til motparter.

* Dataområder er en lukket liste over elementer, inneholdt i oppregningen "Dataområder for tilgangsobjekter"

Tilgang til grupper.

For følgende typer tilgangsobjekter konfigureres rettigheter kun gjennom tilgangsgrupper (navnene på katalogen er angitt i parentes):

• "Motparter" ("motpartstilgangsgrupper")
• "Individuals" ("Individual Access Groups")
• "Kandidater" ("Kandidatgrupper")
• "Varespesifikasjoner" ("Spesifikasjonsbruksformål")

En tilgangsgruppe er spesifisert for hvert element i katalogen (i en spesiell attributt).

Tilgangsinnstillinger fra "tilgangsgruppen ..." utføres i tilleggsformen for tilgangsrettighetsinnstillinger, som kalles opp av en av to kommandoer:

• "Tilgang til gjeldende elementer",
• "Tilgang til katalogen som helhet"

i form av en liste over kataloger "Tilgangsgrupper ..."

Eksempel: Dokumentet "Mottaksordre for varer" er begrenset av typene tilgangsobjekter "Entreprenører", "Organisasjoner", "Lagre".

Hvis du gir tilgang til en tom verdi for tilgangstypen «Entreprenører», vil brukeren se dokumenter hvor variabelen «Entreprenør» ikke er fylt ut.

Tilgang til et katalogelement eller en gruppe.

Avhengig av hvilken tilgang som er konfigurert til - til et katalogelement eller til en gruppe, virker innstillingen enten på selve elementet eller på underordnede grupper.

Følgelig, i skjemaet "Angi tilgangsrettigheter" i kolonnen "Type arv av tilgangsrettigheter til hierarkiske kataloger" er følgende verdier satt:

• Kun for gjeldende rett- for en katalogvare gjelder rettighetene for den angitte varen
• Utvid til underordnede- for en kataloggruppe gjelder rettighetene for alle underordnede elementer

Etter å ha registrert tifor brukergrupper i systemet, vil informasjonsregisteret "Innstillinger for brukerrettigheter" fylles ut.

* Registeret brukes i maler for tilgangsbegrensning.

Bruke maler.

Maler i SCP 1.3 er skrevet for hver type tilgang separat og for mulige kombinasjoner av tilgangstyper, som regel, for hver brukergruppe.

For eksempel , i demoversjonen av UPP er brukergruppen "Kjøp" konfigurert. For denne gruppen er bruk av tilgangstypene "Organisasjoner", "Entreprenører", "Lager" aktivert. Følgelig er det opprettet en rekke tilgangsbegrensningsmaler i systemet:

• "Organisasjon"
• "Organisasjonsrekord"
• "Motparter"
• "Entreprenørrekord"
• "Lagerhus"
• "Warehouses_Record"
• "Motpartsorganisasjon"
• "Counterparty Organization_Record"
• "OrganizationWarehouse"
• "OrganizationWarehouse_Record"
• "CounterpartyOrganizationWarehouse_Record"
• "Motpartslager"
• "CounterpartyWarehouse_Record"

Det vil si alle mulige kombinasjoner av tilgangstyper som kan brukes i tilgangsbegrensningstekster.

Generelt er malkonstruksjonsskjemaet det samme for alle typer tilgang og ser slik ut:

1. Kontrollerer inkludering av den sjekkede typen tilgang.
2. «Brukergrupper»-oppslaget er vedlagt hovedtabellen og det kontrolleres at brukeren er inkludert i minst én gruppe.
3. Til opplysningsregisteret "Tildeling av typer tilgangsverdier" er vedlagt registertabellen "Innstillinger for brukertilgangsrettigheter" i henhold til tilkoblingsbetingelsene. - Tilgangsobjektet er tilgangsverdien som sendes til malparameteren. - Tilgangsobjekttype - avhenger av konteksten for malutvikling - Dataområde.- Bruker.

Resultatet av tilkoblingen avgjør om tilgang er tillatt eller ikke.

Slutten av andre del.