Come memorizzare nella cache i moduli con un proxy inverso e gestire i token dei moduli non aggiornati?

Quando l' API del modulo genera un modulo, genera anche un token che viene passato con il modulo in un campo nascosto e che dovrebbe essere restituito. In tal caso, il modulo viene elaborato.

Se una forma renderizzata dovesse mai essere memorizzata nella cache, diciamo, da parte di Varnish , questo meccanismo si rompe. Il primo utente che invia il modulo consumerà il token e i successivi tentativi di utilizzo del modulo verranno rifiutati.

Quali strategie sono disponibili per mantenere attive le forme mentre memorizza nella cache la loro forma renderizzata?

caching forms

— Letharion
fonte

Sei sicuro di questo? Ho creato siti con moduli e proxy inversi e non ho riscontrato alcun problema. L'unica cosa che devi guardare, in generale, è assicurarti che le pagine dei risultati non vengano memorizzate nella cache.

— Alfred Armstrong,

Mi piacerebbe essere smentito, poiché ciò risolverebbe il mio problema, ma sì, ne sono sicuro. :) Controlla le funzioni form_ {g, s} et_cache per i dettagli.

— Letharion,

Per gli utenti anonimi, sono sicuro che una pagina con un modulo può essere memorizzata nella cache in modo sicuro. Per gli utenti non anonimi, i proxy inversi sono comunque problematici.

— Alfred Armstrong,

(I token vengono generati solo quando un utente ha un ID.)

— Alfred Armstrong

Ah, ha senso. Purtroppo i miei utenti in questo caso sono autenticati. Forse la domanda dovrebbe essere riformulata per includerlo.

— Letharion,

Risposte:

Uso BOA per i miei siti, ma per impostazione predefinita BOA disabilita semplicemente la memorizzazione nella cache del front-end per l'invio di moduli. Al di là della mia esperienza reale, mi sono imbattuto in un artificiale di un anno su come la New Zealand Post affronta Drupal & Varnish e la questione dei token di forma. Santo John Wayne, è assolutamente da leggere per la memorizzazione nella cache di Drupal, davvero. Concentrandosi solo sulla questione del modulo:

L'ultimo pezzo del nostro puzzle è il modulo Advanced Cache Bypass Advanced , che imposta automaticamente uno speciale cookie NO_CACHE ogni volta che l'utente invia un modulo POST sul sito, inclusi elementi come il modulo di accesso. La nostra vernice è configurata per bypassare la cache della pagina (ma non la cache ESI) quando vede questo cookie.

Puoi anche disabilitare i token del modulo quando la produzione XSRF non è richiesta con in form_alter (unset ($ form ['# token']);) o ($ form ['# token'] = FALSE;)

Un articolo di performance di Acquia Drupal pubblica un modulo Drupal Authcache , ma leggendo il documento su Authcache, risolve la memorizzazione nella cache con un segnaposto per il modulo (non memorizza nella cache il modulo):

Authcache tenta di intercettare qualsiasi contenuto personalizzato e impostare un segnaposto all'interno dell'HTML. Quindi, dopo aver caricato la pagina, viene utilizzato un callback Ajax per recuperare dati personalizzati e compilare i segnaposto, aggiornando dinamicamente l'HTML della pagina.

Segnaposti di Authcache correnti: token modulo (solo utenti connessi; richiesto da> Drupal per prevenire attacchi di falsificazione di richieste tra siti)

La strategia è, cache tutto tranne il modulo . Quindi, affrontando tutto il resto: forse Varnish non viene usato affatto, Memcache e Redis? La mia strategia sarebbe quella di utilizzare ciò che offre BOA perché io uso BOA e i maghi dietro di esso ( omega8.cc ) ne sanno molto di più di me. Non penso che ci sia una cache esterna che risolva il problema. Sembrano tutti aggirare il modulo.

Fare il caching parziale con l'authcache di cui sopra e con vista finemente ottimizzato e pannelli, come indicato nell'articolo NZ Post e descritta dalla fiducia cervello alla Wunderkraut - il suo vecchio, ma affronta il problema.

Usa il modulo Drupal ESI e Varnish è parzialmente conforme ESI):

ESI - o Edge Side Includes - è una soluzione di memorizzazione nella cache ad alte prestazioni per utenti autenticati ma può essere utile anche per utenti anonimi.

In genere, le pagine personalizzate per gli utenti autenticati (anche le personalizzazioni minori, come un blocco che dice "Accesso eseguito come manarth") impediranno ai proxy inversi (che possono facilmente eseguire 100 volte più velocemente di Drupal) di memorizzare nella cache la cache, poiché i messaggi destinato a un utente potrebbe quindi essere visto da un altro.

Spero sia più utile.

— Tom
fonte

Una rapida occhiata al codice suggerisce che il modulo ESI non fa nulla per quanto riguarda la validazione dei moduli; nessuna menzione della gestione dei token, né alcuna modifica interessante della forma. È possibile che tu non abbia semplicemente memorizzato nella cache dei moduli che richiedono l'autenticazione in vernice, ed è per questo che non hai mai visto questo problema?

— Letharion,

Si scopre che è esattamente quello che sta succedendo, BOA bypassa la cache del front-end al volo per i moduli (mi dispiace per la mia risposta precedentemente incompleta / errata). ESI è ancora parte importante della strategia "cache all but but" ora nella mia risposta anche se non risolve direttamente.

— Tom,

Quell'articolo postale della Nuova Zelanda era davvero molto interessante. Tuttavia, per quanto posso dire, risolve solo il problema del token con: "Nei casi in cui sei sicuro che la protezione XSRF non sia importante ... Drupal fornisce un meccanismo per disabilitare i token dei moduli", che non è utile in il mio caso.

— Letharion,

Molte informazioni utili però, e sicuramente altri saranno in grado di applicarle ai loro problemi. +1, e poiché è rimasta solo un'ora, posso anche essere consapevole della generosità. :)

— Letharion,

Una potenziale soluzione sarebbe quella di disabilitare il token insieme $form[‘#token’] = FALSE;, quindi sovrascrivere il callback di invio invece di pubblicare effettivamente il commento, rigenerare il modulo originale con un token e chiedere all'utente di confermare il post.

Se l'utente supporta ECMAScript , si potrebbe migliorare l'esperienza dell'utente disponendo di una risorsa di servizi che espone la generazione di moduli di nuovi token di modulo e inserisce il modulo pertinente nel form_cache. Quindi, non appena l'utente si concentra sul modulo ed è quindi probabile che lo desideri inviare, disabilitare il pulsante di invio, recuperare un nuovo token e inserirlo nel modulo già reso e abilitare nuovamente il pulsante di invio.

— Letharion
fonte