Django-tastypie: prepend_urls omite la autenticación

Creado en 25 ago. 2012  ·  8Comentarios  ·  Fuente: django-tastypie/django-tastypie

Disculpas si lo que estoy haciendo aquí es por diseño o si estoy haciendo las cosas completamente mal, pero creo que usar prepend_urls para crear un recurso anidado omite la autenticación tanto en el recurso principal como en el secundario. Creé un ejemplo similar al del Libro de recetas y creé un recurso secundario usando la autenticación ApiKey y puedo acceder a eso a pesar de no pasar los encabezados correctos. El recurso principal también requiere autenticación ApiKey.

Lo que veo sin los encabezados de autenticación es:

GET / api / v1 / article - 401 como se esperaba
GET / api / v1 / article / 1 / - 401 como se esperaba
GET / api / v1 / article / 1 / tags: la lista de etiquetas se devuelve inesperadamente.

Me parece que esto es incorrecto y ciertamente no es lo que esperaría ver.

bug documentation unconfirmed

Comentario más útil

No he probado esto todavía, pero si funciona como dices, definitivamente será un enfoque para mí. Sin embargo, sigo pensando que lo que he informado aquí es un problema con Tastypie; básicamente, si usa una técnica ilustrada en el libro de cocina, la autenticación puede omitirse por completo sin que el desarrollador se dé cuenta.

Todos 8 comentarios

En mi experiencia, es mucho más fácil y elegante usar solo la función override_urls y crear su propio método secundario de envío. Es menos código, se adhiere a todas las metapropiedades de los recursos secundarios (incluida la autenticación) y más.

Ejemplo:

    def override_urls(self):
        return [
            url(r'^(?P<resource_name>%s)/(?P<pk>\w[\w/-]*)/tags%s$' % (self._meta.resource_name, trailing_slash()), self.wrap_view('dispatch_tags'), name='api_article_tags'),
        ]

    def dispatch_tags(self, request, **kwargs):
        return ArticleTagResource().dispatch('list', request, **kwargs)

Básicamente, esto le permite a su ArticleTagResource manejar toda la solicitud de / article / 1 / tags / como si fuera solicitada como una vista de lista (cambie "lista" a "detalle" para que se comporte como vista de detalles).

No he probado esto todavía, pero si funciona como dices, definitivamente será un enfoque para mí. Sin embargo, sigo pensando que lo que he informado aquí es un problema con Tastypie; básicamente, si usa una técnica ilustrada en el libro de cocina, la autenticación puede omitirse por completo sin que el desarrollador se dé cuenta.

Tengo el mismo problema y probé el método de joeribekker con los mismos resultados, ¿alguna idea de cuándo se solucionará esto? o alguna solución alternativa?

Me gusta la idea de usar Resource.dispatch() , pero si quieres hacer algo más complicado que una vista de detalle o lista, entonces no es realmente viable.

Una solución en la que he estado pensando es mover parte del levantamiento más pesado de Resource.dispatch() a Resource.wrap_view() para que wrap_view() pueda usar para envolver arbitrariamente cualquier vista, mientras se aplica todo las reglas de autenticación, autorización y limitación (posiblemente la verificación del método también, aunque más sobre eso a continuación).

Me he encontrado con este problema con la aceleración. Mi solución actual es tener un decorador en el que envuelvo mis vistas personalizadas en: @apply_throttle . El decorador copia el código más o menos de Resource.throttle_check() y Resource.log_throttled_access() .

Puede ser más efectivo para deliciouspie tener un wrap_view() más completo (incluido el anterior) _y_ decoradores (o alguna otra forma de aplicar selectivamente estas cosas), en caso de que la intención del desarrollador de usar las anulaciones sea en realidad, evite el comportamiento normal (por ejemplo, si tiene un punto final anulado que necesita una limitación diferente o relaja los requisitos de autenticación). Los decoradores también serían una buena manera de aplicar comprobaciones de métodos específicos (GET, POST, etc.) a las anulaciones, sin tener que tener ese texto repetitivo al comienzo de su método. Sé que he usado anulaciones donde todas estas hubieran sido útiles.

¿Qué piensan todos sobre ese tipo de solución? Definitivamente estoy interesado en trabajar en esto, pero tengo poco tiempo en este momento.

Este es un hilo antiguo, pero dado que los problemas aún están abiertos y tienen una clasificación alta en mi búsqueda ... una llamada a
self.is_authenticated(request) en la primera línea del controlador se encargará del problema. probado con deliciouspie 0.11 y 0.12.

El libro de cocina ahora recomienda usar self.wrap_view () dentro de prepend_urls (), cerrando este problema.

Evento con wrap_view, necesitaba self.is_authenticated(request) en el método del controlador.

¿Fue útil esta página
0 / 5 - 0 calificaciones