Artikull mbi zbatimin e Row Level Security në PostgreSQL

Si një shtesë për Artikull mbi zbatimin e logjikës së biznesit në nivelin e funksioneve të ruajtura PostgreSQL dhe pjesën kryesore të përgjigjes së zgjeruar në koment.

Pjesa teorike është përshkruar shkëlqyeshëm në dokumentacion Postgres Pro — Politikat e mbrojtjes së rreshtave. Më poshtë është shqyrtuar një zbatim praktik të një problemi të caktuar biznesi — fshehja e të dhënave të fshira. Studimi i kushtohet realizimit modelit të rolit duke përdorur RLS është paraqitur veçmas.

Në artikull nuk ka asgjë të re, nuk ka kuptim të fshehur dhe njohuri sekrete. Vetëm një skicë mbi realizimin praktik të një ideje teorike. Nëse dikujt i intereson — lexoni. Atëherë shihni, mos e humbni kohën tuaj kot.

Formulimi i detyrës

Pa u thelluar shumë në fushën temore, shkurt, detyra mund të formulohet kështu: kemi një tabelë që realizon një entitet biznesi. Rreshtat në tabelë mund të fshihen, por nuk lejohet të fshihen fizikisht rreshtat, duhet t'i fshehim ata.

Sepse është thënë — "Mos fshij asgjë, vetëm riemërto. Interneti ruan GJITHÇKA"

Për më tepër, është gjithashtu e dëshirueshme të mos ri-shkruhen funksionet e ruajtura ekzistuese që punojnë me këtë entitet.

Për të realizuar këtë koncept, tabela ka një atribut is_deleted. Pastaj gjithçka është e thjeshtë — duhet të bëhet në mënyrë që klienti të mund të shohë vetëm rreshtat në të cilat atributi is_deleted është i pavërtetë. Për këtë, përdoret mekanizmi Row Level Security.

Implementimi

Krijojmë një rol të veçantë dhe një skemë

CREATE ROLE repos;
CREATE SCHEMA repos;

Krijojmë tabelën e synuar

CREATE TABLE repos.file
(
...
is_del BOOLEAN DEFAULT FALSE
);
CREATE SCHEMA repos

Aktivizoni Row Level Security

ALTER TABLE repos.file  ENABLE ROW LEVEL SECURITY ;
CREATE POLICY file_invisible_deleted  ON repos.file FOR ALL TO dba_role USING ( NOT is_deleted );
GRANT ALL ON TABLE repos.file to dba_role ;
GRANT USAGE ON SCHEMA repos TO dba_role ;

Funksioni shërbimit — fshirja e rreshtit në tabelë

CREATE OR REPLACE repos.delete( curr_id repos.file.id%TYPE)
RETURNS integer AS $$
BEGIN
...
UPDATE repos.file
SET is_del = TRUE 
WHERE id = curr_id ; 
...
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

Funksioni biznesor — fshirja e dokumentit

CREATE OR REPLACE business_functions.deleteDoc( doc_for_delete JSON )
RETURNS JSON AS $$
BEGIN
...
PERFORM  repos.delete( doc_id ) ;
...
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

Rezultatet

Klienti fshin dokumentin

SELECT business_functions.delCFile( (SELECT json_build_object( 'CId', 3 )) );

Pas fshirjes, klienti i dokumentit nuk e sheh

SELECT business_functions.getCFile"( (SELECT json_build_object( 'CId', 3 )) ) ;
-----------------
(0 rows)

Por në DB dokumenti nuk është fshirë, vetëm është ndryshuar atributi is_del

psql -d my_db
SELECT  id, name , is_del FROM repos.file ;
id |  name  | is_del
--+---------+------------
 1 |  test_1 | t
(1 row)

Çka kërkonte në formulimin e detyrës.

Përfundimi

Nëse tema do të jetë interesante, në studimin e ardhshëm mund të tregohet një shembull realizimi të modelit të rolit të ndarjes së qasjes në të dhëna duke përdorur Row Level Security.

Burimi: habr.com