Sto codificando un'applicazione web REST che gira su Google App Engine, autentica le richieste API ai dati privilegiati utilizzando sessioni dai cookie forniti da webapp2_extras.auth e webapp2_extras.security.
L'intero sito e tutti i punti utilizzano HTTPS.
Webapp2 gira in un "contesto di richiesta" che credo significhi che ogni richiesta che viene attraverso ha una sua discussione, ma mi chiedo qualcosa che sia probabilmente abbastanza specifico del codice e anche se ho scavato nel codice per capire, sono Non sono sicuro che sarei capace di mettere tutte le mie paure a riposo, quindi mi sto chiedendo qui.
La situazione è: I rig la richiesta http PATCH alle richieste "batch" ai metodi PUT, GET e DELETE per salvare su roundtrips client-server. Se si dice che il client ha molti oggetti da salvare sul server, può creare un PATCH con l'elenco jsonified delle richieste "sub" a
/user/dame_edna/objects
E la patch eseguirà l'iterazione dell'elenco e quindi farà le richieste in-app ai diversi punti , ad esempio una richiesta potrebbe essere:
method:delete
point:/decorative_fans/small_dog_design
E il metodo patch costruirà un oggetto webapp2.Request che punta a
/user/dame_edna/objects/decorative_fans/small_dog_design
Riempirà vari campi (ma, soprattutto, per questa domanda, non i campi cookie o auth), e quindi istanzia il gestore richieste, in questo caso,
user.objects.decorative_fans.crud.responder
ed esegui quella richiesta nell'applicazione, senza un ritorno del client-server
Ecco dove mi perdo e cosa trovo interessante:
Il campo cookie della nuova richiesta è vuoto, ma la richiesta conosce in qualche modo il token di autenticazione e la sessione della richiesta di origine. Si noti che la richiesta PATCH originale è arrivata a /user/dame_edna e, per fare in modo che quella richiesta PATCH qui, fosse necessaria una sessione autenticata per l'utente "dame_edna", ma la mia preoccupazione è: come fanno i sottorequisiti che faccio nel l'applicazione sa che sono stati verificati come "dame_edna"?
Ma lo fanno. Ho scaricato il token di autenticazione per la richiesta DELETE e si è verificato come lo stesso token di autenticazione che ha autenticato, ad esempio, dame_edna sulla richiesta PATCH originale, anche se non l'ho copiato o impostato in alcun modo
Mi sembra strano che webapp2 copi copia su questi fondamentali di autenticazione, o che diventino semplicemente accessibili all'oggetto Richiesta appena creato, dal momento che la creazione di richieste in-app come ho fatto io è, secondo i documenti, usato principalmente per i test unitari.
Voglio chiarire ogni dubbio su questo prima di andare avanti con l'applicazione, dal momento che è un'area piuttosto importante che non voglio rovinare, e non posso ignorarlo senza sapere esattamente cosa sta succedendo.
La guida è apprezzata per una spiegazione di come la sub, richiesta in-app conosce l'originale, lo stato autentico delle richieste HTTP e se l'utilizzo di sub-richieste in questo modo sarà "a prova di proiettile" come le sessioni autografate originali fornito da webapp2_extras