Django-rest-framework: 토큰 관리 페이지에서 액세스 토큰을 로그 파일로 유출

확인. 네. 이상적이지 않습니다.

토큰 관련 질문에 대한 답변은 전통적으로 제공된 구현이 의도적으로 (과도하게) 단순하고 더 복잡하거나 더 나은 것이 필요한 경우 사용자 정의 구현을 사용해야 한다는 것이었습니다. (여기서 결론은 유지 관리 부담을 합리적으로 유지하기 위해 여기에 더 이상 복잡성을 추가하지 않도록 했다는 것입니다.)

관리자 페이지 접근 권한이 있는 사용자(높음)와 로그 보기 권한이 있는 사용자(중간)의 접근 권한이 다릅니다.

프로덕션 환경에서 제공된 구현을 사용해야 하는 사람들에게는 이것이 사실이 아니라고 생각합니다.
(이 경우 그들은 동일한 사람이 될 것입니다.)

다른 사람들이 뭐라고 할지는 모르겠지만...

토큰 관련 질문에 대한 답변은 전통적으로 제공된 구현이 의도적으로 (과도하게) 단순하고 더 복잡하거나 더 나은 것이 필요한 경우 사용자 정의 구현을 사용해야 한다는 것이었습니다.

나는 이 입장을 이해하지만 문서는 사용자에게 최소한 내장 구현을 사용하지 않도록 강력히 권장해야 하며 극단적인 경우에는 사용을 중단해야 합니다. 토큰/서명 인증에 대한 타사 권장 사항은 3년 동안 업데이트되지 않은 https://github.com/etoccalino/django-rest-framework-httpsignature 입니다. 나는 제 3자 토큰 제공자가 즉시 제공되지 않는다면 더 많은 관심이 있을 것이라고 상상할 것입니다.

이것은 매우 심각한 정보 공개 IMO이므로 authtoken의 기본 위치가 이 경우 올바른 방법인지 확신할 수 없습니다.

아니, 그래서 내가 그것을 닫지 않은 이유는 ...

제 답변이 의도한 것보다 거칠게 나왔다면 죄송합니다. 그건 제 목표가 아니었습니다.

아무 문제 없습니다! 😃

(URL에 있는 키의 해시를 사용하도록 ModelAdmin을 mung할 수 있는지 궁금합니다...)

교활하지만 그 생각도 위험하게 느껴지지만 이유는 말할 수 없습니다.

마이그레이션은 작업을 처리할 수 있어야 합니다. 까다로운 비트는 다른 테이블의 외래 키이지만 그럴 가능성은 거의 없습니다. DRF는 토큰에 대한 FK를 생성하지 않으며 사용자가 그렇게 할 이유도 많지 않습니다.

이전에 기본 키 필드를 마이그레이션하려고 시도한 적이 없는 것 같지만, 이를 처리하는 작업이 있었고 해당 외래 키도 업데이트된 것으로 기억합니다.

예. 데이터 마이그레이션이 필요하지만 그렇지 않으면 전환하기에 충분히 쉬울 것입니다.

풀 리퀘스트를 환영합니다. 신고 감사합니다!

토큰은 반드시 고유해야 합니까?

문제를 이해하지만 이 문제를 해결하기 위해 생성하는 마이그레이션에 따라 다른 많은 문제가 발생할 수 있다는 점을 고려해야 합니다(예: 새 PK 필드를 도입하면 현재 동작에 의존하는 일부 다른 패키지가 손상될 가능성이 높습니다. ).

인증 토큰에 대한 Django 관리 페이지 내에서 참조로 사용되지만 테이블의 기본 키로 사용되지 않는 토큰 테이블에 자동 증가 정수 필드를 추가할 수 있는지 궁금합니다.

참고로 저는 확장 토큰 구현에도 동일한 문제가 있음을 방금 확인했습니다( django-rest-multitokenauth 참조). 관리자 패널에서 그 실수를 지적해 주셔서 감사합니다! 여기에서 솔루션을 볼 수 있기를 고대하고 있으므로 Python 패키지를 조정할 수 있습니다.

참고로 이것이 내 MultiTokenAuth 패키지 내에서 수정한 방법입니다.
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

토큰 테이블에 대한 외래 키가 있는 경우 잠재적으로 다른 사람들의 코드를 깨뜨릴 수 있다는 경고와 함께 동일한 수정 사항을 여기에 적용할 수 있다고 생각합니다.

안녕하세요,

나는 다가오는 프로젝트를 위해 이 라이브러리를 평가하기 전에 인증 관련 문제를 훑어보고 있었습니다. 간단한 질문이 있습니다. 도움을 주시면 감사하겠습니다.

관리자에서 토큰 모델을 등록하지 않음으로써 이 문제를 피할 수 있습니까?

@raunaqss 네, 등록할 필요가 없습니다.

다시 올려주셔서 감사합니다.

우리는 이것을 가지고 어떤 방향으로 가고 있는지 알고 있습니까?
url을 해시해야 합니까 아니면 pk를 마이그레이션해야 합니까?

PR을 할 수 있습니다.

마이그레이션은 여기에서 합리적인 접근 방식일 가능성이 높습니다.
나는 3.11 릴리스에 마이그레이션을 포함하는 것에 대해 매우 조심스럽게 생각합니다. 매우 큰 API 키 테이블을 가진 사람들에게는 문제가 있거나 예상치 못한 문제가 될 수 있습니다.
내 생각에 현명한 일은 아마도 이에 대한 마이그레이션을 별도로 릴리스하여 시작하여 일부 사람들이 우리 릴리스와 별도로 모든 것을 먼저 테스트할 수 있도록 하는 것이라고 생각합니다.
모든 것이 만족스러우면 마이그레이션을 직접 포함하는 것을 고려할 수 있습니다.

3.11 릴리스 자체에서 푸시하기 보다는 이에 대한 마이그레이션을 별도로 릴리스하는 방법을 살펴보겠습니다. 저는 API 키 테이블이 매우 큰 사용자가 주요 릴리스에서 모든 사용자에 대한 마이그레이션을 푸시하는 것에 대해 너무 조심스러워합니다.

이 문제는 오랫동안 공개되어 왔으며 @jarshwah 의 관찰 이 django-rest-knox 에 의해 해결된 것처럼 보이지만 기본적으로 더 안전하기를 원할 것입니다. drf의 의도가 TokenAuthentication 를 단순하게 하는 것이더라도 많은 개발자는 안전하지 않은 인증 메커니즘을 구현해야 합니다. 의도적으로 비밀 자료를 유출하는 코드를 기본적으로 포함해야 하는지 잘 모르겠습니다.

이 문제를 해결하는 데 진전이 있었습니까? 문제에 대해 현상금을 걸 수 있는 사람이 있습니까? 그렇다면 코드를 기여하거나 현상금을 지불하는 데 관심이 있을 것입니다.

3.12에 우선순위를 두겠습니다.

코드 기여에 관심이 있습니다.

물론 PR을 발행하는 것을 환영합니다.

그렇다면 코드를 기여하거나 현상금을 지불하는 데 관심이 있을 것입니다.

후원자가 되는 것은 기여하는 좋은 방법입니다. 후원자는 우선 지원을 받으며 필요한 경우 문제를 에스컬레이션할 수 있습니다. https://fund.django-rest-framework.org/topics/funding/# 기업 - 계획

모두 훌륭하게 들립니다! 저는 이제 drf 및 encode의 후원자입니다. 해결 작업을 시작할 때 이 문제를 업데이트하겠습니다.

정말 감사합니다. 🙏

좋습니다. 이 문제를 우아하게 해결하는 방법은 명확 하지 않습니다.

우리는 모델이 기본 키에 대해 자동 증분 int를 사용하고 "key" 필드가 표준 고유한 인덱싱된 필드가 되도록 하고 싶지만 마이그레이션할 수 없습니다. 그렇다면 우리의 선택은...

• rest_framework.authtoken2 와 같은 것을 도입하고 문서가 대신 이를 참조하도록 할 수 있으므로 새 프로젝트가 더 나은 기본값을 얻을 수 있습니다.
• 기존 필드를 PK로 계속 사용하고 실제 토큰 값에 대한 새 필드를 추가할 수 있습니다. 값을 복사하는 데이터 마이그레이션을 도입할 수 있는지 확실하지 않습니다. 기존 데이터 세트가 큰 사용자에게는 문제가 됩니다. 이것은 괜찮아 보입니다... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django 우리는 또한 마이그레이션되지 않은 코드베이스에 대한 여전히 올바른 동작에 대해 꽤 주의해야 합니다. 배포된 앱에서 작업하는 경우 일반적으로 새 필드를 도입하고 코드베이스 가 일정 기간 동안 이전 필드를 참조하도록 하는 동안 두 필드에 동일한 값을 쓰고 있는지 확인하는 것으로 시작하려고 합니다. 그리고 그것이 모두 배포되고 동기화되면 새 필드를 사용하도록 전환하는 코드 변경을 도입하십시오.
• 우리는 그대로 계속할 수 있지만 몇 가지 관리자 변경 사항을 도입합니다.

누구든지 이것에 대한 사전 생각이 있습니까?

또한: 이것이 이것이 오랫동안 보류된 이유입니다. 쉬운 대답은 없습니다. 😬

_"관리자 변경 사항 소개"_ 옵션을 보기 위해 #7341을 열었습니다.