Django-rest-framework: Страница администрирования токенов пропускает токены доступа в файлы журнала

В ПОРЯДКЕ. Ага. Не идеально.

Ответ на вопросы, связанные с токенами, традиционно заключался в том, что поставляемая реализация преднамеренно (чрезмерно) проста и что вы должны использовать пользовательскую реализацию, если вам нужно что-то более сложное/лучшее. (Суть здесь в том, что мы избегали добавления каких-либо дополнительных сложностей, чтобы сохранить разумную нагрузку на обслуживание.)

Права доступа для пользователей с доступом к странице администратора (высокий уровень) и пользователей с правами просмотра журналов (средний уровень) различаются.

Я думаю, что это неверно для людей, которые будут/должны использовать предоставленную реализацию в производстве.
(В этих случаях это был бы один и тот же человек.)

Не уверен, что другие могут сказать...

Ответ на вопросы, связанные с токенами, традиционно заключался в том, что поставляемая реализация преднамеренно (чрезмерно) проста и что вы должны использовать пользовательскую реализацию, если вам нужно что-то более сложное/лучшее.

Я понимаю эту позицию, но тогда документы должны настоятельно рекомендовать пользователям как минимум отказаться от встроенной реализации и устареть в крайнем случае. Сторонняя рекомендация для аутентификации токена/подписи — https://github.com/etoccalino/django-rest-framework-httpsignature , которая не обновлялась в течение 3 лет. Я полагаю, что к сторонним поставщикам токенов был бы гораздо больший интерес, если бы они не были предоставлены из коробки.

Это довольно серьезное раскрытие информации, IMO, поэтому я не уверен, что позиция по умолчанию для токена авторизации является правильным путем в этом случае.

Нет. Вот почему я не закрыл его...

Извините, если мой ответ вышел более грубым, чем предполагалось, это не было моей целью.

Нет проблем! 😃

(Интересно, можем ли мы просто использовать ModelAdmin, чтобы использовать хэш ключа в URL-адресе...)

Подлый, но эта идея тоже кажется опасной, хотя я не могу сказать, почему.

Миграция должна быть в состоянии справиться с заданием. Хитростью могут быть внешние ключи в других таблицах, но это маловероятно. DRF не создает FK для токенов, и я не вижу причин, по которым пользователи могли бы это сделать.

Я не думаю, что я пытался перенести поля первичного ключа раньше, но я, кажется, помню, что была операция, которая обрабатывает это, а также соответствующие обновления внешнего ключа.

Ага. Потребуется миграция данных, но в остальном, я думаю, достаточно легко переключиться.

Запросы на вытягивание приветствуются. Спасибо за отчет!

Должен ли токен обязательно быть уникальным?

Я понимаю проблему, но вы должны учитывать, что в зависимости от того, какую миграцию вы создаете (для решения этой проблемы), вы можете вызвать много других проблем (например, введение нового поля PK, скорее всего, нарушит некоторые другие пакеты, которые зависят от текущего поведения). ).

Интересно, можно ли добавить целочисленное поле с автоинкрементом в таблицу токенов, которое используется в качестве ссылки на странице администратора Django для токена аутентификации, но не в качестве первичного ключа таблицы?

К вашему сведению, я только что убедился, что у меня такая же проблема с моей расширенной реализацией токена (см. django-rest-multitokenauth ) — так что спасибо, что указали на эту ошибку в панели администратора! Я с нетерпением жду решения здесь, поэтому я могу адаптировать свой пакет Python.

К вашему сведению, вот как я исправил это в своем пакете MultiTokenAuth:
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

Я предполагаю, что здесь можно применить то же исправление, с оговоркой о возможном нарушении кода других людей, если у них есть внешний ключ к таблице токенов.

Привет,

Я просто просматривал проблемы, связанные с аутентификацией, прежде чем оценить эту библиотеку для предстоящего проекта. У меня простой вопрос, буду признателен за любую помощь.

Можно ли избежать этой проблемы, просто не регистрируя модель токена в админке?

@raunaqss Да, вам не нужно его регистрировать.

Спасибо за повторное поднятие этого.

Знаем ли мы, каким путем мы идем с этим?
Должны ли мы хэшировать URL-адрес или перенести pk?

Я могу сделать пиар.

Миграция, скорее всего, будет разумным подходом.
Я очень настороженно отношусь к включению миграции в выпуск 3.11, поскольку, например. это может быть проблематично/неожиданно для людей с очень большими таблицами ключей API.
Я думаю, что разумно будет начать с выпуска миграции на это отдельно, чтобы мы могли убедиться, что некоторые люди смогут сначала протестировать все это независимо от наших выпусков.
Как только мы будем довольны всем этим, мы можем рассмотреть возможность непосредственного включения миграции.

Давайте взглянем на выпуск миграции для этого отдельно, вместо того, чтобы добавлять ее в сам выпуск 3.11. Я слишком опасаюсь последствий для пользователей с очень большими таблицами ключей API, чтобы продвигать миграцию для всех наших пользователей в основном выпуске.

Эта проблема была открыта в течение долгого времени, и, хотя кажется , что наблюдение @jarshwah решается django-rest-knox , мы, вероятно, хотим быть более безопасными по умолчанию. Даже если намерение drf состоит в том, чтобы TokenAuthentication было простым, многие разработчики вынуждены реализовывать небезопасный механизм аутентификации. Я не уверен, что код, из-за которого происходит утечка секретных материалов, должен быть включен в стандартную комплектацию.

Есть ли прогресс в решении этого вопроса? Кто-нибудь готов принять награду по этому вопросу? Я был бы заинтересован в том, чтобы внести свой код или заплатить вознаграждение, если это так.

Я отдам предпочтение 3.12.

Мне было бы интересно внести свой код

Очень приветствуется выпуск PR для этого, конечно.

Я был бы заинтересован в том, чтобы внести свой код или заплатить вознаграждение, если это так.

Стать спонсором — хороший способ внести свой вклад. Спонсоры имеют приоритетную поддержку и могут решить проблему, если это необходимо. https://fund.django-rest-framework.org/topics/funding/#corporate-plans

Все это звучит здорово! Теперь я спонсор drf и encode. Я обязательно обновлю этот выпуск, если/когда начну работу над разрешением.

Фантастика, большое спасибо. 🙏

Хорошо, так что действительно не очевидно, как решить это изящно.

Нам бы очень хотелось, чтобы модель просто использовала автоматически увеличивающийся int для первичного ключа, а поле «ключ» было стандартным уникальным индексированным полем, но мы не можем перейти на это. Итак, какие у нас варианты...

• Мы могли бы ввести что-то вроде rest_framework.authtoken2 и сделать так, чтобы документы ссылались на него, чтобы новые проекты получали лучший набор значений по умолчанию.
• Мы могли бы продолжать использовать существующее поле в качестве PK и добавить новое поле для фактического значения токена. Не ясно, можем ли мы ввести миграцию данных, копируя значения, как это могло бы быть? быть проблематичным для пользователей с большими существующими наборами данных. Это выглядит прилично... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django Нам также нужно быть очень осторожными в отношении правильного поведения для неперенесенных кодовых баз. Если бы мы работали над развернутым приложением, мы обычно хотели бы начать с введения нового поля и обеспечения того, чтобы мы записывали одни и те же значения в оба поля, в то время как кодовая база по- прежнему ссылалась бы на старое поле в течение определенного периода времени. И только после того, как все это будет развернуто и синхронизировано, внесите изменение кода, переключающееся на использование нового поля.
• Мы могли бы продолжать как есть, но внести некоторые изменения в администрацию.

У кого-нибудь есть предварительные мысли по этому поводу?

Кроме того: вот почему этот вопрос так долго находится на рассмотрении — на него нет простого ответа. 😬

Я открыл #7341, чтобы посмотреть на опцию _"внести некоторые изменения администратора"_.