Passaggio di strutture dati Perl come stringhe GET serializzate a un programma CGI Perl

Question

Voglio passare una struttura di dati Perl serializzata come variabile GET a un'applicazione CGI. Ho provato Data :: Serializer come prima opzione. Sfortunatamente la stringa serializzata è troppo lunga per il mio comfort, oltre a contenere le opzioni unite da '^' (un cursore).

Esiste un modo per creare stringhe con codifica breve da strutture di dati perl in modo da poterle passare in modo sicuro come variabili GET a un'applicazione CGI perl?

Gradirei anche che mi è stato detto che questo (stringhe serializzate e codificate) è un cattivo modo di trasmettere strutture dati complesse ad applicazioni web e suggerimenti su come potrei ottenere questo

Answer 1

Se devi inviare URL ai tuoi utenti che contengono alcuni punti dati chiave e vuoi assicurarti che non possano essere falsificati, puoi farlo con un Digest (come Digest :: SHA) e un segreto condiviso. Ciò ti consente di inserire i dati nei tuoi messaggi senza dover tenere un database locale per tracciarli tutti. Il mio esempio non include un elemento time, ma sarebbe abbastanza facile aggiungerlo se lo desideri.

use Digest::SHA qw(sha1_base64);
my $base_url = 'http://example.com/thing.cgi';

my $email = 'guy@somewhere.com';
my $msg_id = '123411';

my $secret = 'mysecret';
my $data = join(":", $email, $msg_id, $secret);
my $digest = sha1_base64($data);

my $url = $base_url . '?email=' . $email . '&msg_id=' . $msg_id' . '&sign=' . $digest;

Quindi invialo insieme.

Nel tuo " thing.cgi " script devi solo estrarre i parametri e vedere se il digest inviato nello script corrisponde a quello che rigeneri localmente (usando $ email e $ msg_id, e ovviamente il tuo $ segreto). Se non corrispondono, non autorizzarli, in caso affermativo hai una richiesta legittimamente autorizzata.

Nota:
Ho scritto il "grezzo" metodi in Data :: Serializer per rendere la traduzione tra serializzatori molto più semplice e che in effetti aiuta ad andare tra le lingue (fino a un certo punto). Ma questa è ovviamente una discussione separata in quanto non dovresti mai usare un serializzatore per scambiare dati su un modulo web.

Answer 2

Uno degli svantaggi dell'approccio - usando un serializzatore specifico perl, cioè - è che se mai vuoi comunicare tra il client e il server usando qualcosa di diverso da perl, sarà probabilmente più lavoro di qualcosa come JSON o anche XML sarebbe. I limiti di dimensione delle richieste GET che hai già eseguito, ma questo è problematico per qualsiasi schema di codifica.

È più probabile che sia un problema per il prossimo ragazzo che mantiene questo codice piuttosto che per te. Ora ho una situazione in cui uno sviluppatore che prima lavorava su un grande sistema aveva deciso di archiviare alcuni importanti bit di dati come oggetti Storable perl. Non è una decisione orribile in sé e per sé, ma sta rendendo più difficile di quanto dovrebbe essere accedere ai dati con strumenti che non sono scritti in perl.

Answer 3

Il passaggio di stringhe con codifica serializzata è un metodo errato per trasferire strutture di dati complesse alle applicazioni Web.

Se stai tentando di passare lo stato da una pagina all'altra, puoi utilizzare le sessioni lato server che richiede solo il passaggio di una chiave di sessione.

Se devi inviare un link via e-mail a qualcuno, puoi comunque creare una sessione sul lato server con un tempo di scadenza ragionevole (dovrai anche decidere se è necessaria un'ulteriore autenticazione) e quindi inviare l'id di sessione nel link . Puoi / dovresti scadere la sessione immediatamente dopo aver intrapreso l'azione richiesta.