tracking(oauth): Error tracking issue

[ChoiWheatley]

안녕하세요! 오늘 OAuth 진행에 많은 도움을 주셔서 감사합니다! 👍 책 집필 내용에 OAuth에서 문제가 발생했던 부분들과 그 해결방법에 대해서 작성하려고 합니다. 오늘 많은 사람들이 고통받았던 Redirect URI를 포함한 다양한 문제상황에 대하여 생각나시는 대로 아래 스레드에 답글 달아주시면 감사하겠습니다!

[Water-Stone]

• Redirect URI를 입력할 때 http://localhost:8000가 아니라 http://127.0.0.1:8000으로 해야합니다.
  • 둘의 차이점? 참고: https://www.baeldung.com/cs/127-0-0-1-vs-localhost

  More often than not, localhost and 127.0.0.1 are used interchangeably. The two are considered the same thing. However, there are subtle differences that exist between them. Let’s look at these:
  Firstly, the IP address associated with localhost has to be resolved or looked up, while 127.0.0.1 does not usually require resolution.
  Secondly, localhost is not always resolved to 127.0.0.1. It may be resolved to another address within the loopback block of addresses.

[xkimido]

• Redirect URI를 입력할 때 http://localhost:8000가 아니라 http://127.0.0.1:8000으로 해야합니다.

  • 둘의 차이점? 참고: https://www.baeldung.com/cs/127-0-0-1-vs-localhost

  More often than not, localhost and 127.0.0.1 are used interchangeably. The two are considered the same thing. However, there are subtle differences that exist between them. Let’s look at these:
  Firstly, the IP address associated with localhost has to be resolved or looked up, while 127.0.0.1 does not usually require resolution.
  Secondly, localhost is not always resolved to 127.0.0.1. It may be resolved to another address within the loopback block of addresses.

저도 오늘 이 부분이 궁금했는데 레퍼런스 감사합니다!!
링크 보내주신 거 읽고서 조금 더 찾아보니 아래와 같은 차이점이 있다고 해요.
ref: https://velog.io/@lky9303/127.0.0.1-과-localhost의-차이

비유적으로 localhost:8000 은 www.naver.com 이고
127.0.0.1:8000 은 125.209.222.141(네이버 ip주소) 라고 생각하면 될 듯 하다.

루프백은 내 컴퓨터가 내 컴퓨터에 응답을 보내고 받는 기능이기 때문에, DNS 서버를 통해 ip주소로 변환할 수 있는 기능이 없다.
때문에 OS가 이를 조정을 해주어야 되는데, 그것을 담당하는 부분이 OS hosts 파일의 redirect rules이다.

여기에서 localhost 를 어떤 ip로 redirecting 시켜줄지를 지정해줄 수 있는데, 만약 이 부분에서 localhost의 redirecting ip를
다르게 지정해 놓았다면 localhost:8000을 브라우저에 입력하더라도 원하는 결과를 얻지 못할 수 있다는 것이다.

[xkimido]

커스텀 User 모델을 사용할 때 이슈 발생

allauth 라이브러리의 기본 설정은 표준 User 모델을 대상으로 하기 때문에
커스텀 User 모델을 사용 중인 경우에는 그에 맞게 라이브러리 설정값을 변경해주어야 합니다.
별도로 설정을 하지 않고 소셜로그인을 구현했을 때에는 아래와 같은 에러를 만나게 됩니다.

내용을 보면 User 객체에 username 속성이 존재하지 않기 때문에 문제가 발생합니다.
위의 에러를 해결하기 위해서는 아래와 같이 allauth 라이브러리 설정을 변경해 줄 필요가 있습니다.
(User 모델이 USERNAME_FIELD = "email"로 설정되어 있는 경우를 가정합니다.)

settings.py

ACCOUNT_EMAIL_REQUIRED = True
: 이 설정을 True로 변경하면 사용자의 이메일 주소를 회원가입 시 필수 필드로 지정합니다.

ACCOUNT_AUTHENTICATION_METHOD = 'email'
: 사용자 인증 방법으로 이메일을 사용하도록 변경합니다.
이 설정을 email로 변경하려면 ACCOUNT_EMAIL_REQUIRED = True가 필요합니다.

ACCOUNT_USERNAME_REQUIRED = False
: username을 필수 필드로 지정하지 않음을 나타냅니다.
이렇게 설정 해줌으로써 username을 입력받지 않고도 회원가입이 가능하게 됩니다.

ACCOUNT_USER_MODEL_USERNAME_FIELD = None
: 이 설정은 User 모델의 username 필드를 지정하는 옵션입니다. 기본값이 username이기 때문에 위의
ACCOUNT_USERNAME_REQUIRED 설정을 False로 바꾸어도 여기에서 다시 에러가 발생합니다.
값을 None으로 변경하면 이메일로 사용자를 식별하기 때문에 비로소 username에 관련된 에러가 없어집니다!
이 설정을 None으로 변경하려면 ACCOUNT_USERNAME_REQUIRED = False가 필요합니다.

ref: https://django-allauth.readthedocs.io/en/latest/configuration.html

[xkimido]

SITE_ID 관련 에러: Site matching query does not exist

발생 경위

해당 에러는 요청에 대한 사이트와 일치하는 쿼리가 존재하지 않음을 나타냅니다.
SITE_ID가 잘못 설정되거나 django_site 테이블에 해당 사이트 정보가 없을 경우, 관련된 에러가 발생할 수 있습니다.
SITE_ID는 장고 프로젝트에서 여러 사이트를 관리할 때 사용되는 변수라고 합니다.

Sites 탭에서 기본값으로 존재하던 example.com 값을 수정하는 것이 아닌 값을 새로 만든 후에
example.com을 삭제하고 소셜 로그인을 시도하면 위와 같은 에러를 만나게 됩니다.
(id값이 2인 127.0.0.1:8000 추가되고, id값이 1인 example.com 삭제되면서 에러가 발생)

해결

settings.py

django_site 테이블에서 사이트의 id값을 확인합니다.
해당 값을 SITE_ID에 저장해주면 에러가 해결됩니다!
사실 테이블 확인 안 하고 SITE_ID = 1일 경우 에러가 난다면 2 또는 3으로 바꿔주면 해결된다고 합니다.