xowo개발공부로그

2차 프로젝트를 진행하면서 사용해보지 않았던 query parameter(string)를 구현해봤기 때문에 잊기 전에 정리해본다. Query string 클라이언트가 웹사이트에서 입력한 데이터를 전달하는데 가장 널리 사용되는 방법이라고 한다. 가끔 웹사이트의 url주소가 매우 길 때 유심히 보면 물음표(?)로 시작하고 키=값&키=값으로 연결되어있는 부분이 query string이 적용된 부분이다. https://flights?depctycd=GMP&depctycd=CJU&arrctycd=CJU&arrctycd=GMP&depdt=2022-08-24 항공권 리스트 페이지의 경우 사용자로부터 입력받은 데이터를 받아와야 하기 때문에 urls.py의 url 주소는 ' ' 비어있게 설정해줬다. # flights/u..

초기 제품 모델링 매거진을 판매하는 웹 사이트를 선정하여 모델링 중 메인 카테고리와 서브카테고리를 나눴으나, 제품이 많지 않기 때문에 카테고리가 많지 않아도 될 것같다는 판단하에, 메인과 서브 카테고리를 나누지 않고 합치게되었다. 초기 모델링 -> 변경된 모델링 → 문제 발생 추후 기능구현 중 메인 카테고리에 대한 정보만 전달하고 싶은데 서브 카테고리 값도 불러오게되서 코드에 의미없는 슬라이싱이 추가되는 등 이상한 코드가 되어버렸다. related_name 활용한 모델링 → related_name 활용 many to many field 에서 역참조할때 _set 사용 대신 직접 이름을 지정하여 이 이름으로 역참조를 할 수 있게 만들어주는 related_name을 이런 경우에 사용할 수 있다는 멘토님의 조언..

path Variable GET method를 통해 데이터를 넘길 경우 경로를 변수로 사용한다. (특정 인덱스에 대한 조회) Django에서 제품의 상세페이지 url 주소를 path Variable를 활용하여 설정하는 방법을 정리해봤다. http://127.0.0.1:8000/products/1 제품의 상세페이지의 경우 제품의 id로 url 주소를 만들기 위해 products app의 urls.py와 models.py 코드를 수정 # products/urls.py 파일 from products.views import ProductDetailView urlpatterns = [ path('/', ProductDetailView.as_view()), ] # products views.py 파일 class P..

JWT? JWT(JSON Web Token)는 Json 포맷을 이용하여 Self-Contained 방식으로 사용자에 대한 정보를 저장하는 Claim 기반 Web 토큰으로 인가(Authorization)에 연관된 기술이다. 클라이언트의 요청(링크 클릭 etc..)이 들어올 때마다 서버는 요청을 한 사용자가 로그인, 인증과정을 거친 상태인지 확인해서 블로그 게시글 작성, 메일 확인, 댓글 확인과 같은 로그인이 필요한 기능들에 대해 허용을 해야 할지 응답해야 하는데, 매번 로그인을 하기에는 로그인 작업이 무거운 작업이기 때문에 로그인에 성공했을 때 토큰이라는 것을 전달한다. 이후 클라이언트의 요청이 들어올 때마다 로그인 대신 토큰을 확인하여 로그인 기록을 확인하여 응답을 한다. (설명이 틀렸을 수 있음..🥹)..

전 포스팅의 회원가입 구현과 회원 로그인 구현에서 사용자의 중요 정보(비밀번호)를 암호화하지 않았기 때문에 이번에는 bcrypy 라이브러리를 이용하여 어떤 방식으로 암호화를 하고 암호화한 사용자 정보를 어떻게 매칭 시켜 로그인이 되는지 과정을 정리해봤다. (이 포스팅에서 사용한 bcrypy 외에 장고 공식 문서에도 비밀번호를 어떤 방식으로 암호화하는지, 또 어떤 라이브러리가 있는지 확인 할 수 있다.) brcypy공식 문서에서 사용 방법을 보고 나름대로 이해한 것을 간략하게 정리했다. → bcrypy 설치 및 import → 클라이언트로부터 받은 정보 중 비밀번호를 데이터 테이블에 저장 시 암호화하여 저장 (회원가입) → 회원 로그인 시 입력 받은 비밀번호와 암호화하여 저장한 비밀번호를 encode하여 ..

회원 로그인 구현 이전에 작성한 회원가입 구현에 이어 간단한 회원 로그인을 구현해봤다. 먼저 회원 로그인 구현 시 중요한 점은 로그인 또한 사용자의 정보를 받는 것이기 때문에 보안이 필요하다. POST 방식은 GET방식과 다르게 URL에 붙여서 보내지 않고 HTTP BODY에 정보를 넣어 보내기 때문에 POST 방식으로 만들어야 한다. 또한, ★중요★ 사용자의 비밀번호는 암호화해서 db에 저장해야 하는데 이전 포스팅과 이 포스팅에는 적용하지 않았다. 암호화는 이후 공부하며 다시 재 포스팅하는 것으로 ^^... 그리고 마찬가지로 사전에 설치한 HTTPIE를 이용해 서버에 요청을 보내고 그에 따른 작업을 수행하고 요청에 맞는 응답을 보내도록 노력했다... models.py 모델링 조건 → 이름, 이메일, 비..

회원가입 구현 이전에 models.py에 클래스를 정의하여 데이터를 담을 수 있는 테이블을 만들었다면 HTTP통신을 통해 서버에 요청을 보내고 그 요청을 분석하여 처리할 수 있는 로직(View)을 실행시켜 데이터베이스와 통신하여 작업을 수행하고 요청에 맞는 응답을 보낼 수 있는 간단한 회원가입 API를 구현해보았다. HTTP를 통해 서버에 요청을 하면 전달하는 내용에 따라 내가 views.py에 정의한 오류들을 볼 수 있었고, 내가 정의하지 않은 오류가 발생할 경우 500 코드가 반환되는 것을... 볼 수 있었다.ㅠㅜ 아래 정의한 상태 코드 이 외 코드는 여기서 확인할 수 있다. models.py 모델링 조건 → 이름, 이메일, 비밀번호, 연락처 정보를 클라이언트에게서 받음 → 이메일 로그인 방식을 사용..

QuerySet? 쿼리 셋은 데이터베이스로부터 전달받은 객체의 목록(list)이다. 또한, 쿼리셋은 lazy 하기 때문에 생성 작업을 할 때에는 데이터 베이스에서 데이터를 가져오지 않는다고 한다. >>> q = Entry.objects.filter(headline__startswith="What") >>> q = q.filter(pub_date__lte=datetime.date.today()) >>> q = q.exclude(body_text__icontains="food") >>> print(q) # 장고의 쿼리셋은 위 pritn문에서 데이터베이스에 들어가 데이터를 가져온다. # 이전 작업에서는 데이터베이스에서 정보를 가져오지 않는다. ★ queryset을 살펴보기 전에 데이터 베이스를 살펴보자 데이터..

장고는 manytomanyfield를 제공하기 때문에 사용자가 매핑 테이블(중간 테이블)을 직접 만들지 않아도 되지만 직접 만들어보았다. 필드 사용과 미사용 시 비교됬던 부분 직접 매핑 테이블을 구현했을 때 - 사용자가 직접 중간 테이블에서 서로의 id값을 넣어줘야 한다. (데이터가 많으면 관리가 어려울 것 같다) - many to many field를 사용하지 않았기 때문에 매핑테이블로 직접 들어가서 정보를 가져와야한다. 장고에서 제공하는 many to many field를 사용했을 때 - 사용자가 중간 테이블을 이용하고 싶다면 through 옵션을 통해 직접 중간 테이블을 지정할 수 있다. - 필드를 정의했기 때문에 참조 시 매핑 테이블을 들어가지않고 필드로 정의한 변수(?)를 통해 간접적으로 정보를..

장고 튜토리얼 models.py 에서는 함수(def)로 정의했으나 클래스(class)로 정의해보았다. # 데이터 베이스 테이블이 될 class를 작성 (첫글자 대문자) class Category(models.Model): # Category 테이블의 column이 되는 부분('name')과 row 값(models.~~~)이 들어가는 부분이다 # 값은 python3 shell 에서 직접 넣어준다 name = models.CharField(max_length = 50) menu = models.ForeignKey('Menu', on_delete = models.CASCADE) # 데이터 테이블의 이름이 되는 코드 복수형으로 작성 class Meta: db_table = 'categorise' # mysql..