Estoy codificando una aplicación web REST que se ejecuta en el motor de aplicaciones de Google, autentica las solicitudes de API a los datos privilegiados mediante sesiones mediante cookies proporcionadas por webapp2_extras.auth y webapp2_extras.security.
Todo el sitio y todos los puntos utilizan HTTPS.
Webapp2 se ejecuta en un "contexto de solicitud" que creo que significa que cada solicitud que recibe tiene su propio subproceso, pero me pregunto algo que probablemente sea bastante específico del código e incluso si busco el código para entenderlo, estoy No estoy seguro de que sea capaz de poner fin a todos mis miedos, por lo que pregunto aquí.
La situación es: Preparo la solicitud http PATCH para "agrupar" las solicitudes de los métodos PUT, GET y DELETE para guardar en viajes de ida y vuelta cliente-servidor. Si el cliente tiene muchos objetos para guardar en el servidor, puede hacer un PARCHE con la lista jsonificada de "sub" solicitudes para
/user/dame_edna/objects
Y el parche repetirá esa lista y luego realizará solicitudes dentro de la aplicación a los diferentes puntos , por ejemplo, una solicitud podría ser:
method:delete
point:/decorative_fans/small_dog_design
Y el método de parche construirá un objeto webapp2.Request que apunta a
/user/dame_edna/objects/decorative_fans/small_dog_design
Rellenará varios campos (pero, de manera crucial para esta pregunta, no los campos de cookie o autenticación), y luego instanciará el controlador de solicitudes, en este caso,
user.objects.decorative_fans.crud.responder
y ejecute esa solicitud en la aplicación, sin un viaje de ida y vuelta cliente-servidor
Aquí es donde me pierdo y lo que me parece interesante:
El campo de cookie de la nueva solicitud está en blanco, pero de alguna manera la solicitud conoce el token de autenticación y la sesión de la solicitud de origen. Tenga en cuenta que la solicitud de PATCH original llegó a /user/dame_edna , e incluso para hacer esa solicitud de PATCH aquí necesitamos tener una sesión autenticada para el usuario "dame_edna", pero mi preocupación es: ¿cómo funcionan las solicitudes secundarias que realizo en el ¿La aplicación sabe que están verificadas como "dame_edna"?
Pero lo hacen. Volcé el token de autenticación para la solicitud DELETE, y surgió como el mismo token de autenticación que autentificó, por ejemplo, dame_edna a la solicitud PATCH original, aunque no lo copié ni configuré de ninguna manera
Me parece extraño que webapp2 copie a través de estos fundamentos de autenticación, o que simplemente sean accesibles para el objeto Request recién creado, desde la creación de Requests in-app como hice, según los documentos, se usa principalmente para pruebas unitarias.
Quiero aclarar cualquier duda al respecto antes de seguir adelante con la aplicación, ya que es un área bastante clave que no quiero estropearla, y no puedo ignorarla sin saber exactamente qué está pasando.
Se agradece la ayuda por una explicación de cómo la solicitud secundaria y interna de la aplicación conoce el estado original de las solicitudes HTTP y si el uso de solicitudes secundarias de esta manera será tan "a prueba de balas" como las sesiones firmadas originales proporcionado por webapp2_extras