Django-rest-framework: A página de administração do token vaza tokens de acesso em arquivos de log

OK. Sim. Não é ideal.

A resposta para perguntas relacionadas a tokens tem sido tradicionalmente que a implementação fornecida é deliberadamente (super) simples e que você deve usar uma implementação personalizada se precisar de algo mais complexo/melhor. (O ponto principal aqui é que evitamos adicionar mais complexidade aqui para manter a carga de manutenção razoável.)

As permissões de acesso para usuários com acesso à página de administração (alto) e aqueles com permissão para visualizar logs (médio) são diferentes.

Acho que isso não é verdade para pessoas que usariam/deveriam usar a implementação fornecida em produção.
(Nesses casos, eles seriam a mesma pessoa.)

Não tenho certeza do que os outros podem dizer...

A resposta para perguntas relacionadas a tokens tem sido tradicionalmente que a implementação fornecida é deliberadamente (super) simples e que você deve usar uma implementação personalizada se precisar de algo mais complexo/melhor.

Eu recebo essa posição, mas os documentos devem recomendar fortemente os usuários longe da implementação embutida no mínimo e preterir no extremo das coisas. A recomendação de terceiros para autenticação de token/assinatura é https://github.com/etoccalino/django-rest-framework-httpsignature , que não é atualizada há 3 anos. Eu imagino que haveria muito mais interesse em provedores de token de terceiros se um não fosse fornecido imediatamente.

Esta é uma IMO de divulgação de informações bastante séria, então não tenho certeza se a posição padrão para authtoken é o caminho certo a seguir neste caso.

Não. Por isso não fechei...

Desculpe se minha resposta saiu mais grosseira do que o pretendido, esse não era meu objetivo.

Sem problemas! 😃

(Gostaria de saber se poderíamos apenas mung o ModelAdmin para usar um hash da chave na url ...)

Sorrateira, mas essa ideia também parece perigosa, embora eu não possa dizer por quê.

Uma migração deve ser capaz de lidar com o trabalho. A parte complicada seria chaves estrangeiras em outras tabelas, mas isso parece improvável. O DRF não cria FKs para Tokens, e não vejo muitas razões para que os usuários também o fizessem.

Acho que não tentei migrar campos de chave primária antes, mas me lembro de haver uma operação que lida com isso e as atualizações de chave estrangeira correspondentes também.

Sim. Precisaria de uma migração de dados, mas, caso contrário, acho que é fácil alternar.

Solicitações de pull são bem-vindas. Obrigado pelo relatório!

O token precisa necessariamente ser único?

Eu entendo o problema, mas você deve considerar que dependendo de qual migração você criar (para resolver este problema), você pode causar muitos outros problemas (por exemplo, a introdução de um novo campo PK provavelmente quebrará alguns outros pacotes que dependem do comportamento atual ).

Gostaria de saber se é possível adicionar um campo inteiro de incremento automático na tabela de tokens que é usado como referência na página de administração do Django para o token de autenticação, mas não como a chave primária da tabela?

Para sua informação, acabei de verificar que também tenho o mesmo problema com minha implementação de token estendido (consulte django-rest-multitokenauth ) - então, obrigado por apontar esse erro no painel de administração! Estou ansioso para ver a solução aqui, para que eu possa adaptar meu pacote python.

FYI, foi assim que consertei no meu pacote MultiTokenAuth:
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

Eu acho que a mesma correção poderia ser aplicada aqui, com a ressalva de potencialmente quebrar o código de outras pessoas se elas tiverem uma chave estrangeira para a tabela de tokens

Olá,

Eu estava apenas analisando os problemas relacionados à autenticação antes de avaliar esta biblioteca para um próximo projeto. Tenho uma dúvida simples, agradeço qualquer ajuda.

Esse problema pode ser evitado simplesmente não registrando o modelo Token no admin?

@raunaqss Sim, você não precisa registrá-lo.

Tho obrigado por re-aumentar isso.

Sabemos para que lado estamos indo com isso?
Devemos hash a url ou migrar o pk?

Eu posso fazer um PR.

Uma migração muito provavelmente será a abordagem sensata aqui.
Estou bastante cauteloso sobre a inclusão de uma migração na versão 3.11, pois, por exemplo. pode ser problemático/inesperado para pessoas com tabelas de chaves de API muito grandes.
Acho que uma coisa sensata a fazer provavelmente será começar liberando uma migração para isso separadamente, para que possamos garantir que algumas pessoas possam testar tudo primeiro, independentemente de nossos lançamentos.
Quando estivermos satisfeitos com tudo, podemos considerar incluir a migração diretamente.

Vamos dar uma olhada em liberar uma migração para isso separadamente, em vez de enviá-la na versão 3.11 em si. Estou muito cauteloso com as implicações para usuários com tabelas de chaves de API muito grandes para enviar uma migração para todos os nossos usuários em uma versão principal.

Esse problema está em aberto há muito tempo e, embora pareça que a observação de @jarshwah seja abordada por django-rest-knox , provavelmente queremos ser mais seguros por padrão. Mesmo que a intenção do drf seja que TokenAuthentication seja simples, muitos desenvolvedores são obrigados a implementar um mecanismo de autenticação inseguro. Não tenho certeza se o código que vaza material secreto por design deve ser incluído fora da caixa.

Houve algum progresso na resolução deste problema? Alguém está aberto a aceitar uma recompensa sobre o problema? Eu estaria interessado em contribuir com código ou pagar uma recompensa se assim for.

Vou prfioritizá-lo para 3.12.

Eu estaria interessado em contribuir com código

Muito bem-vindo para emitir um PR para ele, com certeza.

Eu estaria interessado em contribuir com código ou pagar uma recompensa se assim for.

Tornar-se um patrocinador é uma boa maneira de contribuir. Os patrocinadores têm suporte prioritário e podem esclarecer um problema, se necessário. https://fund.django-rest-framework.org/topics/funding/#corporate -plans

Isso tudo soa muito bem! Agora sou um patrocinador do drf e encode. Certificar-me-ei de atualizar este problema se/quando começar a trabalhar em uma resolução.

Fantástico, muito obrigado. 🙏

Ok, então não é realmente óbvio como lidar com isso graciosamente.

Gostaríamos muito que o modelo usasse apenas um int de incremento automático para a chave primária e que o campo "chave" fosse um campo indexado e exclusivo padrão, mas não podemos migrar para isso. Então, quais são nossas opções...

• Poderíamos introduzir algo como rest_framework.authtoken2 e fazer com que os documentos se referissem a isso, para que novos projetos tenham um conjunto melhor de padrões.
• Poderíamos continuar a usar o campo existente como o PK e adicionar um novo campo para o valor real do token. Não está claro se poderíamos introduzir uma migração de dados copiando os valores, como poderia? ser problemático para usuários com grandes conjuntos de dados existentes. Isso parece decente... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django Também precisaríamos ter muito cuidado com o comportamento correto para bases de código não migradas. Se estivéssemos trabalhando em um aplicativo implantado, normalmente gostaríamos de começar introduzindo o novo campo e garantindo que estamos escrevendo os mesmos valores em ambos os campos enquanto ainda temos a base de código referindo-se ao campo antigo por um período de tempo. E somente quando tudo estiver implantado e sincronizado, introduza a mudança de código para usar o novo campo.
• Poderíamos continuar como estamos, mas introduzir algumas alterações de administração.

Alguém tem alguma opinião preliminar sobre isso?

Além disso: é por isso que este está pendente há tanto tempo - não há uma resposta fácil para isso. 😬

Abri o nº 7341 para ver a opção _"introduzir algumas alterações de administrador"_.