Forum: Italian Ruby user group check sulla sessione nel controller

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-01 20:08
Salve ragazzi,
come posso abilitare la cache di alcune view nel controller solo se
l'utene non è loggato?
Mi spiego meglio:
nel mio view_controller ho:

caches_page :index

ho bisogno di qualcosa del genere:

if session[:user_id]
caches_page :index
end

ovviamente scritto così nel controller non funge.

Come faccio?

Grazie mille

Luigi
7daea92c28be2e85196a4f6dfdb2f689?d=identicon&s=25 Claudio Petasecca Donati (etapeta)
on 2009-05-04 11:15
Luigi Maresca wrote:
> Salve ragazzi,
> come posso abilitare la cache di alcune view nel controller solo se
> l'utene non è loggato?
> Mi spiego meglio:
> nel mio view_controller ho:
>
> caches_page :index
>
> ho bisogno di qualcosa del genere:
>
> if session[:user_id]
> caches_page :index
> end
>
> ovviamente scritto così nel controller non funge.
>
> Come faccio?
>
> Grazie mille
>
> Luigi

Prova con:

caches_page :index, :if => Proc.new {|c| c.request.session[:user_id] }
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-05-04 12:26
(Received via mailing list)
Innanzitutto scorda caches_page.
Ti spiego, questa macro genera un file html statico nella tua cartella
pubblica, *tutte* le successive request verranno soddisfatte servendo
staticamente quel file.

Per cui se il primo utente che visita quella route è loggato, è
probabile che quella pagina abbia qualche contenuto che non dovrebbe
essere visibile ad un utente che non lo è. Esempio: il link "logout".
In questo caso tutte le request successive verranno servite con quello
specifico output. Il che ovviamente non va bene, perché potrebbe
contenere dati sensibili dell'utente.

La soluzione è caches_action
(http://api.rubyonrails.org/classes/ActionControlle...),
la quale genera ugualmente dell'html, ma ne fa lo storing nella cache di
Rails, anziché nella cartella pubblica. Questo comporta una differenza
sostanziale, perché la request passa *sempre* attraverso ActionPack,
quindi con i tuoi before_filter puoi decidere se e quando utilizzare il
caching.

Ti consiglio queste letture:
* http://railsenvy.com/2007/2/28/rails-caching-tutorial
*
http://www.railsenvy.com/2007/3/20/ruby-on-rails-c...
*
http://www.37signals.com/svn/posts/1557-javascript...
* http://lucaguidi.com/2009/02/09/rails-caching-and-javascript
* http://lucaguidi.com/2009/02/13/rails-caching-and-...

Luca
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-04 14:09
Ciao Claudio, lo provo stasera dovrebbe fare al caso mio.

Ciao Luca,
grazie mille per l'aiuto.
La macro caches_page so che genera il file html statico e dato che per
l'applicazione in questione solo io modifico il db, ogni volta che ci
entro e lo modifico viene lanciata la cancellazione dei file statici.

Il problema, come hai intuito, è proprio il link al logout che non deve
essere memorizzato nel file statico quando io sono loggato, però
appunto, dato che si tratta della home page, il relativo file statico
viene cancellato ad ogni modifica.

Cmq per alcune view, come la index, può sicuramente essere conveniente,
come dici tu, utilizzare la caches_action.

Per altre view che si distinguono una dall'altra per il percorso in cui
si trovano e non per il nome, non posso utilizzare la caches_action
perché non funzionerebbe da cache.

Grazie mille!!!

Luigi
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-05-04 15:44
(Received via mailing list)
Luigi Maresca wrote:
> Il problema, come hai intuito, è proprio il link al logout che non deve
> essere memorizzato nel file statico quando io sono loggato, però
> appunto, dato che si tratta della home page, il relativo file statico
> viene cancellato ad ogni modifica.
Il primo dei miei due post linkati spiega come risolvere il problema con
javascript. Il caso d'uso è identico.

Luca
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-04 22:57
Ciao ragazzi,
stavo provando la soluzione suggerita da Claudio ma non funge:

caches_page :index, :if => Proc.new {|c| !c.request.session[:user_id] }

...ho aggiunto un punto esclamativo perché a me serve che il cache_pages
venga eseguito solo se NON si è loggati.
Ad ogni modo non funziona neppure senza punto esclamativo e cioè il
caches_page lo fa sia che si è loggati che non!

Suggerimenti?


Grazie mille come sempre

Luigi
42651926eec2d760f10c78bcb473e5e3?d=identicon&s=25 Fabrizio Regini (Guest)
on 2009-05-04 23:32
(Received via mailing list)
Ciao,

Il giorno 04/mag/09, alle ore 12:25, Luca Guidi ha scritto:

> Per cui se il primo utente che visita quella route è loggato, è
> probabile che quella pagina abbia qualche contenuto che non dovrebbe
> essere visibile ad un utente che non lo è. Esempio: il link "logout".
> In questo caso tutte le request successive verranno servite con quello
> specifico output. Il che ovviamente non va bene, perché potrebbe
> contenere dati sensibili dell'utente.

come hai giustamente detto, l'output specifico per un utente loggato
*potrebbe* contenere dati sensibili.
Ad ogni modo, con la dovuta accortezza, è possibile generare file di
cache diversi che riportino come prefisso, ad esempio, l'id
dell'utente loggato.
In questo modo non si rischia di rivelare dati di un utente loggato ad
un'altro.
Il meccanismo si chiama fragment_caching, ed è spiegato nell'episodio
#7 della serie "Scaling Rails" (5:22).

Si applica nella vista:
<% cache("#{current_user.id}_frammento_di_cache") do %>
  <div>Contenuto da cachare</div>
<% end -%>

e per farlo scadere:

expire_fragment "#{current_user.id}_frammento_di_cache"
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-05-05 00:11
(Received via mailing list)
Infatti io parlavo del page caching, il fragment caching è più fine
grained, e serve proprio a questo. Nel caso riportato da Luigi, l'action
caching dovrebbe essere sufficiente.

Luca
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-06 09:39
---------problema 1--------

...nessuno mi riesce ad aiutare per far funzionare:

caches_page :index, :if => Proc.new {|c| !c.request.session[:user_id] }

che sarebbe l'ideale per me!?!?!

-------problema 2---------

Mi sono nel frattempo, caricando un pò di aggiornamenti al codice,
accorto di avere un altro problema:

Ho voluto migliorare un pò il sito eliminando pagine dinamiche del tipo
../?category=Antivirus e redirezionandole a indirizzi del tipo

http://www.software-windows.net/lista/software/ant...

questa pagina come altre, come quelle relative alla paginazione, sono
tutte riferite alla vista "index".

Il problema che ho sta nel fatto che non posso, nel frattempo che i
vecchi indirizzi vengono sostituti, da Google, con i nuovi, attivare il
caches_page o il caches_action su tale vista che genera, ovviamente,
anche l'index del sito.

Qualche idea?

Grazie

Luigi
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-06 11:57
...perdonatemi non ho completato il discorso:

dicevo, non posso cachare l'index perché la richiesta del tipo
../?category=Antivirus viene redirezionata all'indirizzo statico tramite
un redirect_to che sta nel controller, in particolare in:

def index
...
end

quindi se faccio la cache della index il codice non viene eseguito e
nemmeno il redirect!

Come potrei fare a cachare lo stesso la index?

Grazie ancora

Luigi
42651926eec2d760f10c78bcb473e5e3?d=identicon&s=25 Fabrizio Regini (Guest)
on 2009-05-06 21:24
(Received via mailing list)
Il giorno 06/mag/09, alle ore 09:39, Luigi Maresca ha scritto:

> caches_page :index, :if => Proc.new {|c| !
> c.request.session[:user_id] }

Questa soluzione è documentata, cerchiamo di capire perchè non funziona.
A me funziona benone.
Provalo prima con un semplice booleano:

caches_page :index, :if => Proc.new {|c| true }

e

caches_page :index, :if => Proc.new {|c| false }

se funziona vuol dire che c'è un errore nell'espressione !
c.request.session[:user_id].

Inoltre, di default il caching è disabilitato in development. Attivalo
nel file development.rb:

config.action_controller.perform_caching             = true

Ciao,

Fabrizio Regini
fabrizio.regini@exelab.eu
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-06 22:13
Nel development è abilitato, il mio problema è infatti che l'espressione
:if non lo disabilita!

Cheidevo infatti se per caso ci fosse qualche errore nella stringa:

c.request.session[:user_id]

Grazie

Luigi
42651926eec2d760f10c78bcb473e5e3?d=identicon&s=25 Fabrizio Regini (Guest)
on 2009-05-07 10:01
(Received via mailing list)
Questo dipende dalla tua implementazione.

Anzichè caches_page :index, :if => Proc.new {|c| true }, prova a
mettere un punto di interruzione:

caches_page :index, :if => Proc.new {|c| debugger }

Rilancia il server con l'opzione -u, cancella eventuali file cachati,
ricarica e dovresti entrare in debug.

Il giorno 06/mag/09, alle ore 22:13, Luigi Maresca ha scritto:
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-07 10:07
...mmmhhhh....come si fa ad entrare in debug?...e cioè come si lancia il
server con l'opzione -u.

Io uso, in locale, InstantRails2.0.


Grazie

Luigi
42651926eec2d760f10c78bcb473e5e3?d=identicon&s=25 Fabrizio Regini (Guest)
on 2009-05-07 10:33
(Received via mailing list)
Ok, non so su windows che differenze ci siano, quindi non ti posso
aiutare molto.
Anche senza usare il debug, fatti stampare un output nel browser per
capire qualcosa in più sulla condizione che non ti funziona.

Il giorno 07/mag/09, alle ore 10:07, Luigi Maresca ha scritto:
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-07 10:35
> Anche senza usare il debug, fatti stampare un output nel browser per
> capire qualcosa in pi?la condizione che non ti funziona.

...perdonatemi, ma non so come si fa neppure quest'altra cosa!
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-05-07 10:43
(Received via mailing list)
Elimina manualmente il file html dalla directory pubblica. :)
598fadf49a8e63645edfb36cba7dc1c9?d=identicon&s=25 Luigi Maresca (luigi-s-w-net)
on 2009-05-07 10:47
Mi sto perdendo:

> Anche senza usare il debug, fatti stampare un output nel browser per
> capire qualcosa in più sulla condizione che non ti funziona.

questo voleva dire fai generare al codice le pagine html?
42651926eec2d760f10c78bcb473e5e3?d=identicon&s=25 Fabrizio Regini (Guest)
on 2009-05-07 11:32
(Received via mailing list)
In modo molto rozzo, una cosa del genere:

def index
  raise params.inspect
end

Il raise ferma l'esecuzione e ti stampa l'hash params nel browser
Ovviamente è un esempio.

Il giorno 07/mag/09, alle ore 10:47, Luigi Maresca ha scritto:
This topic is locked and can not be replied to.