Django-tastypie: prepend_urls contourne l'authentification

Créé le 25 août 2012  ·  8Commentaires  ·  Source: django-tastypie/django-tastypie

Toutes mes excuses si ce que je fais ici est intentionnel ou si je fais tout simplement les choses complètement mal, mais je pense que l'utilisation de prepend_urls pour créer une ressource imbriquée contourne l'authentification sur la ressource parent et enfant. J'ai créé un exemple similaire à celui du livre de recettes et j'ai créé une ressource enfant à l'aide de l'authentification ApiKey et je suis en mesure d'y accéder malgré le fait de ne pas passer les en-têtes corrects. La ressource parente nécessite également une authentification ApiKey.

Ce que je vois sans les en-têtes d'authentification est:

GET / api / v1 / article - 401 comme prévu
GET / api / v1 / article / 1 / - 401 comme prévu
GET / api / v1 / article / 1 / tags - La liste des balises est renvoyée de manière inattendue.

Il me semble que c'est incorrect et ce n'est certainement pas ce à quoi je m'attendrais.

bug documentation unconfirmed

Commentaire le plus utile

Je n'ai pas encore essayé cela, mais si cela fonctionne comme vous le dites, ce sera certainement une approche à adopter. Cependant, je pense toujours que ce que j'ai signalé ici est un problème avec Tastypie - fondamentalement, si vous utilisez une technique illustrée dans le livre de cuisine, l'authentification peut être complètement contournée sans que le développeur ne s'en rende compte.

Tous les 8 commentaires

D'après mon expérience, il est beaucoup plus facile et plus élégant d'utiliser uniquement la fonction override_urls et de créer votre propre méthode enfant de répartition. C'est moins de code, adhère à toutes les méta-propriétés de vos ressources enfants (y compris l'authentification) et plus encore.

Exemple:

    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)

Cela permet essentiellement à votre ArticleTagResource de gérer toute la demande de / article / 1 / tags / comme si elle était demandée en tant que vue de liste (changez «liste» en «détail» pour qu'elle se comporte comme une vue détaillée).

Je n'ai pas encore essayé cela, mais si cela fonctionne comme vous le dites, ce sera certainement une approche à adopter. Cependant, je pense toujours que ce que j'ai signalé ici est un problème avec Tastypie - fondamentalement, si vous utilisez une technique illustrée dans le livre de cuisine, l'authentification peut être complètement contournée sans que le développeur ne s'en rende compte.

J'ai eu le même problème et j'ai essayé la méthode de joeribekker avec les mêmes résultats, une idée de la date à laquelle cela sera corrigé? ou des solutions de contournement?

J'aime l'idée d'utiliser Resource.dispatch() , mais si vous voulez faire quelque chose de plus compliqué qu'une vue de détail ou de liste, alors ce n'est pas vraiment viable.

Une solution à laquelle j'ai réfléchi consiste à déplacer une partie des levées les plus lourdes de Resource.dispatch() à Resource.wrap_view() afin que wrap_view() puisse être utilisé pour envelopper arbitrairement n'importe quelle vue, tout en appliquant l'ensemble de les règles d'authentification, d'autorisation et de limitation (peut-être aussi la vérification de la méthode, mais plus d'informations ci-dessous)

J'ai rencontré ce problème avec la limitation. Ma solution de contournement actuelle est d'avoir un décorateur dans lequel j'emballe mes vues personnalisées: @apply_throttle . Le décorateur copie plus ou moins le code de Resource.throttle_check() et Resource.log_throttled_access() .

Il peut être plus efficace pour tastypie d'avoir à la fois des décorateurs wrap_view() plus complets (y compris ce qui précède) _et_ décorateurs (ou une autre façon d'appliquer sélectivement ces choses), juste au cas où l'intention du développeur d'utiliser les remplacements est de contourner réellement le comportement normal (par exemple, si vous avez un point de terminaison surchargé qui nécessite une régulation différente ou assouplit les exigences d'authentification). Les décorateurs seraient également un bon moyen d'appliquer des vérifications de méthode spécifiques (GET, POST, etc.) aux remplacements, sans avoir à avoir ce passe-partout au début de votre méthode. Je sais que j'ai utilisé des remplacements là où tout cela aurait été utile.

Que pensent chacun de ce genre de solution? Je suis vraiment intéressé à travailler là-dessus, mais je suis assez à court de temps pour le moment.

C'est un vieux fil de discussion, mais comme les problèmes sont toujours ouverts et classés en haut de ma recherche ... un appel à
self.is_authenticated(request) dans la première ligne du gestionnaire s'occupera du problème. testé avec tastypie 0.11 & 0.12.

Le livre de recettes recommande maintenant d'utiliser self.wrap_view () dans prepend_urls (), fermant ce problème.

Événement avec wrap_view, j'avais besoin de self.is_authenticated(request) dans la méthode du gestionnaire.

Cette page vous a été utile?
0 / 5 - 0 notes