Come configurare i diritti di accesso in 1C 8.3?

In questo articolo vedremo come lavorare con gli utenti in 1C Accounting 8.3:

• creare un nuovo utente
• configurare i diritti: profili, ruoli e gruppi di accesso
• come configurare la limitazione dei diritti a livello di record (RLS) in 1C 8.3, ad esempio per organizzazione

Le istruzioni sono adatte non solo per il programma di contabilità, ma anche per molti altri basati su BSP 2.x: 1C Trade Management 11, Gestione salari e personale 3.0, ERP 2.0, Gestione piccole imprese e altri.

Nell'interfaccia del programma 1C, la gestione degli utenti viene effettuata nella sezione “Amministrazione”, alla voce “Configurazione utenti e diritti”:

Come creare un nuovo utente in 1C

Per creare un nuovo utente in 1C Accounting 3.0 e assegnargli determinati diritti di accesso, nel menu "Amministrazione" è presente la voce "Impostazioni utente e diritti". Andiamo la:

L'elenco degli utenti è gestito nella sezione “Utenti”. Qui puoi creare un nuovo utente (o gruppo di utenti) o modificarne uno esistente. Solo un utente con diritti amministrativi può gestire l'elenco degli utenti.

Creiamo un gruppo utenti chiamato "Contabilità" e ci saranno due utenti al suo interno: "Contabile 1" e "Contabile 2".

Per creare un gruppo, fare clic sul pulsante evidenziato nella figura sopra e inserire un nome. Se nella base informativa sono presenti altri utenti idonei al ruolo di contabile, è possibile aggiungerli immediatamente al gruppo. Nel nostro esempio non ce ne sono, quindi facciamo clic su "Salva e chiudi".

Ora creiamo gli utenti. Posiziona il cursore sul nostro gruppo e fai clic sul pulsante “Crea”:

Nel nome completo inseriremo "Contabile 1" e il nome di accesso sarà impostato su "Contabile 1" (questo è ciò che verrà visualizzato quando si accede al programma). La password sarà “1”.

Assicurati che le caselle di controllo "Accesso al programma consentito" e "Mostra nell'elenco di selezione" siano selezionate, altrimenti l'utente non si vedrà durante l'autorizzazione.

Lasciare la "Modalità di avvio" su "Auto".

Impostazione dei diritti di accesso: ruoli, profili

Ora devi specificare "Diritti di accesso" per questo utente. Ma devi prima scriverlo, altrimenti apparirà una finestra di avviso come mostrato nell'immagine sopra. Fare clic su “Registra”, quindi su “Diritti di accesso”:

Seleziona il profilo Ragioniere. Questo profilo è standard e configurato con i diritti di base richiesti da un contabile. Fare clic su "Registra" e chiudere la finestra.

Nella finestra “Utente (creazione)”, fare clic su “Salva e chiudi”. Stiamo anche creando un secondo contabile. Ci assicuriamo che gli utenti siano abilitati e possano lavorare:

È opportuno notare che lo stesso utente può appartenere a più gruppi.

Abbiamo scelto i diritti di accesso per i contabili tra quelli inclusi nel programma per impostazione predefinita. Ma ci sono situazioni in cui è necessario aggiungere o rimuovere alcuni diritti. Per fare ciò, è possibile creare il proprio profilo con una serie di diritti di accesso necessari.

Andiamo alla sezione "Accesso ai profili del gruppo".

Diciamo che dobbiamo consentire ai nostri contabili di visualizzare la registrazione del diario.

Creare un profilo da zero è piuttosto laborioso, quindi copiamo il profilo "Contabile":

E apportiamo le modifiche necessarie: aggiungiamo il ruolo "Visualizza registro":

Diamo al nuovo profilo un nome diverso. Ad esempio, "Contabile con integrazioni". E seleziona la casella di controllo "Visualizza registro di registrazione".

Ora dobbiamo modificare il profilo degli utenti che abbiamo creato in precedenza.

Limitazione dei diritti a livello di registrazione in 1C 8.3 (RLS)

Scopriamo cosa significa limitare i diritti a livello di record, o come lo chiamano in 1C - RLS (Record Level Security). Per ottenere questa opportunità è necessario selezionare la casella apposita:

Il programma richiederà la conferma dell'azione e ti informerà che tali impostazioni possono rallentare notevolmente il sistema. Spesso è necessario che alcuni utenti non vedano i documenti di determinate organizzazioni. È proprio per questi casi che esiste un'impostazione di accesso a livello di record.

Andiamo nuovamente nella sezione di gestione del profilo, facciamo doppio clic sul profilo “Ragioniere con Inseriti” e andiamo alla scheda “Restrizioni di accesso”:

“Tipo di accesso” seleziona “Organizzazioni”, “Valori di accesso” seleziona “Tutti consentiti, le eccezioni sono assegnate in gruppi di accesso”. Fare clic su "Salva e chiudi".

Ora torniamo alla sezione “Utenti” e selezioniamo, ad esempio, l'utente “Contabile 1”. Fare clic sul pulsante “Diritti di accesso”:

Utilizzando il pulsante "Aggiungi", seleziona l'organizzazione i cui dati saranno visualizzati dal "Contabile 1".

Nota! L'utilizzo di un meccanismo per separare i diritti a livello di record può influire sulle prestazioni del programma nel suo insieme. Nota per il programmatore: l'essenza di RLS è che il sistema 1C aggiunge una condizione aggiuntiva a ciascuna richiesta, richiedendo informazioni sul fatto che all'utente sia consentito leggere queste informazioni.

Altre impostazioni

Le sezioni “Copia impostazioni” e “Cancella impostazioni” non sollevano dubbi; i loro nomi parlano da soli; Queste sono le impostazioni per l'aspetto del programma e dei report. Ad esempio, se hai impostato un bell'aspetto per la directory "Nomenclatura", può essere replicato per altri utenti.

Nella sezione "Impostazioni utente", puoi modificare l'aspetto del programma ed effettuare impostazioni aggiuntive per facilità d'uso.

La casella di controllo "Consenti accesso a utenti esterni" consente di aggiungere e configurare utenti esterni. Ad esempio, desideri organizzare un negozio online basato su 1C. I clienti del negozio saranno utenti esterni. I diritti di accesso vengono configurati allo stesso modo degli utenti normali.

Basato su materiali da: programmist1s.ru

L'oggetto di configurazione "ruolo" fornisce una serie di diritti alle operazioni (azioni) sugli oggetti di configurazione.

Ruolo "Pieni diritti".

Questo è semplicemente un ruolo (non predefinito) in cui vengono controllati tutti i tipi di diritti su tutti gli oggetti di configurazione.

Ciò che lo distingue dagli altri ruoli è la presenza del diritto “Amministrazione”.

Se viene creato almeno un utente, il sistema inizia a verificare la presenza del diritto di "Amministrazione": almeno un utente deve averlo.

Restrizioni di accesso a livello di record

Sicurezza a livello di riga (RLS): restrizione a livello di record.

Il meccanismo di limitazione dell'accesso ai dati consente di gestire i diritti di accesso non solo a livello di oggetti di metadati, ma anche a livello di oggetti di database. I seguenti oggetti possono essere utilizzati per limitare l'accesso ai dati:

• ruoli,
• parametri di sessione,
• opzioni funzionali,
• moduli condivisi privilegiati,
• parola chiave ALLOWED nel linguaggio di query.

Il meccanismo è progettato per limitare l'accesso ai record delle tabelle degli oggetti di metadati in base a condizioni arbitrarie imposte sui valori dei campi riga di queste tabelle. Ad esempio, per visualizzare solo i record relativi alle “tue” controparti, organizzazioni, ecc.

Implementazione tecnica delle restrizioni di accesso in 1C

1C genera una richiesta al DBMS. Il cluster di server aggiunge alla richiesta una sezione WHERE, che contiene il testo della condizione per limitare l'accesso tramite RLS, quindi questa richiesta viene inviata al DBMS, i dati estratti vengono restituiti al client 1C.

Questo meccanismo funzionerà per qualsiasi richiesta del client:

• nei rapporti,
• in elenchi dinamici e in moduli di elenco regolari
• nelle query personalizzate.

Una tale implementazione del meccanismo influisce notevolmente sulle prestazioni.

Modi per aggirare le restrizioni di accesso.

Nelle operazioni di grandi dimensioni ad uso intensivo di risorse (ad esempio l'elaborazione della ripubblicazione di documenti), parte del codice può essere spostata in moduli privilegiati.

UN) Modulo privilegiato è un modulo comune con il flag "Privileged" nelle proprietà.

La sua particolarità è che il codice in esso contenuto viene eseguito senza alcun controllo sui diritti di accesso, incluso RLS.

B) Anche privilegiato la modalità può essere attivata per i moduli oggetto documento. Questo viene fatto nelle proprietà del documento, flag

• Trattamento privilegiato nella conduzione
• Modalità privilegiata quando si annulla una transazione

B) Metodo Imposta modalità privilegiata()

Il comando di sistema consente di rendere privilegiata parte del codice di qualsiasi modulo.

Dalla successiva riga di codice, funzionerà la modalità di esecuzione privilegiata.

Funzionerà fino alla linea per disattivare questa modalità o fino al termine della procedura/funzione

(VERO);

// qualsiasi codice qui verrà eseguito senza controllo dei diritti e RLS

Imposta modalità privilegiata(Menzogna ); // o fine della procedura/funzione

Il numero di volte in cui la modalità privilegiata viene abilitata deve corrispondere al numero di volte in cui viene disabilitata. Tuttavia, se all'interno di una procedura o funzione la modalità privilegiata è stata attivata (una o più volte), ma non è stata disattivata, il sistema si spegnerà automaticamente tante volte quante sono state attivazioni incomplete nella procedura o funzione lasciata

Se in una procedura o una funzione chiama un metodo Imposta modalità privilegiata(Falso) ha effettuato più che chiamate di metodo Imposta modalità privilegiata(True ), verrà generata un'eccezione

Funzione Modalità privilegiata() restituisce True se la modalità privilegiata è ancora abilitata e False se è completamente disabilitata. Ciò non analizza il numero di impostazioni della modalità privilegiata in una particolare funzione.

Tutte le procedure e le funzioni richiamate verranno eseguite anche in modalità privilegiata.

È anche possibile avviare una sessione privilegiata. Questa è una sessione in cui la modalità privilegiata viene stabilita fin dall'inizio del sistema. Inoltre, durante il funzionamento il metodo Modalità privilegiata() restituirà sempre True e la possibilità di disabilitare la modalità privilegiata non è supportata. Solo un utente che dispone di diritti amministrativi (diritto di amministrazione) può avviare una sessione privilegiata. La sessione può essere avviata utilizzando l'opzione della riga di comando di avvio dell'applicazione client UsePrivilegedMode o il parametro della stringa di connessione infobase prmod .

Sorge spontanea la domanda: perché allora istituire restrizioni di accesso se possono essere aggirate così facilmente?

Modalità sicura.

Sì, puoi scrivere elaborazioni esterne con una modalità di esecuzione privilegiata e scaricare/corrompere i dati. Per evitare ciò, il sistema dispone di un metodo di contesto globale

Imposta modalità sicura().

La modalità provvisoria, tra le altre cose, ignora la modalità privilegiata.

Deve essere installato prima di chiamare a livello di codice processori esterni o esportare procedure e funzioni dai relativi moduli.

Quando si eseguono operazioni vietate, viene generata un'eccezione in fase di esecuzione.

Inoltre, a livello delle impostazioni del ruolo, è possibile disabilitare la possibilità per gli utenti di avviare in modo interattivo report ed elaborazioni esterne.

Impostazione delle restrizioni di accesso

La RLS può essere configurata solo per i diritti:

• leggere (selezionare)
• aggiungendo (inserisci)
• cambiare (aggiornare)
• eliminare

Per le operazioni di lettura e la cancellazione, un oggetto che risiede nel database deve rispettare le restrizioni di accesso ai dati.

Per l'operazione di aggiunta La restrizione di accesso ai dati deve corrispondere all'oggetto che si prevede di scrivere nel database.

Per l'operazione di modifica la restrizione di accesso ai dati deve rispettare l'oggetto sia prima della modifica (in modo che l'oggetto venga letto) sia dopo la modifica (in modo che l'oggetto venga scritto).

Per tutti gli altri diritti non esiste tale opzione.

Aggiungiamo una nuova restrizione per il diritto di “lettura” della directory “Nomenclatura”. Si aprirà un elenco di campi per i quali è possibile configurare la restrizione aggiunta.

Ciò significa che se provi ad accedere ai campi selezionati, il vincolo verrà attivato, ma se provi ad accedere ai campi non selezionati, il vincolo non verrà attivato.

Se selezioni la bandiera " Altri campi", la restrizione verrà configurata per tutti i campi della tabella, ad eccezione dei campi per i quali le restrizioni sono impostate esplicitamente.

*Caratteristica: per i diritti di aggiunta, modifica, eliminazione:

• La restrizione può essere configurata solo per tutti i campi.
• Può esserci una sola restrizione.

Per il diritto “Lettura” è possibile configurare diverse condizioni; queste verranno abbinate all'operatore logico “AND”.

Non tutti i campi dell'oggetto dati del vincolo principale possono essere utilizzati nelle restrizioni sui seguenti tipi di oggetti di database:

• nei registri di accumulo le restrizioni di accesso possono contenere solo misure dell'oggetto principale della restrizione;
• nei registri contabili i vincoli possono utilizzare solo le misurazioni di bilancio dell'oggetto principale del vincolo

Se, in condizioni di accesso limitato ai dati del registro di accumulo circolante, vengono utilizzate misure che non rientrano nei totali, allora quando si accede alla tabella virtuale dei giri, i totali memorizzati non vengono utilizzati e la richiesta viene eseguita interamente secondo la tavola di movimento.

Meccanismo per imporre restrizioni di accesso.

Qualsiasi operazione sui dati archiviati in un database in 1C:Enterprise porta infine a una chiamata al database con qualche richiesta di leggere o modificare i dati. Nel processo di esecuzione delle query sul database, i meccanismi interni di 1C:Enterprise impongono restrizioni di accesso. In cui:

• Viene generato un elenco di diritti(lettura, aggiunta, modifica, eliminazione), un elenco di tabelle del database e un elenco di campi utilizzati da questa query.
• Da tutti i ruoli dell'utente corrente sono selezionate le restrizioni di accesso ai dati per tutti i diritti, le tabelle e i campi coinvolti nella richiesta. Inoltre, se un ruolo non contiene restrizioni sull'accesso ai dati di una tabella o di un campo, significa che in questa tabella sono disponibili i valori dei campi obbligatori di qualsiasi record. In altre parole, l'assenza di una restrizione all'accesso ai dati significa la presenza di una restrizione DOVE È IL VERO.
• Recupera i valori correnti di tutti i parametri di sessione e le opzioni funzionali partecipare alle restrizioni selezionate.

Per ottenere il valore di un parametro di sessione o di un'opzione di funzionalità, non è necessario che l'utente corrente disponga dell'autorizzazione per ottenere tale valore. Tuttavia, se il valore di qualche parametro di sessione non è stato impostato, si verificherà un errore e la query sul database non verrà eseguita.

I vincoli derivati ​​da un ruolo vengono combinati utilizzando l'operazione AND.

I vincoli derivati ​​da ruoli diversi vengono combinati utilizzando l'operazione OR.

Le condizioni costruite vengono aggiunte alle query SQL con cui 1C: Enterprise accede al DBMS. Quando si accede ai dati da condizioni di restrizione di accesso, il controllo dei diritti non viene eseguito (né per gli oggetti di metadati né per gli oggetti di database). Inoltre, il meccanismo per l'aggiunta di condizioni dipende dal metodo di funzionamento selezionato delle restrizioni “tutte” o “consentite”.

*Caratteristica: se un utente ha accesso a più ruoli con restrizioni configurate a livello di record per un oggetto, in questo caso le condizioni delle restrizioni vengono aggiunte utilizzando l'operazione logica "OR". In altre parole, i poteri dell'utente sono cumulativi.

Ciò porta alla seguente conclusione: non consentire che le condizioni per limitare l'accesso a un oggetto in ruoli diversi si intersechino, perché in questo caso il testo della richiesta sarà molto complicato e ciò influirà sulle prestazioni.

Metodo "Tutto".

Quando si impongono restrizioni utilizzando il metodo "tutto", vengono aggiunti condizioni e campi alle query SQL in modo che 1C:Enterprise possa ottenere informazioni sul fatto se, durante l'esecuzione di una query sul database, sono stati utilizzati o meno dati vietati per un determinato utente. Se sono stati utilizzati dati vietati, la richiesta si bloccherà a causa di una violazione di accesso.

L'imposizione di restrizioni di accesso utilizzando il metodo “tutti” è presentata schematicamente nella figura:

Metodo “Consentito”.

Quando si applicano restrizioni utilizzando il metodo "consentito", vengono aggiunte condizioni alle query SQL in modo che i record vietati per l'utente corrente non influenzino il risultato della query. In altre parole, quando le restrizioni vengono imposte in modalità “permessa”, i record vietati per un dato utente sono considerati mancanti e non influiscono sul risultato dell'operazione, che è schematicamente presentato in figura:

Le restrizioni di accesso ai dati vengono imposte sugli oggetti del database nel momento in cui 1C:Enterprise accede al database.

Nella versione client-server di 1C:Enterprise, le restrizioni vengono applicate sul server 1C:Enterprise.

Tuttavia, questa opzione (ALLOWED) non funzionerà se in una query facciamo riferimento a una tabella per la quale non sono configurate restrizioni di accesso, ma che contiene riferimenti a righe di tabella con restrizioni configurate. In questo caso, il risultato della query mostrerà "<Объект не найден>......" al posto del valore del campo di riferimento.

Se stai sviluppando un report o elaborandolo utilizzando query di configurazione standard o personalizzate, controlla sempre il flag "Consentito". affinché il rapporto funzioni sotto qualsiasi utente con qualsiasi insieme di diritti.

Nel caso di oggetto che legge dati dal database non è possibile impostare il flag “Consentito”. Pertanto è necessario configurare le selezioni per la lettura degli oggetti, tenendo conto delle possibili restrizioni sui diritti di accesso per l'utente. Non esiste alcuna possibilità di ottenere solo i dati consentiti nella tecnologia degli oggetti.

È importante che se una query non specifica la parola chiave ALLOWED, tutte le selezioni specificate in tale query non devono entrare in conflitto con nessuna delle restrizioni di lettura sugli oggetti del database utilizzati nella query. Inoltre, se la query utilizza tabelle virtuali, allora le selezioni corrispondenti dovranno essere applicate alle tabelle virtuali stesse.

Esercizio 1. Generatore di query nelle impostazioni RLS.

Componiamo il testo della sezione “WHERE” nella query alla directory. È possibile utilizzare il generatore di query.
Il designer ha un aspetto essenziale.

Scheda "Tabelle".

La tabella principale sarà la tabella dell'oggetto per il quale si sta configurando il vincolo.

Puoi anche selezionare altre tabelle e impostare varie connessioni tra loro nella scheda "Relazioni".

Scheda "Condizioni"

Qui è possibile configurare le effettive condizioni di restrizione dell'accesso

Aggiungiamo le condizioni all'attributo "Prezzo" della directory della nomenclatura per il diritto di "lettura" su tutti i campi della tabella.

“Nomenclatura DOVE Nomenclatura.Prezzo > 500”

Vediamo come funziona questa semplice regola. La tabella delle directory contiene i seguenti elementi:

Dopo aver impostato una restrizione di accesso, la tabella mostrerà solo gli elementi che soddisfano la condizione:

Anche i gruppi sono scomparsi. Cambiamo il testo della restrizione

“Nomenclatura DOVE Nomenclatura.Prezzo > 500

OR Nomenclatura.Questo è un gruppo"

Bene, ora è quello che ti serve.

Se rimuovi la visualizzazione del campo “codice” nelle impostazioni dell'elenco, verranno visualizzati tutti gli elementi della directory, ad es. la restrizione non ha funzionato. Se imposti il ​​campo "Codice" da visualizzare, la restrizione funzionerà.

In questo caso, nonostante l'elemento della directory sia visibile nel campo elenco, la sua maschera non può essere aperta perché è configurata una restrizione sull'attributo. La stessa cosa accade in una richiesta arbitraria: quando si tenta di ottenere una proprietà “limitata”, si verificherà un errore di accesso.

Se provi a ottenere le credenziali "limitate" a livello di codice, verrà generato anche un errore di accesso.

Inoltre non sarà possibile accedere ad alcun campo di un oggetto tramite un collegamento, perché quando si riceve un collegamento il sistema legge l'intero oggetto e se contiene dettagli “ristretti” l'oggetto non verrà letto.

Pertanto, quando si lavora a livello di programmazione con gli oggetti del database, è necessario tenere presente le possibili restrizioni a livello di record e ottenere tutti i dati necessari dell'oggetto su richiesta e quindi inserirli in una struttura o eseguire parte del codice in un modulo privilegiato.

Dopo aver impostato la limitazione dell'accesso, la visualizzazione della riga nell'elenco dei diritti è cambiata: è diventata grigia ed è apparsa un'icona.

Restrizioni durante la configurazione dell'accesso (RLS).

• Non esiste una sezione di riepilogo;
• Non è possibile accedere alle tabelle dei registri virtuali;
• Non è possibile utilizzare i parametri in modo esplicito;
• Può essere utilizzato nelle query nidificate qualsiasi>/span> strumento del linguaggio di query tranne:
  • operatore IN GERARCHIA;
  • proposte di RISULTATI;
  • risultati delle query nidificate non deve contenere parti della tabella>/span>;
  • tavoli virtuali, in particolare Saldi e Fatturati

Esercizio 2. Nomenclatura con prezzo corrente.

Crea una restrizione di accesso se devi visualizzare articoli con un prezzo corrente superiore a un determinato valore, ad esempio 100.

Soluzione:

Stiamo aggiungendo una nuova regola di limitazione dell'accesso per la directory "Nomenclatura" con il diritto di "lettura".
Seleziona “altri campi”.
Nel costruttore aggiungiamo una query nidificata. In esso, seleziona la tabella del registro delle informazioni "Prezzi degli articoli".
Non esiste una scheda "ordine": questa è una funzionalità di Progettazione query per creare una richiesta di restrizione di accesso.
Nella scheda “Avanzate”, imposta “primo 999999999”, appare la scheda “ordine”.
Impostiamo l'ordinamento in base al campo "Periodo" in ordine decrescente.
Quindi impostiamo una connessione tra la tabella principale e la sottoquery per riferimento.

Modelli di limitazione dell'accesso.

Pratica 3. Restrizione alle “controparti” in base al valore in una costante.

Impostiamo una restrizione di accesso per la directory Controparti in base al valore memorizzato nella Costante.

Inoltre, nei dettagli è necessario impostare una restrizione per tutti gli oggetti che utilizzano la directory "Controparti".

Soluzione

Per la directory “Controparti” imposteremo una restrizione per il diritto di “lettura” aggiungendo una query nidificata alla costante nella sezione “Condizioni”. Non dimenticare che questo è un gruppo.

Riscontriamo un problema, la directory Controparti viene filtrata correttamente e vengono visualizzati tutti i documenti con l'attributo "Controparte", alcuni con collegamenti "interrotti" nell'attributo "Controparte".

Ora è necessario configurare le restrizioni di accesso per tutti gli oggetti che utilizzano il collegamento ad “Account”. Troviamoli utilizzando il servizio “ricerca collegamenti ad un oggetto”.

Copiamo e modifichiamo leggermente il testo della condizione RLS dalla directory “Controparti”. Questo deve essere fatto tante volte quanti sono gli oggetti trovati.

Oppure utilizza un modello di restrizioni di accesso per evitare problemi di duplicazione del codice.

I modelli di restrizione di accesso sono configurati a livello di ruolo e possono essere utilizzati per qualsiasi oggetto all'interno del ruolo modificato.

È possibile aggiungere qualsiasi parte di testo di restrizione di accesso al modello. Il modello viene richiamato utilizzando il simbolo “#”. Ad esempio, #TemplateCounterparty.

Attraverso # in 1C le istruzioni vengono scritte nel preprocessore. Nel contesto dell'esecuzione delle impostazioni di limitazione dell'accesso, la piattaforma sostituisce il testo della chiamata al modello con il testo del modello.

Aggiungiamo il testo dopo la parola DOVE al modello "Contractor Template", ad eccezione del testo su EtoGroup.

Parametri nei modelli di restrizione di accesso.

Continuiamo a risolvere il problema 2.

Il problema ora è che la tabella principale della directory si chiama “controparte”, nel documento “Ricevuta fattura”. Il campo da controllare nella directory si chiama “link”, nel documento si chiama “Counterparty”.

Cambiamo il nome della tabella principale nel testo del modello in "#CurrentTable"

"#CurrentTable" è un parametro predefinito.

E attraverso un punto indichiamo il numero del parametro di input - “.#Parameter(1)

Anche “#Parametro” è un valore predefinito. Può contenere un numero arbitrario di parametri di input. Sono indirizzati tramite numero di serie.

Nel testo delle restrizioni di accesso alla directory indichiamo quanto segue:

Per il documento quanto segue:

"Vendite di beni WHERE #TemplateCounterparty ("Controparte")"

Quando si richiama un modello di restrizione di accesso, i parametri devono essere passati ad esso solo come stringa, ovvero tra virgolette.

Tabella principale - Nomenclatura

Il testo del modello è:

#TabellaCorrente DOVE #TabellaCorrente.#Parametro(1) = #Parametro(2)

Il testo del modello contiene parte del testo nella lingua di restrizione dell'accesso ai dati e può contenere parametri evidenziati utilizzando il simbolo "#".

Il simbolo "#" può essere seguito da:

• Una delle parole chiave:
  • Un parametro seguito dal numero del parametro nel modello tra parentesi;
  • CurrentTable – indica l'inserimento nel testo del nome completo della tabella per la quale si sta costruendo il vincolo;
  • NomeTabellaCorrente– denota l'inserimento nel testo del nome completo della tabella (come valore stringa, tra virgolette) a cui viene applicata l'istruzione, nella versione corrente del linguaggio integrato;
  • NomeCurrentAccessRight– contiene il nome del diritto per il quale viene eseguita la restrizione corrente: READ, ADD, INSERT, CHANGE, UPDATE, DELETE;
• nome del parametro del modello – indica l'inserimento nel testo del corrispondente vincolo del parametro del modello;
• simbolo “#” – indica l'inserimento di un carattere “#” nel testo.

Un'espressione di restrizione di accesso può contenere:

• Modello di restrizione di accesso, specificato nel formato #TemplateName("Valore del parametro modello 1", "Valore del parametro modello 2",...). Ogni parametro del modello è racchiuso tra virgolette doppie. Se è necessario specificare un carattere di virgolette doppie nel testo del parametro, è necessario utilizzare due virgolette doppie.
• Funzione StrContains(WhereWeLook, WhatWeLook). La funzione è progettata per cercare un'occorrenza della stringa WhatWeLook nella stringa WhereWeLook. Restituisce True se viene trovata l'occorrenza e False altrimenti.
• L'operatore + serve per la concatenazione di stringhe.

Per semplificare la modifica del testo del modello, nella scheda Modelli di restrizione nel modulo del ruolo, fare clic sul pulsante Imposta testo modello. Nella finestra di dialogo che si apre, inserisci il testo del modello e fai clic su OK.

Non possono essere installati utilizzando ImpostaParametro() o qualcosa di simile.

I parametri in questo caso sono:

• Opzioni della sessione
• Opzioni funzionali

La lettura dei parametri di sessione in una richiesta di restrizione dell'accesso avviene in modalità privilegiata, cioè senza controllo dei diritti per operare con essi.

Pratica 4. Accesso alle “vostre” controparti

È necessario configurare la restrizione dell’accesso dell’utente attuale alle “loro” controparti.

Esiste una directory “Utenti”, una directory “Controparti”, documenti con i dettagli “Controparte”.

L'utente attuale dovrebbe vedere i dati solo per quelle controparti per le quali è stata stabilita una connessione con lui.

Anche la comunicazione deve essere configurata.

Opzioni possibili:

Stabilire connessioni tra utente e controparte

• Dettagli nella directory delle controparti
• Registro delle informazioni

Possibili soluzioni al problema:

• Memorizzare un utente in una costante è una cattiva opzione; la costante è disponibile per tutti gli utenti.
• Memorizzare un array fisso delle controparti dell'utente corrente nei parametri di sessione non è un'ottima opzione poiché possono esserci molte controparti
• Memorizzare i parametri di sessione dell'utente corrente, quindi richiedere un elenco delle “sue” controparti è un'opzione accettabile.
• Altre opzioni.

Soluzione.

Creiamo un nuovo parametro di sessione "CurrentUser" e compiliamolo nel modulo di sessione.

Creiamo un registro delle informazioni “Compliance dei dirigenti e degli appaltatori”

Creiamo un nuovo ruolo e in esso una nuova restrizione di accesso per il documento "Fattura".

Nel testo della richiesta collegheremo la tabella principale con il registro delle informazioni per Account = Account e Manager = &CurrentUser. Tipo di connessione Interna.

Se possibile, è meglio evitare query annidate nei testi di limitazione dell'accesso, poiché verrà eseguita ogni volta che i dati di questo oggetto verranno letti dal database.

Controllo: le restrizioni funzionano

*Caratteristica: se si modifica l'elenco delle controparti utente nel registro, le restrizioni di accesso avranno effetto immediato senza riavviare la sessione utente.

Pratica 5. Data di divieto di modifiche.

È necessario attuare una restrizione alla modifica dei dati prima della data stabilita per vietare le modifiche.
È necessario limitarlo per gli utenti.

Creiamo un registro di informazioni “Date di divieto di modifiche” con la dimensione Utente, risorsa Data di divieto.

Costruiamo la logica della soluzione in questo modo:

• se un utente non viene specificato, il ban si applica a tutti gli utenti
• se esiste una restrizione per tutti gli utenti e una restrizione per un utente specifico, la restrizione si applica a un utente specifico e agli altri secondo il principio generale.

Ovviamente, tale vincolo può essere configurato per gli oggetti del database che hanno una certa posizione sull'asse del tempo. Può essere

• Documentazione
• Registri informativi periodici

Creiamo un nuovo ruolo "Restrizioni per data di divieto di modifiche".

In esso, per il documento “Fattura” per il diritto “modifica” aggiungeremo una nuova restrizione di accesso.

Specifichiamo l'impostazione per tutti i campi.

Il testo della restrizione è:

ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice

Modificare le date di divieto. Data di divieto AS Data di divieto
DA

JOIN INTERNO (SELEZ
MAX(Modifica date vietate.Utente) AS Utente
DA
Registro delle informazioni. Date di divieto di modifiche AS Date di divieto di modifiche
DOVE
(Modifica date vietate. Utente = &CurrentUser
OR Date non consentite Modifiche.Utente = VALUE(Directory.users.EmptyLink))) AS VZ_User
BY Data di divieto di modifiche.Utente = VZ_User.Utente) AS NestedQuery
Data fattura ricevuta software > Data Query nidificata.Ban

Controlliamo: la restrizione funziona.

Utilizzo delle istruzioni del preprocessore

#Se Condizione1 #Allora

Richiedi il frammento 1

#ElseIf Condizione2 #Then

Richiedi il frammento 2

#Altrimenti

Richiedi il frammento 3

#Finisci se

Nelle condizioni è possibile utilizzare operazioni logiche (e, o, no, ecc.) e accedere ai parametri di sessione.

Questo approccio nel contesto della creazione di restrizioni di accesso è conveniente in quanto, a seconda delle condizioni, verrà compilato un testo di richiesta più breve. Una query più semplice carica meno il sistema.

Lo svantaggio è che il costruttore della query non funzionerà con tale testo.

*Peculiarità:

A differenza delle istruzioni impartite al preprocessore del linguaggio integrato nei testi di restrizione dell'accesso, prima dell'operatore è necessario inserire un hash - #Then

Esercizio 6. Cambia "Usa RLS"

Integriamo il nostro sistema di restrizioni con un interruttore che attiva/disattiva l'uso delle restrizioni a livello record.

Per fare ciò, aggiungeremo una costante e un parametro di sessione denominato "UseRLS".

Scriviamo nel Modulo Sessione per impostare il valore del parametro di sessione dal valore della costante.

Aggiungiamo il seguente codice a tutti i testi di restrizione di accesso:

"#If &UseRLS #Then….. #EndIf"

Controlliamo: tutto funziona.

Tuttavia, ora, dopo aver attivato il flag “usa radar”, le modifiche non avranno effetto immediato. Perché?

Perché il parametro di sessione viene impostato all'avvio della sessione.

È possibile impostare il valore del parametro di sessione in modo che venga reimpostato quando viene scritto un nuovo valore costante, ma funzionerà solo per la sessione utente corrente. Agli altri utenti dovrebbe essere richiesto di riavviare il sistema.

Fine della prima parte.

L'ottava versione della piattaforma 1C:Enterprise (oggi 8.3) portava molti cambiamenti rispetto ai “sette”, tra i quali spiccava soprattutto il meccanismo per limitare i diritti di accesso a livello record. Nonostante sia teoricamente possibile farne a meno, utilizzando solo i ruoli, RLS consente di ottenere impostazioni di accesso più dettagliate. Ma per far funzionare correttamente questo meccanismo, è necessario comprenderne chiaramente l'essenza e avere sufficiente esperienza nello sviluppo in 1C.

Cos'è la RLS?

L'essenza di questa funzionalità è la capacità dello sviluppatore di impedire a un utente specifico o a un gruppo di utenti di accedere alle tabelle o ai campi delle tabelle del database. In genere, le restrizioni vengono utilizzate per impedire agli utenti 1C di visualizzare e modificare informazioni riservate e segrete, ad esempio limitando i dipendenti di un'azienda inclusa in un gruppo alla visualizzazione dei documenti solo per la propria organizzazione. Inoltre, il meccanismo per limitare i diritti di accesso a livello di record può essere utilizzato per rimuovere informazioni non necessarie dall'interfaccia.

Per poter scrivere query per le restrizioni RLS, è necessario creare un ruolo o assumerne uno esistente. La configurazione di RLS in 1C 8.3 può essere utilizzata per le seguenti azioni dell'utente:

• Aggiunta;
• Lettura;
• Eliminare;
• Modifica.

Oltre alle più ampie possibilità di personalizzazione dell'accesso, RLS presenta anche degli svantaggi:

1. Requisiti per le qualifiche dello sviluppatore, poiché la richiesta dovrà essere scritta nel linguaggio integrato, tenendo conto delle regole di sintassi;
2. Mancanza di capacità di eseguire rapidamente il debug delle condizioni;
3. Possibilità limitate per descrivere la logica: condizioni troppo complesse dovranno ancora essere scritte in moduli di documenti e libri di consultazione;
4. Nella versione client-server del database è possibile la crescita implicita delle tabelle incluse nella query. Inoltre, è molto difficile seguire questo processo;
5. Requisiti di risorse. Le restrizioni RLS consumano molta energia sul computer client e sul server;
6. Poca documentazione è disponibile gratuitamente.

Un altro problema che potrebbe sorgere dopo aver impostato 1C RLS possono essere i report. Il fatto è che gli sviluppatori prevedono possibili restrizioni RLS e creano report in modo tale da mostrare solo i dati consentiti. Se per gli utenti sono configurate restrizioni RLS diverse, i dati nel report per gli stessi parametri potrebbero essere diversi. Ciò può sollevare domande, quindi è necessario tenere conto di queste situazioni quando si progettano report o si scrivono query in RLS.

Creare un vincolo RLS

Per aggiungere una restrizione RLS, è necessario trovare il ruolo desiderato e aprirlo facendo doppio clic.

La finestra che si apre contiene 2 schede: “Diritti” e “Modelli di restrizione”. Per imporre determinate restrizioni a un'azione specifica, è necessario selezionarla e fare clic sul segno più verde in basso a destra. Apparirà una riga in cui possiamo impostare le restrizioni RLS 1C nella lingua incorporata in 1C.

Se conosci la sintassi 1C (come il palmo della tua mano), puoi scrivere direttamente nel campo "Restrizione di accesso". Gli sviluppatori 1C hanno fornito la possibilità di aprire un costruttore di query, che aiuterà e suggerirà quali restrizioni possono essere apportate. Per aprirlo è necessario cliccare sul pulsante con tre punti (Seleziona) o F4 e apparirà una finestra con il pulsante “Query Builder…”.

Nella finestra che appare, puoi configurare le restrizioni non solo per questa directory, ma anche per altri oggetti di sistema. Per fare ciò, è necessario aggiungerli nella scheda "Tabelle e campi". Registriamo le restrizioni sui campi della directory “Nomenclatura” e facciamo clic su “OK”. Fai attenzione ai nomi delle variabili: i parametri RLS vengono impostati all'inizio della sessione utente e devono essere contenuti nell'oggetto metadati.

Nella scheda "Modelli di vincoli", si specificano le query necessarie quando si copiano le stesse impostazioni RLS in 1C 8.3. Dopo aver aggiunto il modello, puoi utilizzare il suo nome nelle impostazioni dei diritti di accesso.

È anche possibile aggiungere contemporaneamente restrizioni a più ruoli. Per fare ciò, nell'albero di configurazione è necessario fare clic con il tasto destro sulla sezione "Ruoli" e selezionare "Tutti i ruoli".

In conclusione, vorrei sottolineare che questo articolo è rivolto ai consulenti sviluppatori 1C e può aiutare principalmente coloro che hanno già esperienza nello sviluppo 1C:Enterprise. Nonostante la sua apparente semplicità, la conoscenza della semantica e la comprensione della struttura dei processi aziendali della propria impresa o dell'organizzazione del cliente per la corretta distribuzione dei diritti richiedono un certo livello di conoscenza ed esperienza.

Nel sistema 1C Enterprise 8, oggi continueremo a studiare il meccanismo dei diritti e ad approfondire il meccanismo RLS (restrizione dei diritti a livello record).

Di seguito esamineremo i vantaggi e gli svantaggi di questo metodo e vedremo la configurazione di RLS in 1C Enterprise 8.3 utilizzando un esempio.

1C RLS (Record Level Security) ovvero limitazione dei diritti a livello di registrazione- questi sono i diritti utente nel sistema 1C, che consente di separare i diritti per gli utenti nel contesto dei dati che cambiano dinamicamente.

Il tipo più comune di impostazione RLS 1C consiste nel limitare la visibilità dell'utente tra organizzazioni o clienti (l'utente vede solo i "suoi" dati).

Il vantaggio principale è la presenza del meccanismo stesso; il meccanismo è piuttosto complesso e interessante. Consente di differenziare in modo molto preciso i diritti degli utenti: gli utenti potrebbero anche non essere consapevoli dell'esistenza di altri dati nel sistema.

Svantaggi di 1C 8 RLS

Tra le carenze si può notare un notevole calo delle prestazioni del sistema. Ciò è dovuto al fatto che la piattaforma, quando crea una query nel database, complica qualsiasi richiesta dello sviluppatore con condizioni aggiuntive.

Tra gli svantaggi c'è anche la complessità dell'impostazione di questa funzionalità e la difficoltà del debug. 1C ha rilasciato pochissimo materiale sull'impostazione e il funzionamento di questa funzionalità. È abbastanza difficile trovare uno specialista che possa impostare correttamente il meccanismo.

Impostazione delle restrizioni sui diritti a livello di record RLS 1C

Le autorizzazioni a livello di record (RLS) vengono utilizzate per limitare i seguenti tipi di diritti:

• Lettura
• Aggiunta
• Modifica
• Rimozione

Ottieni 267 lezioni video su 1C gratuitamente:

Esternamente, l'impostazione di RLS (diritti a livello di record) è simile alla creazione di un semplice file . Un esempio di modello per limitare l'accesso alla visibilità dei documenti da parte del cliente dall'intestazione del documento:

##Se &Utilizza restrizioni sui diritti di accesso a livello di record ##Allora

TabellaCorrente DA #TabellaCorrente COME TabellaCorrente
UNISCI A SINISTRA (SELEZIONA VARI
Composizione gruppo.Link gruppo utenti AS
DA
Directory.Gruppi utenti.Gruppi utenti Composizione gruppo AS
DOVE
GroupComposition.User = &CurrentUser) AS UserGroups
Software (limitazioni dei diritti di accesso a livello di record e utilizzo)
DOVE (&UseRecordLevelPermissionRestrictions = FALSE
OPPURE (NON 1 V
(SELEZIONA TOP 1
1 COME SELEZIONARE
DA
Registro delle informazioni. Scopo dei tipi di oggetti di accesso AS Scopo dei tipi di oggetti di accesso
DOVE
Scopo dei tipi di accesso Objects.UserGroup = UserGroups.UserGroup
E SCELTA
QUANDO Scopo dei tipi di oggetti di accesso. Tipo di oggetto di accesso = VALORE (Enumerazione. Tipi di oggetti di accesso. Controparti)
E CurrentTable.#Parameter(1) LINK Directory.Counterparties
E NON TabellaCorrente.#Parametro(1) = VALORE(Directory.Accounts.EmptyLink)
POI SCELTA
QUANDO 1 V
(SELEZIONA TOP 1
1
DA
Directory.Controparti AS Appaltatori INTERNAL JOIN Informazioni Registro.Impostazioni diritti di accesso utente Impostazioni diritti di accesso utente AS
DI
UserAccessRightSettings.AccessObject = Counterparties.AccessGroupToCounterparty
E UserAccessRightSettings.AccessObjectType = VALUE(Enumeration.AccessObjectTypes.Counterparties)
AND (Impostazioni diritti di accesso utente. Utente = Assegnazione di tipi di oggetti di accesso. Gruppo utenti
OPPURE UserAccessRightSettings.User = VALUE(Directory.UserGroups.AllUsers))
E UserAccessRightSettings.Record = TRUE
DOVE
Controparti.Link = TabellaCorrente.#Parametro(1))
POI LA VERITÀ
ALTRIMENTI FALSO
FINE
ALTRIMENTI VERO
FINE = FALSO))
E NON UserGroups.UserGroup È NULL)
##Finisci se

In sostanza, questa query viene aggiunta ogni volta che viene eseguita una query sulla tabella "#CurrentTable". Da cui possiamo immaginare quale carico aggiuntivo comporta il meccanismo di restrizione a livello record.

Come puoi vedere, la richiesta ha parametri speciali, ad esempio "&Utilizza restrizioni sui diritti di accesso a livello di record". Questi parametri nel radar vengono selezionati dagli oggetti metadati - “ “. Di norma vengono impostati all'inizio della sessione utente.

Costruttore di restrizione dell'accesso ai dati

Per comodità dello sviluppatore, 1C 8.3 dispone di un'utilità speciale per aiutare a configurare il radar: Data Access Restriction Designer. Viene richiamato dal campo "Limitazione di accesso". Come segue:

1C ha un sistema integrato di diritti di accesso (questo sistema è chiamato ruoli 1C). Questo sistema è statico: poiché l'amministratore ha assegnato i diritti 1C, quindi lo sarà.

Inoltre, esiste un sistema dinamico di diritti di accesso (chiamato RLS 1C). In esso, i diritti 1C vengono calcolati dinamicamente mentre l'utente lavora in base ai parametri specificati.

Una delle impostazioni di sicurezza più comuni in vari programmi è una serie di permessi di lettura/scrittura per i gruppi di utenti e quindi l'inclusione o l'esclusione di un utente dai gruppi. Ad esempio, un sistema simile viene utilizzato in Windows AD (Active Directory).

Tale sistema di sicurezza in 1C si chiama Ruoli 1C. I ruoli 1C si trovano nella configurazione nel ramo Generale/Ruoli. I ruoli 1C fungono da gruppi per i quali vengono assegnati i diritti 1C. L'utente viene quindi incluso o escluso da questo gruppo.

Facendo doppio clic sul nome del ruolo 1C, si aprirà l'editor dei diritti per il ruolo 1C. A sinistra c'è un elenco di oggetti 1C. Selezionane uno e le opzioni per i diritti di accesso verranno visualizzate sulla destra (come minimo: lettura, aggiunta, modifica, eliminazione).

Per il ramo superiore (nome della configurazione corrente), vengono stabiliti i diritti amministrativi 1C e l'accesso per avviare varie opzioni.

Tutti i diritti 1C sono divisi in due gruppi: un diritto “semplice” e lo stesso diritto con l'aggiunta di “interattivo”. Cosa significa?

Quando un utente apre un modulo (ad esempio l'elaborazione) e preme un pulsante su di esso, il programma nel linguaggio 1C integrato esegue determinate azioni, ad esempio l'eliminazione di documenti. I diritti "Simply" 1C sono responsabili di consentire queste azioni (eseguite a livello di codice).

Quando un utente apre un diario e inizia a fare qualcosa utilizzando la tastiera in modo indipendente (ad esempio, inserendo nuovi documenti), si tratta di diritti 1C “interattivi”.

Un utente può avere accesso a più ruoli, nel qual caso le autorizzazioni sono cumulative.

Una ripartizione delle possibilità di impostare i diritti di accesso utilizzando i ruoli – Oggetto 1C. Cioè, puoi abilitare l'accesso alla directory o disabilitarlo. Non puoi accenderlo un po'.

A questo scopo esiste un'estensione del sistema di ruoli 1C denominata 1C RLS. Si tratta di un sistema di diritti di accesso dinamico che consente di limitare parzialmente l'accesso. Ad esempio, l'utente vede solo i documenti per un determinato magazzino e organizzazione e non vede il resto.

Accuratamente! Quando si utilizza lo schema confuso RLS 1C, utenti diversi potrebbero avere domande quando tentano di riconciliare lo stesso report generato da utenti diversi.

Ti prendi una certa directory (ad esempio, organizzazioni) e un certo diritto (ad esempio, lettura). Consenti la lettura per il ruolo 1C. Nel pannello Restrizione accesso ai dati, imposti il ​​testo della query, che restituisce VERO o FALSO a seconda delle impostazioni. Le impostazioni vengono generalmente archiviate in un registro delle informazioni (ad esempio, il registro delle informazioni di configurazione Impostazioni contabilità e diritti di accesso utente).

Questa query viene eseguita dinamicamente (quando si tenta di implementare la lettura) per ciascuna voce di directory. Pertanto, per i record per i quali la query di sicurezza ha restituito TRUE, l'utente li vedrà, ma il resto no.
I diritti 1C soggetti alle restrizioni RLS 1C sono evidenziati in grigio.

La copia delle stesse impostazioni RLS 1C viene eseguita utilizzando i modelli. Crei un modello, lo chiami (ad esempio) MyTemplate e in esso specifichi la richiesta di sicurezza. Successivamente, nelle impostazioni dei diritti di accesso 1C, specifica il nome del modello in questo modo: "#MyTemplate".

Quando un utente lavora in modalità 1C Enterprise, quando esegue RLS 1C, potrebbe ricevere un messaggio di errore "Diritti insufficienti" (ad esempio, per leggere la directory Xxxx).

Ciò significa che RLS 1C ha bloccato la lettura di diversi record.

Per evitare che venga visualizzato un messaggio di questo tipo, è necessario utilizzare la parola CONSENTITO () nel testo della richiesta nel linguaggio 1C integrato.

Per esempio: