Standard di codifica/decodifica cookie agnostici linguistici

Question

Ho difficoltà a capire qual è lo standard (o ce n'è uno?) Per codificare/decodificare i valori dei cookie indipendentemente dalle piattaforme di back-end.

Secondo RFC 2109:

il valore è opaco per il programma utente e può essere qualsiasi cosa, il server di origine sceglie di inviare, possibilmente in una codifica ASCII stampabile server selezionato. "Opaco" implica che il contenuto è di interesse e pertinenza solo per il server di origine. Il contenuto può, infatti, essere leggibile da chiunque tenti l'intestazione Set-Cookie.

che suona come "il server è il capo" e decide a prescindere dalla codifica. Ciò rende piuttosto difficile impostare un cookie, ad esempio il backend PHP e leggerlo da Python o Java o qualsiasi altra cosa, senza scrivere alcuna gestione manuale di codifica/decodifica su entrambi i lati.

Supponiamo di avere un valore che deve essere codificato. Il russo /"печенье (*} значения"/ significa "valore del cookie" con alcuni caratteri aggiuntivi alfanumerici.

Python:

Quasi tutti i server WSGI fa lo stesso e usa SimpleCookie classi di Python che codifica a/decodifica da octal literals anche se molti dice che octal literals are depreciated in ECMA-262, modalità rigorosa. Wtf?

Quindi, il nostro valore del cookie grezzo diventa "/\"\320\277\320\265\321\207\320\265\320\275\321\214\320\265 (*} \320\267\320\275\320\260\321\207\320\265\320\275\320\270\321\217\"/"

Node.js:

Non ho ancora testato a tutti, ma io sono solo indovinare un backend JavaScript sarebbe farlo con nativi encodeURIComponent e decodeURIComponent funzioni che usa hexadecimal di escaping/unescaping?

PHP:

PHP applica urlencode ai valori dei cookie che è simile a encodeURIComponent ma non esattamente la stessa cosa.

Quindi il valore grezzo diventa; %2F%22%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D1%8C%D0%B5+%28%2A%7D+%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D1%8F%22%2F che non è nemmeno racchiuso tra virgolette.

Tuttavia; se la variabile JavaScript value ha il valore codificato PHP sopra, decodeURIComponent(value) dà /"печенье+(*}+значения"/, vedere "+" caratteri al posto degli spazi ..

Qual è la situazione in Java, Ruby, Perl e .NET? Quale lingua segue (o il più vicino) al comportamento desiderato. In realtà, esiste uno standard definito da W3?

Answer 1

Penso che qui le cose siano un po 'confuse. La codifica del server non ha importanza per il client e non dovrebbe. Questo è ciò che RFC 2109 sta cercando di dire qui.

Il concetto di cookie in http è simile a questo nella vita reale: quando si paga la quota d'ingresso a un club si ottiene un timbro a inchiostro sul polso. Questo ti permette di uscire e rientrare nel club senza pagare di nuovo. Tutto quello che devi fare è mostrare il polso al buttafuori.In questo esempio di vita reale, non ti importa come appare, potrebbe anche essere invisibile nella luce normale - tutto ciò che è importante è che il buttafuori riconosca la cosa. Se dovessi lavarlo via, perderai il privilegio di rientrare nel club senza pagare di nuovo.

In HTTP sta succedendo la stessa cosa. Il server imposta un cookie con il browser. Quando il browser ritorna al server (leggi: la successiva richiesta HTTP), mostra il cookie sul server. Il server riconosce il cookie e agisce di conseguenza. Tale cookie potrebbe essere qualcosa di semplice come un indicatore "WasHereBefore". Ancora una volta, non è importante che il browser capisca di cosa si tratta. Se cancelli il tuo cookie, il server agirà come se non ti avesse mai visto prima, proprio come avrebbe fatto il buttafuori di quel club se ti lavassi quel timbro d'inchiostro.

Oggi, molti cookie memorizzano solo un'importante informazione: un identificatore di sessione. Tutto il resto è memorizzato sul lato server e associato a quell'identificatore di sessione. Il vantaggio di questo sistema è che i dati effettivi non lasciano mai il server e come tale possono essere considerati attendibili. Tutto ciò che è memorizzato sul lato client può essere manomesso e non dovrebbe essere considerato attendibile.

Edit: Dopo aver letto il tuo commento e leggere la tua domanda ancora una volta, credo di aver finalmente capito la tua situazione, e perché siete interessati nella codifica effettiva del cookie piuttosto che lasciarlo al vostro linguaggio di programmazione: Se si dispone di due diversi ambienti software sullo stesso server (ad esempio: Perl e PHP), è possibile che si desideri decodificare un cookie impostato dall'altra lingua. Nell'esempio sopra, PHP deve decodificare il cookie Perl o viceversa.

Non esiste uno standard per la memorizzazione dei dati in un cookie. Lo standard dice solo che un browser invierà il cookie esattamente come è stato ricevuto. Lo schema di codifica utilizzato è quello che il tuo linguaggio di programmazione ritiene opportuno.

Tornando all'esempio della vita reale, ora avete due buttafuori che parlano inglese, l'altro che parla russo. I due dovranno concordare un tipo di timbro a inchiostro. Più probabile che questo coinvolgerà almeno uno di loro che apprende la lingua dell'altro.

Poiché il comportamento del browser è standardizzato, è possibile imitare uno schema di codifica di una lingua in tutte le altre lingue utilizzate sul server o semplicemente creare uno schema di codifica standardizzato in tutte le lingue utilizzate. Potrebbe essere necessario utilizzare routine di livello inferiore, come PHP header() anziché routine di livello superiore, ad esempio start_session() per ottenere ciò.

BTW: allo stesso modo, è il linguaggio di programmazione lato server che decide come memorizzare i dati della sessione lato server. Non è possibile accedere a CGI::Session di Perl utilizzando l'array $_SESSION di PHP.

Answer 2

Indipendentemente dal fatto che il cookie sia opaco per il client, deve comunque essere conforme alle specifiche HTTP. rfc2616 specifica che tutte le intestazioni HTTP devono essere ASCII (ISO-8859-1). rfc5987 estende quello per supportare altri set di caratteri, ma non so quanto sia ampiamente supportato.

Answer 3

Preferisco codificare in UTF8 e includere la codifica in base64. È veloce, onnipresente e non mancherà mai i tuoi dati alle due estremità.

È necessario garantire una conversione esplicita in UTF8 anche quando lo si avvolge. Altre lingue & runtime, mentre supporta Unicode, potrebbe non memorizzare stringhe come UTF8 internamente ... come molte API di Windows. Python 2.x, nella mia esperienza, raramente ottiene stringhe Unicode a destra senza conversione esplicita.

ENCODE: nativeString -> utfEncode() -> base64Encode()

DECODE: base64Decode() -> utfDecode() -> nativeString

quasi tutte le lingue che conosco, in questi giorni, sostiene questa . Puoi cercare una codifica universale a funzione singola, ma sbaglio sul lato della cautela e scegli l'approccio in due fasi ... specialmente con i set di caratteri estranei.