Django-tastypie: prepend_urls ignora a autenticação

Na minha experiência, é muito mais fácil e elegante usar apenas a função override_urls e criar seu próprio método filho de despacho. É menos código, adere a todas as propriedades meta de recurso filho (incluindo autenticação) e muito mais.

Exemplo:

    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)

Isso basicamente permite que seu ArticleTagResource trate toda a solicitação de / article / 1 / tags / como se fosse solicitada como uma exibição de lista (altere "lista" para "detalhes" para que se comporte como exibição de detalhes).

Ainda não tentei fazer isso, mas se funcionar como você diz, com certeza será uma abordagem a ser adotada. No entanto, ainda acho que o que relatei aqui é um problema com o Tastypie - basicamente, se você usar uma técnica ilustrada no livro de receitas, a autenticação pode ser completamente ignorada sem que o desenvolvedor perceba.

Eu tenho o mesmo problema e tentei os mesmos resultados do método de joeribekker, alguma ideia de quando isso será corrigido? ou alguma solução alternativa?

Gosto da ideia de usar Resource.dispatch() , mas se você quiser fazer algo mais complicado do que um detalhe ou exibição de lista, então não é realmente viável.

Uma solução em que estive pensando é mover alguns dos levantamentos mais pesados ​​de Resource.dispatch() para Resource.wrap_view() modo que wrap_view() pudesse ser usado para envolver arbitrariamente qualquer visualização, ao aplicar as regras de autenticação, autorização e limitação (possivelmente a verificação do método também, embora mais sobre isso a seguir).

Eu tive esse problema com a limitação. Minha solução atual é ter um decorador no qual envolvo minhas visualizações personalizadas: @apply_throttle . O decorador copia o código mais ou menos de Resource.throttle_check() e Resource.log_throttled_access() .

Pode ser mais eficaz para o tastypie ter tanto wrap_view() (incluindo o acima) _and_ decoradores (ou alguma outra maneira de aplicar seletivamente essas coisas), apenas no caso de a intenção do desenvolvedor usar as substituições na verdade, contorna o comportamento normal (por exemplo, se você tem um endpoint sobrescrito que precisa de regulagens diferentes ou relaxa os requisitos de autenticação). Decoradores também seriam uma boa maneira de aplicar verificações de método específicas (GET, POST, etc) às substituições, sem ter que ter aquele clichê no início do seu método. Eu sei que usei substituições onde tudo isso teria sido útil.

Quais são os pensamentos de todos em relação a esse tipo de solução? Estou definitivamente interessado em trabalhar nisso, mas estou sem tempo agora.

Eu tenho lutado com isso, mas eu encontrei e respondo SO.
http://stackoverflow.com/questions/11827368/tastypie-override-urls-ignores-authentication-and-authorization

Este é um tópico antigo, mas como os problemas ainda estão em aberto e tiveram uma classificação elevada em minha pesquisa ... uma chamada
self.is_authenticated(request) na primeira linha do manipulador cuidará do problema. testado com tastypie 0,11 e 0,12.

O livro de receitas agora recomenda usar self.wrap_view () dentro de prepend_urls (), encerrando este problema.

Evento com wrap_view, eu precisava de self.is_authenticated(request) no método do manipulador.