¿Autenticación cliente/servidor interna API de Django o no?

Tengo un proyecto django, en el cual expongo algunos puntos finales api (punto final api = respuestas para obtener/publicar, devuelve respuesta json, corrígeme si estoy equivocado en mi definición). Esos puntos finales los utilizo en el front end, como los recuentos de actualizaciones o el contenido actualizado, o una miríada de otras cosas. Manejo la lógica de representación en el lado del servidor, en plantillas y, en algunos casos, envío una plantilla renderizada a cadena al cliente.

Estas son las preguntas que estoy tratando de responder:

  1. ¿Necesito algún tipo de autenticación entre los clientes y el servidor?
  2. ¿Es suficiente la protección de origen cruzada de django?
  3. ¿Dónde, en esta imagen, se ajustan paquetes como django-oauth-toolkit ? Y django-rest-framework ?
  4. si no agrego ninguna autenticación entre los clientes y el servidor, ¿dejo mi servidor abierto para ataques?

Además, ¿qué pasa para la conexión de servidor a servidor? Ambos servidores bajo mi control.

0
Si está preguntando: si implemento la autenticación de oauth/openid/something para proteger mi servidor de las solicitudes GET, entonces diría que no. Sí, el servidor estará abierto, pero si ninguna de las vistas permite realizar cambios en ningún objeto, y usted ha seguido las pautas de implementación de django ( djangobook.com/en/2.0/chapter12.html ), entonces todo debería estar bien.
agregado el autor Odif Yltsaeb, fuente
Bueno, trato de proteger todos y cada uno de mis puntos de vista todo lo que necesiten. Lo que significa que tengo que iniciar sesión requiere la mayoría de las vistas protegidas y las vistas de API generalmente requieren una clave de API. Siempre que tengas la clave API, puedes hacer lo que permitan las vistas: P
agregado el autor Odif Yltsaeb, fuente
@OdifYltsaeb, sí, eso es lo que me pregunto, debería implementar oauth o tal para los clientes. ¿Qué hay de las llamadas posteriores? es csrf suficiente? ¿Y qué hay de servidor a servidor?
agregado el autor Neara, fuente

1 Respuestas

Recomiendo utilizar django-tastypie para la comunicación de servidor a cliente. Lo he usado en numerosas aplicaciones tanto de servidor a servidor como de servidor a cliente. Esto le permite aplicar la seguridad de django, así como otra lógica sobre el proceso de autorización. Ofrece también fuera de la caja:

  • estrangulamiento
  • serialización en json, xml y otros formatos
  • autenticación (básica, apikey, personalizada y de otro tipo)
  • validación
  • autorización
  • paginación
  • almacenamiento en caché

Por lo tanto, como resumen general, sugeriría que se construya sobre dicho marco que haría que su API interna sea más interoperable para futuras extensiones y más segura.

Para responder específicamente a su pregunta, nunca habilitaría ninguna API de servidor sin al menos alguna autenticación/autorización básica.

Espero responder sus preguntas sobre cómo puede entregar todas sus preocupaciones anteriores con un marco.

El django-rest-framework que pides, también es realmente avanzado y fácil de usar, pero prefiero sabroso por las razones que explico.

¡Espero haber ayudado un poco!

0
agregado
gracias, esto de hecho se dirige a mis preguntas. es hora de ir a re-modelar mi api de una manera apropiada. Todavía me pregunto cómo se pasa la clave de API a los clientes que la exponen? y la autenticación/autorización de clientes ¿ralentiza la página?
agregado el autor Neara, fuente
la autenticación/autorización no afecta la respuesta (con respecto a que está utilizando un flujo de trabajo estándar). no entiendo exactamente lo que quieres decir aquí "todavía me pregunto cómo pasas la clave de API a los clientes para exponerla". Estaría encantado de ayudar, así que ayúdame a entender más profundamente tu pregunta. ¡Muchas gracias!
agregado el autor Michael Petychakis, fuente