««« | »»»
PostgreSQL: passare le informazioni di sessione dall’applicazione
Nelle applicazioni che sfruttano una connessione persistente verso il database e implementano al loro interno la logica di autenticazione e autorizzazione, può presentarsi la necessità di passare al database delle informazioni relative all’utente dell’applicazione, che sarà diverso da quello usato per connettersi al database.
In molti casi, se si tratta solo di inserire le informazioni di auditing su poche tabelle, è sufficiente che sia l’applicazione a passare esplicitamente queste informazioni, durante il salvataggio dei record. Se l’auditing va fatto su tutte le tabelle si può progettare il codice in modo da rendere l’operazione più o meno trasparente.
Non sempre questo è possibile — le modifiche al codice sarebbero troppo onerose o impossibili — né adeguato. Ad esempio, quando vogliamo tracciare eventuali attività svolte al di fuori del controllo dell’applicazione. In questi casi la soluzione dev’essere trovata al livello del database.
Il problema diventa quindi come passare in modo trasparente i dati sull’utente dell’applicazione. Una possibilità consiste nell’usare le cosiddette opzioni custom in combinazione con le trigger.
Al login sull’applicazione verrà chiamata una funzione che imposta il valore dell’opzione custom:
CREATE OR REPLACE FUNCTION begin_sess(staffid text) RETURNS void AS $$ BEGIN PERFORM set_config( 'mysess.curr_user', coalesce(staffid,''), false ); END; $$ LANGUAGE 'plpgsql' VOLATILE
Con questa informazione, basta agganciare una trigger ad ogni tabella che ci interessa:
... DECLARE curr_user staff.staff_id%TYPE; BEGIN SELECT current_setting('mysess.curr_user') INTO curr_user; ...
Se il valore di mysess.curr_user fosse vuoto, ad es. perché l’operazione viene fatta direttamente sul database, basterà ripiegare sull’utente a livello del database.
Le informazioni riportate qui sono state ricavate più o meno pedissequamente da questo thread: Audit Trigger puzzler.
Per proseguire
Commenti e trackback sono disabilitati.