Django-rest-framework: La página de administración de tokens filtra tokens de acceso a los archivos de registro

está bien. Sí. No es ideal.

La respuesta a las preguntas relacionadas con tokens ha sido tradicionalmente que la implementación proporcionada es deliberadamente (demasiado) simple y que debe usar una implementación personalizada si necesita algo más complejo/mejor. (La conclusión aquí es que nos hemos alejado de agregar más complejidad aquí para mantener la carga de mantenimiento razonable).

Los permisos de acceso para usuarios con acceso a la página de administración (alto) y aquellos con permisos para ver registros (medio) son diferentes.

Creo que esto no es cierto para las personas que deberían usar la implementación proporcionada en producción.
(En esos casos, serían la misma persona).

No estoy seguro de lo que otros podrían decir...

La respuesta a las preguntas relacionadas con tokens ha sido tradicionalmente que la implementación proporcionada es deliberadamente (demasiado) simple y que debe usar una implementación personalizada si necesita algo más complejo/mejor.

Obtengo esta posición, pero luego los documentos deberían recomendar encarecidamente a los usuarios que se alejen de la implementación integrada como mínimo, y desaprobar en el extremo de las cosas. La recomendación de terceros para la autenticación de token/firma es https://github.com/etoccalino/django-rest-framework-httpssignature , que no se ha actualizado en 3 años. Me imagino que habría mucho más interés en los proveedores de tokens de terceros si no se proporcionara uno listo para usar.

En mi opinión, esta es una divulgación de información bastante seria, por lo que no estoy seguro de que la posición predeterminada para authtoken sea la forma correcta de hacerlo en este caso.

No. Por eso no lo cerré...

Lo siento si mi respuesta salió más dura de lo previsto, ese no era mi objetivo.

¡No hay problemas! 😃

(Me pregunto si podríamos simplemente mung ModelAdmin para usar un hash de la clave en la URL...)

Astuto, pero esa idea también se siente peligrosa, aunque no puedo decir por qué.

Una migración debe ser capaz de manejar el trabajo. La parte complicada serían las claves foráneas en otras tablas, pero eso parece poco probable. DRF no crea FK para tokens, y tampoco veo muchas razones por las que los usuarios lo harían.

No creo que haya intentado migrar campos de clave principal antes, pero creo recordar que hubo una operación que lo maneja, y las actualizaciones de clave externa correspondientes también.

Sip. Necesitaría una migración de datos, pero por lo demás, supongo que es bastante fácil cambiar.

Se aceptan solicitudes de extracción. ¡Gracias por el informe!

¿El token debe ser necesariamente único?

Entiendo el problema, pero debe considerar que, según la migración que cree (para resolver este problema), puede causar muchos otros problemas (por ejemplo, la introducción de un nuevo campo PK probablemente romperá algunos otros paquetes que dependen del comportamiento actual ).

Me pregunto si es posible agregar un campo entero de incremento automático en la tabla de tokens que se usa como referencia dentro de la página de administración de Django para el token de autenticación, pero no como la clave principal de la tabla.

Para su información, acabo de verificar que también tengo el mismo problema con mi implementación de token extendida (consulte django-rest-multitokenauth ), ¡así que gracias por señalar ese error en el Panel de administración! Espero ver la solución aquí, para poder adaptar mi paquete de python.

FYI, así es como lo arreglé dentro de mi paquete MultiTokenAuth:
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

Supongo que se podría aplicar la misma solución aquí, con la advertencia de romper potencialmente el código de otras personas si tienen una clave externa para la tabla de tokens.

Hola,

Solo estaba hojeando los problemas relacionados con la autenticación antes de evaluar esta biblioteca para un próximo proyecto. Tengo una pregunta simple, agradecería cualquier ayuda.

¿Se puede evitar este problema simplemente no registrando el modelo Token en admin?

@raunaqss Sí, no es necesario que lo registre.

Gracias por volver a subir esto.

¿Sabemos hacia dónde vamos con esto?
¿Deberíamos codificar la URL o migrar el pk?

Puedo hacer un PR.

Es muy probable que una migración sea el enfoque sensato aquí.
Soy bastante cauteloso acerca de incluir una migración en la versión 3.11, ya que, por ejemplo. podría ser problemático/inesperado para personas con tablas de claves API muy grandes.
Creo que lo más sensato sería comenzar lanzando una migración a esto por separado, de modo que podamos asegurarnos de que algunas personas puedan probarlo todo primero independientemente de nuestros lanzamientos.
Una vez que estemos satisfechos con todo, podemos considerar incluir la migración directamente.

Echemos un vistazo a la publicación de una migración para esto por separado, en lugar de incluirla en la versión 3.11. Soy demasiado cauteloso con las implicaciones para los usuarios con tablas de claves API muy grandes para impulsar una migración en todos nuestros usuarios en una versión importante.

Este problema ha estado abierto durante mucho tiempo y, aunque parece que django-rest-knox aborda la observación de @jarshwah, probablemente queramos ser más seguros de forma predeterminada. Incluso si la intención de drf es que TokenAuthentication sea ​​simple, muchos desarrolladores están obligados a implementar un mecanismo de autenticación inseguro. No estoy seguro de que el código que filtra material secreto por diseño deba incluirse fuera de la caja.

¿Se ha avanzado en la resolución de este problema? ¿Alguien está dispuesto a aceptar una recompensa por el tema? Me interesaría contribuir con el código o pagar una recompensa si es así.

Lo priorizaré para 3.12.

Yo estaría interesado en contribuir con el código

Muy bienvenido a emitir un PR para ello, seguro.

Me interesaría contribuir con el código o pagar una recompensa si es así.

Convertirse en patrocinador es una buena manera de contribuir. Los patrocinadores tienen soporte prioritario y pueden escalar un problema si es necesario. https://fund.django-rest-framework.org/topics/funding/#corporate-planes

¡Todo eso suena genial! Ahora soy patrocinador de drf y codificar. Me aseguraré de actualizar este problema cuando empiece a trabajar en una resolución.

Fantástico, muchas gracias. 🙏

De acuerdo, entonces no es realmente obvio cómo abordar esto con gracia.

Realmente nos gustaría que el modelo solo use un int de incremento automático para la clave principal, y que el campo "clave" sea un campo indexado único estándar, pero no podemos migrar a eso. Entonces, cuales son nuestras opciones...

• Podríamos introducir algo como rest_framework.authtoken2 y hacer que los documentos se refieran a eso en su lugar, para que los nuevos proyectos obtengan un mejor conjunto de valores predeterminados.
• Podríamos continuar usando el campo existente como PK y agregar un nuevo campo para el valor real del token. No está claro si podríamos introducir una migración de datos copiando los valores, como podría ser. ser problemático para los usuarios con grandes conjuntos de datos existentes. Esto parece decente... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django También deberíamos tener mucho cuidado con el comportamiento correcto de las bases de código no migradas. Si estuviéramos trabajando en una aplicación implementada, normalmente querríamos comenzar introduciendo el nuevo campo y asegurándonos de escribir los mismos valores en ambos campos sin dejar de tener el código base haciendo referencia al campo anterior durante un período de tiempo. Y solo una vez que todo esté implementado y sincronizado, introduzca el cambio de código para usar el nuevo campo.
• Podríamos continuar como estamos pero introducir algunos cambios administrativos.

¿Alguien tiene alguna idea preliminar sobre esto?

Además: es por eso que este ha estado pendiente durante tanto tiempo: no hay una respuesta fácil. 😬

Abrí #7341 como un vistazo a la opción _"introducir algunos cambios de administrador"_.