Passaggio variabili al modello

Rieccomi,dopo tanto tempo,a scrivere sul forum…Sto cominciando a
preparare la tesi su rails,quindi credo che avrò molto bisogno di
aiuto!!!
Innanzitutto,vorrei sapere se,come per il controller e per l’helper,
esiste un modo per far “ereditare” del codice a tutti i modelli:in
pratica,vorrei che un before_create possa essere scritto una volta per
tutte e verificato da tutti i modelli.
Più precisamente,vorrei che il salvataggio di una nuova riga venga
consentito solo se l’utente ha determinati privilegi. Ma come faccio a
passare la variabile al modello (supponendo per esempio che la variabile
sia una sessione?).
Aspetto un vostro aiuto/suggerimento. Grazie!

Alessandro M. wrote:

Innanzitutto,vorrei sapere se,come per il controller e per l’helper,
esiste un modo per far “ereditare” del codice a tutti i modelli:in
pratica,vorrei che un before_create possa essere scritto una volta per
tutte e verificato da tutti i modelli.
Più precisamente,vorrei che il salvataggio di una nuova riga venga
consentito solo se l’utente ha determinati privilegi. Ma come faccio a
passare la variabile al modello (supponendo per esempio che la variabile
sia una sessione?).
Aspetto un vostro aiuto/suggerimento. Grazie!

Sei sicuro di voler “sporcare” il modello con problematiche di
autorizzazione?

Le operazioni che si effettuano su un dominio non hanno la pretesa di
essere atomiche.
Si puo’ chiamare un metodo di un oggetto di modello sapendo che lo stato
del sistema sara’ temporaneamente instabile.
E’ per questo che il modello viene blindato con uno strato di servizi (i
controller, appunto) che gestiscono la transazionalita’ ed altre
problematiche trasversali, tra cui l’autenticazione.
Il controller garantisce che ogni servizio da lui esposto mantiene il
sistema in uno stato stabile, non corrotto.

Inoltre spesso l’autorizzazione viene demandata a sistemi esterni,
proprio per la trasversalita’ della problematica che suggerisce di
implementarla in un unico posto a fronte di diverse applicazioni che lo
usano.

E’ chiaro che se vuoi gestire l’autorizzazione internamente, le entita’
necessarie all’autorizzazione dovranno far parte del modello.
Ma vedo rischioso utilizzarle in un before_create di modello.

Ma veniamo al tuo punto chiave.

L’autorizzazione in before_create richiede la conoscenza di chi ha
richiesto l’operazione.
Se un model.save non contiene questa informazione, il before_create puo’
ottenerla solo dal contesto.
Ovvero da una variabile globale (o di classe), come User.current.
Ma questo significa sporcare il modello, perche’ un “utente corrente”
non e’ parte del dominio.
Un dominio deve essere definito indipendentemente da chi lo usa, o da
quanti lo usano.

Nelle mie applicazioni l’autorizzazione e’ gestita dal controller in un
modo simile a questo:

before_filter :authorize, :except => [:register, :login]

dove

def authorize(ctrl = params[:controller], action = params[:action])
User.find(session[:user]).allowed_to?({:controller => ctrl, :action
=> action})
end

e’ definita in app/controllers/application.rb

Claudio Petasecca D. wrote:

Alessandro M. wrote:

Innanzitutto,vorrei sapere se,come per il controller e per l’helper,
esiste un modo per far “ereditare” del codice a tutti i modelli:in
pratica,vorrei che un before_create possa essere scritto una volta per
tutte e verificato da tutti i modelli.
Più precisamente,vorrei che il salvataggio di una nuova riga venga
consentito solo se l’utente ha determinati privilegi. Ma come faccio a
passare la variabile al modello (supponendo per esempio che la variabile
sia una sessione?).
Aspetto un vostro aiuto/suggerimento. Grazie!

Sei sicuro di voler “sporcare” il modello con problematiche di
autorizzazione?

Le operazioni che si effettuano su un dominio non hanno la pretesa di
essere atomiche.
Si puo’ chiamare un metodo di un oggetto di modello sapendo che lo stato
del sistema sara’ temporaneamente instabile.
E’ per questo che il modello viene blindato con uno strato di servizi (i
controller, appunto) che gestiscono la transazionalita’ ed altre
problematiche trasversali, tra cui l’autenticazione.
Il controller garantisce che ogni servizio da lui esposto mantiene il
sistema in uno stato stabile, non corrotto.

Inoltre spesso l’autorizzazione viene demandata a sistemi esterni,
proprio per la trasversalita’ della problematica che suggerisce di
implementarla in un unico posto a fronte di diverse applicazioni che lo
usano.

E’ chiaro che se vuoi gestire l’autorizzazione internamente, le entita’
necessarie all’autorizzazione dovranno far parte del modello.
Ma vedo rischioso utilizzarle in un before_create di modello.

Ma veniamo al tuo punto chiave.

L’autorizzazione in before_create richiede la conoscenza di chi ha
richiesto l’operazione.
Se un model.save non contiene questa informazione, il before_create puo’
ottenerla solo dal contesto.
Ovvero da una variabile globale (o di classe), come User.current.
Ma questo significa sporcare il modello, perche’ un “utente corrente”
non e’ parte del dominio.
Un dominio deve essere definito indipendentemente da chi lo usa, o da
quanti lo usano.

Nelle mie applicazioni l’autorizzazione e’ gestita dal controller in un
modo simile a questo:

before_filter :authorize, :except => [:register, :login]

dove

def authorize(ctrl = params[:controller], action = params[:action])
User.find(session[:user]).allowed_to?({:controller => ctrl, :action
=> action})
end

e’ definita in app/controllers/application.rb

E infatti alla fine ieri avevo deciso di fare come hai proposto tu:
before_filter :check_privileges_for_create, :only => [:new,:create]

Il problema era che ho bisogno di creare del codice “generico”, in cui
passando la struttura del database (o definendo le tabelle che devono
essere presenti,con le relative relazioni) viene automaticamente creata
l’applicazione e anche la gestione dei permessi (quali operazioni sono
concesse agli utenti, quali campi possono essere
visualizzati/aggiornati,ecc…). Quindi,pensavo che avvalendomi del
before_create si sarebbe potuto astrarre meglio,poichè col filtro
presente nel controller va invece definita a priori l’azione su cui
eseguire il filtro stesso. In questo caso: se l’utente lascia che le
azioni per creare una nuova riga si chiamino create va tutto ok,ma se
l’azione per creare viene chiamata,ad esempio, save? Il filtro non viene
applicato,se non si aggiunge manualmente anche :save in :only.
Comunque sia,la parte più difficile viene adesso: a seconda dei
privilegi,l’utente può visualizzare/aggiornare solo alcuni dei campi di
una tabella,quindi bisogna fargli visualizzare solo i campi a cui può
avere accesso. Il tutto in modo “generale”,poichè il codice deve
astrarre dall’applicazione. Che Dio mi aiuti!!!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs