Categories
Uncategorized

AMP Camp: Cross-origine stato utente in AMP

TheMummichogblog è un partecipante al Amazon Services LLC Associates programma, un programma di affiliazione pubblicitario progettato per fornire un mezzo per siti per guadagnare tariffe pubblicitarie con la pubblicità e il link al amazon.com. Amazon, il logo di Amazon, AmazonSupply, e il logo AmazonSupply sono marchi di Amazon.com, Inc. o delle sue affiliate.

--------------------------------------------------------------------------------------------------
Booking.com
Eppure egli si è caricato delle nostre sofferenze, si è addossato i nostri dolori e noi lo giudicavamo castigato, percosso da Dio e umiliato.
----------------------------------------------------------------------------------------------

AMP Camp: Cross-origine stato utente in AMP

tl; dr: Questo articolo vi insegnerà come monitorare le azioni degli utenti tra il dominio e AMP cache.

Benvenuti alla più recente nella nostra serie di post su AMP Camp, il nostro demo che mostra come creare un sito interattivo con AMP! In questa serie, discuteremo le tecniche e gli strumenti che abbiamo usato nella creazione di esso, così come le best practice che abbiamo sviluppato. Se siete interessati a creare un sito interattivo con AMP, ci auguriamo che imparerai qualcosa!

Nel post precedente, abbiamo parlato di come utilizzare i modelli sia sul client e il server. In questo post, parleremo di best practice per il monitoraggio dello stato utente tra la provenienza e le cache AMP.

Stato utente e cache AMP
Se un utente visita il tuo sito su una cache AMP e di nuovo sul proprio dominio, è importante riconoscere che sia i visitatori sono la stessa persona. Questo può prendere un po ‘di lavoro. Fortunatamente, c’è una soluzione!

Immaginate questo: si esegue BestClips, un sito che vende il maggior numero di graffette efficaci in tutto il mondo. Ogni clip può contenere fino a 50 fogli di carta, e sono completamente realizzata al 100% soia biodegradabili!

Dal momento che si desidera agli utenti di visualizzare i clip più velocemente possibile, hai costruito le pagine di prodotto con AMP. Servite le pagine AMP dal tuo dominio, bestclips.com. E quando spider web come Google e Bing di scoprire queste pagine AMP, vengono memorizzati nella cache AMP. Così, quando un utente scopre la pagina del prodotto in Google o Bing Search, saranno visualizzarlo in un iframe su un sito come google.com o bing.com, e la pagina sarà servita da una cache AMP, come CDN. ampproject.org o bing-amp.com. Fin qui tutto bene!

Ma cosa succede se un utente scopre la vostra pagina su una cache AMP, aggiungono graffette al loro carrello, e nel corso della giornata che visitano il sito di nuovo bestclips.com? Saranno i clip essere ancora nel loro carrello? O sarà il carro vuoto?

(Se il tuo sito utilizza uno scambio firmato, molti browser mostrerà il tuo dominio di origine anche quando la pagina è stata servita da una cache. In questo caso, il problema svanisce. In caso contrario, è bene sapere come trattare con esso.)

Qual è il problema?
AMP cache contribuire a rendere le pagine web veloce, preservando la privacy degli utenti! Ma una cache introduce anche un ulteriore livello di complessità: gli utenti possono accedere al sito non solo sul tuo dominio, ma anche sul dominio del cache.

diciamo di lasciare che bestclips.com, seguendo la pratica web standard, tiene traccia dello stato di un utente facendo cadere un cookie che contiene un ID di sessione. Poi, ogni volta che l’utente visita il tuo pagine su bestclips.com, il server recupera il cookie, si legge l’ID di sessione, e ripristina lo stato utente dai dati memorizzati sul server che è associato con tale ID.

Ora, diciamo che l’utente visita la pagina del prodotto, vedono alcune graffette che non può vivere senza, e vogliono aggiungere quelli al carrello. Essi clic su un pulsante, e il tuo sito sottomette i dati al server:


Se l’utente è sulla vostra origine, la richiesta viene fornito con un cookie di sessione. In parte, la richiesta sarebbe simile a questa:

POST / add-to-cart HTTP / 2.0
Cookie: session_id = 12345
Ma se l’utente visita il vostro sito su una cache AMP, la richiesta al server potrebbe effettivamente derivare da ampproject.org o bing-amp.com – un dominio diverso! Il browser associa il cookie con bestclips.com, e quindi ora è un cookie di terze parti. La maggior parte dei browser allegramente inviarli insieme. Ma utenti potrebbero avere impostare il proprio browser per bloccare i cookie di terze parti. E alcuni browser semplicemente bloccare un cookie di terze parti in determinate circostanze. Ciò renderebbe il vostro look richiesta in questo modo, senza intestazione di cookie:

POST / add-to-cart HTTP / 2.0
Cosa fare?

La soluzione, in breve
(Per semplicità, andando avanti, useremo il termine “origine” per riferirsi al proprio dominio, e la “cache” per riferirsi a una cache AMP.)

La soluzione è duplice. Sul vostro dominio, identificare gli utenti con un cookie di sessione, come al solito. Sul cache e su un browser che accetti cookie di terze parti, fare lo stesso. In caso contrario, ogni volta che un utente prende un’azione che lo stato dell’applicazione modifica, li reindirizza immediatamente alla vostra origine, dove è possibile accedere o creare un cookie memorizzato nel vostro dominio, e poi fare il cambiamento desiderato.

In altre parole, se l’utente vuole aggiungere graffette al loro carrello, e se non è possibile leggere il loro cookie, niente panico! Semplicemente li reindirizza alla vostra origine, in cui è possibile cambiare il loro carrello al contenuto del vostro cuore.

Questo reindirizzamento è reso possibile da un’intestazione HTTP AMP-specifico chiamato AMP-reindirizzamento-To. Se una pagina AMP fa una richiesta del server utilizzando , e la risposta del server contiene questa intestazione, AMP reindirizzerà alla pagina desiderata.

Ecco l’intero flusso:

L’utente accede alla pagina del prodotto. Se l’utente è l’origine, la provenienza imposta un cookie di sessione, se uno non è già presente.
L’utente prende un’azione per cambiare ciò che è nel carrello
Il browser invia i dati circa il cambiamento per l’origine tramite POST XHR
I controlli di origine se la richiesta non conteneva alcun cookie di sessione ed è venuto dalla cache
Se questo è vero:
La risposta dice AMP per reindirizzamento a un URL sull’origine che comprende una stringa di query che descrive il cambiamento dell’utente
Quando l’origine vede che stringa di query, si legge o crea il cookie, rende il cambiamento, e reindirizza ancora una volta a un URL sull’origine che non hanno la stringa di query fastidioso
Se questo non è vero, allora possiamo semplicemente recuperare la sessione dell’utente e fare il cambiamento dell’utente. O siamo in origine o siamo sulla cache con un browser che permette di cookie di terze parti.
Se l’utente comincia in cache o l’origine, entro la fine di questo processo hanno avuto una sessione e le loro variazioni si riflettono sul server.

La soluzione, in dettaglio
Cerchiamo di descrivere questo processo in dettaglio. Diciamo che un utente visita la nostra pagina del prodotto e decide di acquistare uno dei nostri nuovi Superclips. La nostra pagina del prodotto vite in https://bestclips.com/product, ma l’utente potrebbe accedere a questa pagina o sulla nostra origine o in una cache AMP.

Fase 1. L’utente arriva alla nostra pagina del prodotto. Questa pagina contiene un modulo che permette all’utente di selezionare una quantità, e un pulsante che permette loro di aggiungere il prodotto al loro carrello presentare. Questo aspetto potrebbe in questo modo:


Form>
Fase 2. Diciamo che le foglie degli utenti la quantità da “1” e rubinetti “Aggiungi al carrello”.

Fase 3. il modulo viene inviato, e AMP invia una richiesta POST XHR al nostro server, bestclips.com. (Per garantire che questa richiesta funzionerà anche da una cache, è necessario impostare CORS intestazioni Se si utilizza il nodo, si può semplicemente collegare il middleware AMP CORS..) Sull’origine, gli sguardi di richiesta di questo tipo:

POST / api / add-to-cart HTTP / 2.0
AMP-same-origin: true
Cookie: session_id = 12345
quantità = 2
Si noti che AMP comodamente aggiunge l’intestazione AMP-same-origin quando è in esecuzione sull’origine.

Se l’utente è sulla cache con un browser che permette di cookie di terze parti, la richiesta sarà simile a questa:

POST / api / add-to-cart HTTP / 2.0
Cookie: session_id = 12345
quantità = 2
Se l’utente è su una cache con un browser che i cookie blocchi di terze parti, l’intestazione Cookie mancheranno pure:

POST / api / add-to-cart HTTP / 2.0
quantità = 2
Fase 4. Ora arriva la parte divertente.

I controlli server per verificare se la richiesta è priva di un cookie di sessione ed è venuto dalla cache. Se non v’è alcun cookie, il browser non ha permesso un cookie da impostare. Questo potrebbe accadere anche se i blocchi del browser dell’utente tutti i cookie, nel qual caso, reindirizzando l’origine non aiuterebbe. Non saremmo mai in grado di monitorare lo stato dell’utente con i biscotti. Questo è il motivo per cui anche controllare per vedere se la richiesta è venuto dalla cache – perché questo è il caso si può affrontare.

Se la richiesta è priva di un cookie di sessione ed è venuto dalla cache, la richiesta mancherà sia l’intestazione Cookie e l’intestazione AMP-same-origin, come indicato sopra. Il server rileva questa condizione:

if (! request.cookies.session_id && request.headers [ ‘amp-same-origin’]! == ‘true’)
Se questo è vero, il server invia una risposta che indica AMP per reindirizzamento a un URL sull’origine. In questo URL, include una stringa di query che descrive il cambiamento dell’utente, in questo modo:

response.setHeader ( “AMP-Redirect-To”, `https://bestclips.com?item=$ {} request.body.itemName & quantità = $ {} request.body.quantity`);
Questo invia una risposta che contiene un’intestazione come questo:

AMP-Redirect-To: https:? //Bestclips.com/product item = SuperClip & quantità = 1
Quando questa risposta torna al browser, AMP nota l’intestazione e reindirizza a https://bestclips.com/product?item=superclip&quantity=1. Questa richiesta va a bestclips.com, la nostra origine! Il server di origine può quindi leggere il cookie di sessione o crearne uno se non esiste. Si aggiunge un SuperClip al carrello dell’utente. Poi si reindirizza a https://bestclips.com/product

In altre parole, si reindirizza indietro alla pagina del prodotto, senza la stringa di query. In questo modo, l’utente non avere difficoltà che potrebbero essere causati dalla stringa di query. (Vedere “Ecco come non farlo” sotto per motivi.)

Come promesso, ora l’utente ha un cookie di sessione e la modifica è stata effettuata sul server.

Posso usare client ID, invece?
Se avete lavorato con AMP, si può sapere che c’è il Client ID, che permette di analisi dei pacchetti di monitorare il viaggio di un utente dalla cache alla loro origine. Sulla origine, è memorizzato in un cookie e persiste per un anno. Sulla cache, è anche memorizzato in un cookie, e se non è in un cookie, si può essere creato con una chiamata al API Client ID. Quindi sarebbe tentati di utilizzare questa per identificare in modo coerente un utente.

Purtroppo, anche se i siti fanno utilizzare questa soluzione, si tratta con difetti. L’ID client identifica un singolo utente unicamente per alcuni viaggi tra le origini e le cache, ma non tutti. E il suo comportamento cross-site può essere bloccato dagli stessi browser che abbiamo avuto a che fare con tutto questo articolo.

L’AMP Linker rende questi viaggi di cross-site più affidabile, dal momento che conserva l’ID cliente come un parametro di stringa di query. Questo fornisce un altro modo per utilizzare l’ID cliente! Ma significa che l’identificatore univoco dell’utente sarà quindi visibile nel loro URL. URL tendono a fare il login su server, e talvolta cattivi attori scoprono i file di log. Peggio ancora, l’utente potrebbe anche condividere la loro URL pubblicamente, esponendo il loro identificativo per il mondo. In entrambi i casi, la loro sessione è vulnerabile agli hacker! Questo è il motivo per cui abbiamo usato il POST invece di GET nei nostri esempi di cui sopra.

Ho davvero bisogno di fare questo?
L’utente non può. Ma, come i browser bloccare i cookie di terze parti in sempre più casi, questa soluzione sarà sempre più essenziale per consentire agli utenti di utilizzare il sito senza problemi in tutta l’origine e la cache AMP. E mentre il flusso sopra richiede un po ‘di tempo per spiegare, non è difficile da implementare.

Veramente?
Verificare come abbiamo fatto nel sito dimostrativo AMP Camp. Ecco il codice del server. Ed ecco il modulo nella pagina del prodotto. L’unica differenza è che, in questo sito demo, quando l’utente aggiunge un elemento al loro carrello, noi li reindirizza alla pagina dei dettagli della spesa.

Scritto da Ben Morss, Developer Advocate

AMP Camp: Cross-origin user state in AMP

Amazon e il logo di Amazon sono marchi di Amazon.com, Inc., o delle sue affiliate.