async event loop 기반 framework 인 python tornado 를 사용하여 웹소켓 서버에 데이터를 보내던 중에 문제가 발생했다.

tornado 는 멀티스레딩 사용 시 main event loop 에서 실행할 기능을 콜백에 담아 처리한다. 그래서 for loop 을 돌며 client 에게 메시지를 전달하는 로직을 구현했다.

# 중략
for client in self.clients:
    data = json.dumps({self.stock_code: stock_price})

    self.loop.add_callback(lambda client:client.write_message(data))
    # time.sleep(0.0000001)

self.clients 는 웹소켓에 접속한 클라이언트이다. 다음과 같은 코드를 돌렸을 때 맨 마지막에 접속한 클라이언트에게만 메시지를 보내는 버그가 발생했다. 그런데 아주 임시방편으로 아주 짧은 시간동안 print() 함수를 실행했더니 또 작동하는 것이였다.

왜 그런지 고민끝에 이유를 발견했다.

다음 예제를 보자.

funcs = []
for i in range(5):
    funcs.append(lambda : print(i))

# i 값은 이 때 4이다.
for f in funcs:
    f()

결과는 4만 다섯번 출력된다. 이유가 뭘까?

• 바로 lambda 가 evaluate 되서야 비로서 코드가 생성되기 때문에 for loop에서 마지막 값인 4가 출력되는 것이다.

• 그리고 time.sleep 함수가 실행됐을 때 제대로 작동하는 것 처럼 보였던 이유는, add_callback() 에 함수가 담기고 나서 time.sleep() 이 실행되는 동안 add_callback() 에 들어있는 함수가 해당 for loop 안에서 실행이 될 준비가 되었기 때문이였다.

• 하지만 time.sleep() 이 없었을 떈 for loop 가 너무 빨리 돌아버려서 loop 이 끝나버린 뒤 함수가 실행준비가 되었기 때문에 마지막 client 에게만 데이터가 간 것이였다.

그렇다면 이런 이슈를 해결하기 위해 우리는 어떻게 할 수 있을까?

functools.partial

함수가 생성될 때 evaluate 되는 고차함수 partial 을 쓰면 된다.

from functools import partial
funcs = []
for i in range(5):
    funcs.append(partial(print, i))

for f in funcs:
    f()

결과는 차례대로 0 1 2 3 4 가 출력된다.

하지만 여기서 방법이 끝이아니다.

lambda default argument

lambda 의 default argument 를 사용하는 방법이 있다.

Using a default argument works because default arguments are evaluated when the function is created, not when it is called.

https://stackoverflow.com/a/10452819

default args 를 사용하면 해당 args 는 함수가 실행될 때가 아니라 생성될 때 evaluate 되기 때문에 이 방법도 해답이 될 수 있다.

wrap-up

중요한 것은 lambda 의 변수가 evaluate 되는 시점이다.

우리가 이 문제를 해결하기 위한 최선의 선택은 lambda 에 들어가는 함수가 얼마나 복잡한지에 따라 결정되는 것 같다.

• 복잡하다면 : functools.partial
• 간단하다면 : lambda expression

파이썬 스크립트에 sys.path.append 를 추가해주는 방법도 있지만, 환경변수 추가를 함으로써 스크립트를 깔끔하게 유지하기로 했다.

$ export

그냥 export PYTHONPATH="${PYTHONPATH}:/your/source/root" 이렇게 해줄수도 있지만, 이건 임시적인 방법이라 이렇게 하면 컴퓨터를 재부팅했을 때 환경변수가 사라진다.

zsh 를 쓰고있기 때문에 ~/.zshenv 에 환경변수를 추가하고 source ~/.zshenv 로 업데이트를 해준 뒤 echo $PYTHONPATH 로 적용이 되었는지 확인해보았더니 환경변수 경로가 제대로 출력된다.

• 처음에 c_alphabet.replace 를 했을 때 c_alphabet 객체 자체의 변화가 있을 줄 알았는데 그렇지 않아서
• c_alphabet = c_alphabet.replace(c, '?', 1) 처럼 같은 변수에 값을 다시 재할당 해주었다.
• 왜냐면 string 자료형은 immutable 하다.
• immutable 객체들은 값이 변경될 때 새로운 객체로 생성이 되기 때문에 변경이 일어날 때 기존 객체는 변하지 않는다.
• 마찬가지로 string 자료형을 replace 로 변경하려고 하면, 새로운 메모리를 참조하는 객체가 새로 생성되며, 이를 새로운 변수에 다시 할당해주어야 한다.

immutable 한 객체들은 call by value 의 속성을 띄고 있다.

LINE 1: ...' * ('2021-05-07'::date - "stock_prices"."date")) / '7 days ...
                                                             ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.

위의 결과는 각각 캔들차트를 monthly, weekly 옵션을 넣어서 돌렸을 때 걸린 시간을 나타낸 것이다.

Application Level

기존에는 다음과 같이 시간복잡도가 O(n^2) 인 코드를 작성했다.

  class StockCandleChart(View):
    def get(self, request):
        chart_type  = request.GET.get('chart_type', 'daily')
        code        = request.GET.get('ticker', None)

        error_handler_res = handle_candle_chart_input_error(chart_type, code)
        if isinstance(error_handler_res, JsonResponse):
            return error_handler_res

        two_years_from_now = datetime.datetime.now() - relativedelta(years=2)

        ticker          = Ticker.objects.get(code=code)
        stock_prices_qs = StockPrice.objects.filter(ticker=ticker, date__gte=two_years_from_now).order_by('date')

        if chart_type == 'daily':
            stock_prices  = [
                                {
                                'date'    : str(stock_price_qs.date),
                                'bprc_adj': stock_price_qs.bprc_adj,
                                'prc_adj' : stock_price_qs.prc_adj,
                                'hi_adj'  : stock_price_qs.hi_adj,
                                'lo_adj'  : stock_price_qs.lo_adj,
                                'volume'  : stock_price_qs.volume
                                } for stock_price_qs in stock_prices_qs]
        else:
            groups_dict  = self.get_stock_price_groups_by_chart_type(chart_type, stock_prices_qs)
            stock_prices = self.get_stock_prices_list(groups_dict)

        data = {
                'name'  : ticker.stock_name,
                'ticker': ticker.code,
                'values': stock_prices
            }

        return JsonResponse({'results': data}, status=200)

    def get_stock_price_groups_by_chart_type(self, chart_type, stock_prices_qs):
        pre_group_num = int()
        groups_dict   = dict()

        for stock_price_qs in stock_prices_qs:
            if chart_type == 'weekly':
                today       = datetime.datetime.today()
                this_friday = today + datetime.timedelta((calendar.FRIDAY - today.weekday()) % 7)
                base_date   = this_friday.date()

                time_diff         = (base_date - stock_price_qs.date).days
                current_group_num = int(time_diff / 7)

            elif chart_type == 'monthly':
                current_group_num = stock_price_qs.date.strftime('%Y-%m')

            groups_dict.setdefault(current_group_num, [stock_price_qs])

            if current_group_num == pre_group_num:
                groups_dict[current_group_num].append(stock_price_qs)
            pre_group_num = current_group_num

        return groups_dict

    def get_stock_prices_list(self, groups_dict):
        stock_prices = list()

        for group in groups_dict:
            stock_price_list = groups_dict[group]

            first_stock_price = stock_price_list[0]
            last_stock_price  = stock_price_list[-1]

            bprc_adj = first_stock_price.bprc_adj
            prc_adj  = last_stock_price.prc_adj

            lowest  = first_stock_price.lo_adj
            highest = first_stock_price.hi_adj
            volume  = 0

            for stock_price in stock_price_list:
                if stock_price.lo_adj < lowest:
                    lowest = stock_price.lo_adj

                if stock_price.hi_adj > highest:
                    highest = stock_price.hi_adj

                volume += stock_price.volume

            weekly_stock_price = {
                'date': last_stock_price.date,
                'bprc_adj': bprc_adj,
                'prc_adj': prc_adj,
                'hi_adj': highest,
                'lo_adj': lowest,
                'volume': volume
            }
            stock_prices.append(weekly_stock_price)

        return stock_prices

하지만 아무리 생각해도 너무 for 문이 많고 복잡도가 높은 것 같아서, App Level 이 아니라, DB Level 에서 처리해보기로 했다.

DB Level

일주일 그룹 데이터의 거래량(volume), 고가(hi_adj), 저가(lo_adj) 구하기

SELECT time_diff, SUM(volume) volume, MAX(hi_adj) hi_adj, MIN(lo_adj) lo_adj 
FROM (SELECT *, (date '2021-04-29' - date) / 7 as time_diff
      FROM stock_prices WHERE ticker_id=3 ORDER BY date) td
GROUP BY time_diff ORDER BY time_diff;

일주일 그룹 데이터의 종가(prc_adj) 구하기

weekly candle chart 는 일주일으로 묶인 주식 가격 그룹의 가장 마지막 날의 종가를 구해야한다.

SELECT *
FROM 
    (SELECT *, row_number() OVER(PARTITION BY time_diff ORDER BY date DESC) "row_number" 
     FROM (SELECT *, (date '2021-04-29' - date) / 7 as time_diff 
           FROM stock_prices
           WHERE ticker_id=3
           ORDER BY date) td) td2 WHERE row_number=1;

일주일 그룹 데이터의 시가(bprc_adj) 구하기

PARTITION BY 구문에서 DESC 를 ASC 로 바꿔주기만 하면 된다.

위 쿼리들은 각각 (거래량, 고가, 저가), 시가, 종가 를 세번에 걸쳐서 구한다. 이 모든걸 한 번의 쿼리로 수행되게끔 바꿀 수 있는 쿼리는 무엇인지 생각해보았다.

날짜, 거래량, 고가, 저가, 시가, 종가 한번에 SELECT 하기

SELECT 
    MAX(date), SUM(volume) volume, MAX(hi_adj) hi_adj, MIN(lo_adj) lo_adj, MAX(first_bprc_adj) bprc_adj, MAX(last_prc_adj) prc_adj
FROM
    (
    SELECT
        FIRST_VALUE(bprc_adj) OVER(PARTITION BY group_id ORDER BY date) first_bprc_adj,
        FIRST_VALUE(prc_adj) OVER(PARTITION BY group_id ORDER BY date DESC) last_prc_adj,
        *
        FROM
            (SELECT *, (date '2021-04-30' - date) / 7 group_id FROM stock_prices) t1
        WHERE ticker_id = 3
    ) t2
    GROUP BY group_id

group by 에서 지정되지 않은 컬럼은 집계함수를 못쓰지만, 어차피 모두 동일한 값을 가지고 있는 필드 값들에서 max 든 min 등 하나의 값을 반환하기 때문에 이렇게 했다.

16 times faster

weekly 기준 db level 에서의 속도가 약 16배 빠르다.

Wrap-up (Final Codes)

def get_candle_chart_by_type(self, chart_type, stock_prices_qs):
        if chart_type == 'daily':
            results_qs = stock_prices_qs.values('date', 'bprc_adj', 'prc_adj', 'hi_adj', 'lo_adj', 'volume').order_by('date')
            return list(results_qs)

        if chart_type == 'weekly':
            today       = datetime.datetime.today()
            this_friday = today + datetime.timedelta((calendar.FRIDAY - today.weekday()) % 7)
            base_date   = this_friday.date()

            first_qs = stock_prices_qs.annotate(group_id=Cast(
                                        ExtractDay(base_date - F('date')), IntegerField()) / 7).order_by('date')
        elif chart_type == 'monthly':
             first_qs = stock_prices_qs.annotate(group_id=TruncMonth(F('date'))).order_by('date')

        second_qs = first_qs.values('group_id')\
                            .annotate(
                                    bprc_adj=Window(
                                        expression   = FirstValue('bprc_adj'),
                                        partition_by = F('group_id'),
                                        order_by     = F('date').asc()
                                    ),
                                    prc_adj=Window(
                                        expression   = FirstValue('prc_adj'),
                                        partition_by = F('group_id'),
                                        order_by     = F('date').desc()
                                    ),
                                    date=Window(
                                        expression   = Max('date'),
                                        partition_by = F('group_id')
                                    ),
                                    hi_adj=Window(
                                        expression   = Max('hi_adj'),
                                        partition_by = F('group_id')
                                    ),
                                    lo_adj=Window(
                                        expression   = Min('lo_adj'),
                                        partition_by = F('group_id')
                                    ),
                                    volume=Window(
                                        expression   = Sum('volume'),
                                        partition_by = F('group_id')
                                    )
                            )\
                            .distinct('date')\
                            .values('date', 'bprc_adj', 'prc_adj', 'hi_adj', 'lo_adj', 'volume')
        results = list(second_qs)
        return results

위와 같은 예제 snippet 처럼 작성하거나

이렇게 직접 환경변수의 DJANGO_SETTINGS_MODULE 에 접근해서 default 로 사용할 settings 파일을 지정해줘도 된다.

둘중 택 1을 해서 작성한 뒤, django.setup() 을 실행해준다.

주식 가격을 클라이언트들에게 websocket 을 통해 push 하려고 Django 의 Channels 를 사용하던 중 의문점이 들었다.

• Django Channels 에서 유저가 consumer 를 통해 접근하면
• 다음과 같이 해당 유저의 individual channel 이 설정해놓은 group 으로 참여되도록 했다.

해당 group 의 이름을 알면 그 group 에 연결된 모든 channel 들에게 메시지를 전달하는게 가능하다. 그래서 그 group 의 이름을 알아야했는데, 문서 어디를 찾아봐도 group 리스트를 구하는 방법이 나와있지 않았다.

그 때 갑자기 channel layers 를 관리하기 위해 redis 서버를 세팅했던 것이 생각났다.

바로 redis 서버에 접속해서 모든 keys 를 확인해봤더니,

서버에 모든게 저장되어있었다.

https://github.com/django/channels_redis#prefix

처음 세팅했던 channels_redis 모듈이

• 채널과 그룹이 생성되고 어떤 채널들이 특정 그룹에 연결되는지와 같은 정보들을 저장하고,
• 그 정보들을 사용하여 그룹에 있는 채널들에게 메시지를 보낼 수 있도록 한다.

다음은 redis 서버와 django channels 가 어떤식으로 상호작용하는지 설명한 글이다.

It depends on how you are using it. The primary purpose of redis in django-channel_layers is to store the necessary information required for different instances of consumers to communicate with one another. For example, in the tutorial section of channels documentation, it is clear that Redis is used as a storage layer for channel names and group names. These are stored within Redis so that they can be accessed from any consumer instance. If for example, I create a group called 'users' and then add 3 different channel names to it, this information is stored in Redis. Now, whenever I want to send data to the channels in the group I can simply reference the group from my consumer and Django-channels will automatically retrieve the channel names stored under that group in Redis. On the other hand, if you want to use consumers in a non-conventional way, that is, as background workers then Redis becomes a message queue. That's because when you send a message containing a task to be done by one of the background workers (a consumer that 'consumes' the tasks) those messages have to be stored somewhere so that the background workers can retrieve them as they finish up other tasks.

https://stackoverflow.com/questions/63754950/what-role-does-redis-serve-in-django-channels

How to retreive data from redis server

django-channels 자체에서 모든 groups 와 연결된 channels 들을 가져오는 것이 불가능하다고 해서, 아 그럼 django 프로젝트 안에서 redis 서버에 접근한 다음 저 group name 을 가지고 오기만 하면 된다 라고 생각했으나, 그렇게 다시한번 서버에 접근하는것이 비효율적이라고 판단했다.

그래서 그냥 백그라운드 스레드를 실행시켜서 해당 ticker 를 key 로 잡고 연결된 channels 들을 해당 key 의 value 로 관리했다.

• ANIMAL_INS 에서 ANIMAL_OUTS 를 LEFT JOIN 해준 뒤,
• ANIMAL_OUTS 의 ANIMAL_ID 값이 NULL 인 부분을 가지고 와서
• 오래된 순으로 ORDER BY 뒤 LIMIT 3 을 걸어주면 된다.

SELECT A.NAME, A.DATETIME
FROM ANIMAL_INS A LEFT JOIN ANIMAL_OUTS B
                         ON A.ANIMAL_ID = B.ANIMAL_ID
WHERE B.ANIMAL_ID IS NULL
ORDER BY A.DATETIME LIMIT 3;

오랜 기간 보호한 동물(2)

• INNER JOIN 으로 ANIMAL_INS 와 ANIMAL_OUTS 를 합친다.
• ANIMAL_OUTS.DATETIME 에서 ANIMAL_INS.DATETIME 를 뺀 값을 기준으로 ORDER BY 한다.
• 두 값을 뺀 값이 가장 높은 것이, 보호소에 있었던 시간이 가장 길기 때문에 DESC 으로 정렬한다.

-- 코드를 입력하세요
SELECT A.ANIMAL_ID, A.NAME
FROM ANIMAL_INS A INNER JOIN ANIMAL_OUTS B
                         ON A.ANIMAL_ID = B.ANIMAL_ID
ORDER BY (B.DATETIME - A.DATETIME) DESC LIMIT 2;

보호소에서 중성화한 동물

• 두 테이블을 OUTER JOIN 한 뒤 입양할 때와 입양보내졌을 때의 SEX 상태가 다른걸 찾으면 된다.

-- 코드를 입력하세요
SELECT A.ANIMAL_ID, A.ANIMAL_TYPE, A.NAME
FROM ANIMAL_INS A INNER JOIN ANIMAL_OUTS B
                          ON A.ANIMAL_ID = B.ANIMAL_ID
WHERE A.SEX_UPON_INTAKE <> B.SEX_UPON_OUTCOME
ORDER BY A.ANIMAL_ID;

Problem

장바구니에 물건이 8개보다 많은 유저의 이름을 구해보자

테이블은 다음과 같이 구성돼있다.

carts

orders

order_status

users

• 우선 carts 테이블에 들어있는 order_id 건에 대해서
• order_status 의 status 가 "구매전"인 order 의 order_id 만 가져와야한다.

SELECT * a.id
FROM orders a INNER JOIN order_status b
                      ON a.order_status_id = b.id
WHERE b.status = "구매전";

• 가져온 order_id 가 있는 테이블과 carts 테이블을 inner join 한다. (left join 해도 상관없음)

• 그 뒤 order_id 로 group by 한 뒤 sum(carts.quantity) 가 8 보다 큰 order_id 만 뽑아온다.

SELECT b.order_id
FROM (SELECT * a.id
      FROM orders a INNER JOIN order_status b
                            ON a.order_status_id = b.id
      WHERE b.status = "구매전") a INNER JOIN carts b
                      ON a.id = b.order_id
      GROUP BY order_id
      HAVING SUM(b.quantity) > 8;

• 8 보다 큰 order_id 가 있는 테이블과 orders 테이블을 join 하고, join 된 테이블에서 또 users 테이블을 join 한 뒤 users.name 만 SELECT 해주면 끝!

SELECT c.name
FROM (SELECT b.order_id
FROM (SELECT * a.id
      FROM orders a INNER JOIN order_status b
                            ON a.order_status_id = b.id
      WHERE b.status = "구매전") a INNER JOIN carts b
                      ON a.id = b.order_id
      GROUP BY order_id
      HAVING SUM(b.quantity) > 8) a INNER JOIN orders b
                                            ON a.order_id = b.id
                                    INNER JOIN users c
                                            ON b.user_id = c.id;

-- 코드를 입력하세요
SELECT ANIMAL_OUTS.ANIMAL_ID, ANIMAL_OUTS.NAME
FROM ANIMAL_OUTS LEFT JOIN ANIMAL_INS
ON ANIMAL_OUTS.ANIMAL_ID = ANIMAL_INS.ANIMAL_ID
WHERE ANIMAL_OUTS.ANIMAL_ID NOT IN (SELECT ANIMAL_ID FROM ANIMAL_INS)

• ANIMAL_OUTS 에만 있고, ANIMAL_INS 에는 없는 row 를 반환하면 된다.
• 그러기 위해서는, ANIMAL_OUTS 를 기준으로 (LEFT) OUTER JOIN 을 한다.
• 그 다음, WHERE 구에서 ANIMAL_OUTS.ANIMAL_ID 가 ANIMAL_INS.ANIMAL_ID 에 들어있지 않는 경우를 NOT IN (서브쿼리) 를 사용해 조건을 지정해준다.

마지막 WHERE 구를 다음과 같이 변경해도 된다.

-- 코드를 입력하세요
SELECT ANIMAL_OUTS.ANIMAL_ID, ANIMAL_OUTS.NAME
FROM ANIMAL_OUTS LEFT JOIN ANIMAL_INS
ON ANIMAL_OUTS.ANIMAL_ID = ANIMAL_INS.ANIMAL_ID
WHERE ANIMAL_INS.ANIMAL_ID IS NULL;

결과

인덱스는 테이블에 붙여진 색인이며, 검색속도를 향상시키는 역할을 한다.

여기서 "검색" 이란, SELECT 명령에 WHERE 구로 조건을 지정하고 그에 일치하는 행을 찾는 일련의 과정을 말한다.

따라서, 테이블에 인덱스가 지정되어 있으면 효율적으로 검색할 수 있으므로 WHERE 로 조건이 지정된 SELECT 명령의 처리 속도가 향상된다.

ALGORITHM FOR THE INDEXING

• 테이블에 인덱스를 작성하면 테이블 데이터와 별개로 인덱스용 데이터가 저장장치에 만들어진다.
• 이 때 이진 트리(binary tree) 라는 데이터구조로 작성된다.

• 원하는 수치와 비교해서 더 크면 오른쪽, 작으면 왼쪽의 가지를 조사해나간다.

• 인덱스를 작성하면 애초에 이진 트리구조로 데이터를 저장하기 때문에 이진탐색만 하면 된다.

• 이진트리에서 같은 값을 가지는 노드를 여러 개 만들 수 없다는 특징은, 키값이 unique 한 컬럼에 대해서만 해당되는 이야기다.

• 키값이 unique 하지 않으면 가지가 두개가 아니라 세개 (하나는 같은경우) 가 된다.

How to create INDEX?

CREATE INDEX 인덱스명 ON 테이블명 (컬럼명1, 컬럼명2, ...)

How to use INDEX?

EXPLAIN SELECT * FROM sample62 WHERE a = 'a';

sample62의 a 컬럼에 대해서 인덱스를 작성했기 때문에, possible_keys 와 key 컬럼을 보면 해당 인덱스가 활용된 것을 볼 수 있다.

WHERE 조건을 바꿔서 a 열을 사용하지 않도록 한다면 당연한 얘기지만 인덱스를 사용할 수 없다.

when to use and when to not use?

만약 특정 컬럼의 데이터가 yes 나 no 로 데이터의 종류가 두개밖에 없다면 이진탐색에 의한 효율성을 기대할 수 없다. 데이터의 종류가 적으면 적을수록 인덱스의 효율이 떨어진다.

반대로 서로 다른 값으로 여러 종류의 데이터가 존재하면 그만큼 인덱싱의 효율은 좋아진다.

따라서 인덱스를 무조건 쓴다고 좋은것이 아니라, 언제 써야할 것인지를 고려하고 써야한다.

SQL 첫걸음 29강 : 인덱스의 작성과 삭제

그런데 cookie 에 대해서 좀 더 공부를 하려고 하던 중 다음 글을 보고 의문이 들었다.

Secure과 HttpOnly 쿠키 Secure 쿠키는 HTTPS 프로토콜 상에서 암호화된(encrypted ) 요청일 경우에만 전송됩니다. 하지만 Secure일지라도 민감한 정보는 절대 쿠키에 저장되면 안됩니다, 본질적으로 안전하지 않고 이 플래그가 당신에게 실질적인 보안(real protection)를 제공하지 않기 때문입니다. 크롬52 혹은 파이어폭스52로 시작한다면, 안전하지 않은 사이트(http:) 는 쿠키에 Secure 설정을 지시할 수 없습니다. 출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

user_id 도 민감정보 아닌가 ? 라는 의문이 들어서 검색해보니 여기서 말하는 민감정보란

다음과 같이 특정인을 지칭할 수 있는 정보들(PII)인 것 같았다.

• 전화번호
• 주민등록번호
• 주소
• etc...

그리고 위와 같은 민감 정보를 쿠키에 저장하게 되면,

쿠키는 로컬 저장소에 공유되기 때문에 A 라는 사이트에 접속해서 쿠키를 저장해두면, B 라는 사이트에 접속하면 거기서 A 라는 사이트에 저장된 쿠키를 얻을 수 있다. 또는 저장된 쿠키를 다른 악성 코드가 가져갈 수도 있다.

Then, is it okay to store in web-storage?

보안의 측면에서 웹 스토리지(로컬 스토리지 + 세션 스토리지)는 좋지않다고 말할 수 있다. 웹 스토리지에 저장된 값은 javascript 코드를 통해 언제든지 접근할 수 있는데, 이는 XSS(cross-site scripting) 공격에 취약하기 때문이다.

반면 쿠키에 저장한 값은 HttpOnly 속성을 통해 javascript를 통한 접근을 막을 수 있다. 그렇기 때문에 보안적인 측면을 생각한다면 웹 스토리지보다는 쿠키에 저장하는 것이 좋다고 할 수 있다.

https://woowacourse.github.io/javable/post/2020-08-31-where_to_store_token/

Cookie vulnerabilities

• XSS(크로스 사이트 스크립트)공격

˙ 자바스크립트를 이용하여 document.cookie 값을 탈취할 수 있음 -> 쿠키의 httpOnly 설정을 통해 차단가능, 하지만 이것도 완벽한 방법은 아니다.

• 스니핑(Sniffing)공격을 이용

˙ 네트워크를 통해 전송되는 쿠키값을 암호화하지 않고 전송하는 경우 네트워크 스니핑 공격을 통해 쿠키값을 탈취할 수 있음

• 공용 PC에서 쿠키값 유출

˙ 영속성 쿠키는 하드디스크에 저장되며, 간단한 방법으로 접근 가능하기 때문에 공용PC 사용시 PC에 저장된 사용자 정보가 유출될 수 있음

출처: https://coyagi.tistory.com/entry/시큐어코딩-쿠키-및-세션관리 [코코야이야기]

Conclusion

그래서 결론이 뭐냐? 결국 뭐든 안전해야하는건 클라이언트한테 넘기지 않는것이 좋다.

-> 그래서 로그인 할 때 토큰을 사용하는것이다.

토큰은 로컬스토리지에 저장하고 털려도 그냥 uuid 일뿐이다. 그러나 세션하이재킹같은 것은 가능하다.

그럼 이것을 어떻게 막느냐 ?

토큰 유효시간을 짧게? -> 소용없다, 실시간으로 해킹할 수도 있다.

그래서 보통

• IP
• 접속 pc 정보
• 브라우저 정보

와 같은 정보를 함께 암호화해서 토큰화시킨 뒤 나중에 값을 받을 때 복호화해서 대조한다. 위 정보들은 request 를 날릴 때 기본적으로 함께 들어가는 값이라서 서버에서 잘 꺼내서 토큰화시키면 된다. 토큰화 시킴과 동시에 서버에서 해당 값을 가지고 있어야 대조가 가능하기 때문에, 세션이든 db 든 메모리든 저장을 하고 있어야 한다.

나는 나중에 해당 ip 정보를 db 에 저장한 뒤 메모리에 캐싱하는 방식으로 해볼 예정이다.

어쨌든, 그래서 보안이 중요한 사이트들을 보면,

• 로그인을 하나의 ip 에서만 허용하거나
• 이 pc 기억하기와 같은 것이 있어서

pc 기억이 안되어있으면 이메일이나 휴대폰으로 인증을 하라고 하는 경우도 많다.

이 전까지는 그냥 user_id 만 payload 에 담아서 보내줬는데, 이후에는 좀 더 보안을 중요하게 생각해서 소개한 방법들을 적용할 계획이다.

• 먹방 프로젝트는, 직방 사이트에 영감을 받아 시작하게 된 프로젝트이다.
• 디자인과 기획 부분만 직방 레이아웃을 참고하였으며, 나머지는 프론트 3명 백엔드 2명으로 구성된 우리 먹방 팀에서 전부 다 구현하였다.
• 지도위에 맛집정보들을 표시해주는 사이트이며, 사용자가 직접 맛집을 등록할 수도 있고 리뷰와 평점, 사진을 남길수도 있게 제작하였다.
• 키워드 검색기능을 추가하여 주소, 맛집이름, 근처 지하철역 키워드로 검색할 수 있게 하였다.
• 카카오 API 로그인을 추가하여 사용자의 편리성을 더했고, 일반 회원가입(문자인증포함)을 추가하여 보안을 강화하려고 했다.

How is it different from the first one?

• 1차 프로젝트때와 달리 프로젝트의 pm 을 맡아, "Agile in scrum" 방식으로 매일 stand-up meeting 을 진행하고 Trello 로 스케줄을 관리하며 프로젝트를 주도적으로 진행했다.

• postman 으로 만든 API 들을 (요청할 uri, 요청 method, key 값, query params 값... 및 요청 예시) 와 함께 문서화하려고 노력했다.

• 프론트/백에서 겪는 blocker 를 혼자서만 해결하게 두지 않고 다같이 고민해보는 시간을 가졌다.

• 프론트/백 기능을 처음부터 떨어져서 각자 만들지 않았다. 같은 기능을 담당하는 프론트/백이 같이 모여서 만들면서, 서로가 데이터를 어떻게 처리할 것인지 로직을 충분히 설명한 이후에 코딩하는 방식을 고수했다.

• 만들다가 기능에서 이해가 되지 않는 부분이 있으면 바로바로 이야기 하도록 주도하여, 나중에 프론트/백 어느 한곳에서 기능을 다시 갈아엎어야하는 수고를 덜었다.

• 1차 때 하지 못했던 기능들을 최대한 많이 해보고 이해하려고 노력했다.

1. geopy, haversine 모듈을 활용한 위,경도 거리 계산
2. 카카오 API 를 활용한 소셜로그인 구현
3. 네이버 문자서비스를 통한 문자인증 로직 구현
4. select_related, prefetch_related 를 통한 쿼리 수 줄이기
5. django orm method 를 이용한 다양한 filtering 방법들 적용
6. unit test 작성

Agile in scrum

• 스크럼 방식으로 agile 하게 진행했다.
• 말로만 스크럼이 아니라, 실제로도 최대한 빨리 기능을 만든 다음 프론트/백 에서 맞춰보게 했다.
• 그렇게 함으로써 빠르게 전체적인 틀을 잡았고, 각자 세부적인 부분에 집중할 수 있었다.
• Trello 를 활용해 작업했으며, board 에 크게 스케줄을 크게 네가지 파트로 나눴다.
• Backlog -> This Week -> In Progress -> Done
• 팀/개인 별로 티켓 색깔을 구분하여 할당했으며, 우리 팀이 어느위치에 와있는지 한눈에 알 수 있었다.
• 필수 구현사항/추가 기능 구현사항 을 나누어 작업의 우선순위를 정했다.
• 매일 stand-up meeting 을 통해 팀/개인 별 작업 진행속도 및 각자가 처한 blocker 를 파악하는 시간을 가졌다. blocker 가 있으면, 혼자 고민하게 두지 않고 백엔드, 프론트엔드가 모두가 함께 고민하도록 했다. 이렇게 함으로써 한사람이 너무 앞서가거나 뒤쳐지지 않게 조절하려고 노력했다.

Communication

• 팀 내 communication tool 은 slack 을 사용했고,
• 코드 reviewer 와의 소통은 slack 및 github 에 올린 PR 의 code review 를 통해 진행했다.

My role in the project

As a Project Manager

• pm 을 맡아, 프로젝트의 전체적인 work flow 를 관리했다.
• 프론트/백엔드 가릴 것 없이 문제가 있으면 칠판 및 노트에 설명을 하면서 blocker 를 해결하려고 애썼다.
• 작업 속도를 보면서 2주 내에 구현하지 못할 기능들은 과감하게 제하고 추가 구현사항으로 빼놓음으로써, 필수적으로 구현해야 할 것들에 먼저 집중하게끔 노력했다.
• stand-up meeting 및 팀 내 communication 을 주도했다.

As a Backend

• 모델링
• Django project 초기 세팅
• Kakao API 소셜 로그인 & 회원가입, Naver 문자 서비스를 이용한 문자인증
• 가게 등록
• 위도, 경도, 축척, 화면 픽셀 & DPI 기준 가게 정보 표시
• 가게와 근처 지하철 사이의 거리 표시
• 가게 세부정보 표시
• 리뷰 등록 & 삭제
• 가게 검색
• 가게 찜하기, 찜하기 삭제
• 기준에 맞는 가게 필터링
• Django project RDS 에 연결 및 AWS EC2 인스턴스에 docker 를 활용하여 배포

Backend Modeling & APIs

1. Modeling

1차 프로젝트 때는 커머스 사이트라서 주문관리 때문에 모델링이 복잡했었다. 그래서 모델링에 대해 정말 많이 고민했었고 힘든 만큼 많이 배웠었다. 그 덕분에 2차 프로젝트는 수월하게 진행했다.

• 모델링은 user app, store app 두개로 나눠서 진행했다.

• 가게(stores) 테이블안에 주소(address) 정보를 넣으려고 하다보니 한 테이블 안에 정보가 너무 많기도 하고, 따로 독립적으로 addresses 로 테이블을 빼서 관리하는 것이 깔끔해 보였다.

• 그래서 처음엔 그냥 foreign key 로 address 가 stores 를 참조하도록 했다가,

• Django 의 one-to-one field 에 대해 공부했던 것이 생각나서 바로 적용해보았다.

• 1차 때는 one-to-one 관계 설정을 안해봤었는데, one-to-one field 를 쓰다보니 왜 사용하는지 몸소 깨닫게되었다. store.address_set 으로 접근을 안해도 된다는 점이 너무 편했다.

• 나머지 테이블에 대해서는 필요한 부분에 one-to-many, many-to-many 관계를 정했다.

2. Kakao API Login & Sign Up

• 카카오 소셜로그인 시 처음에 백엔드에서 인가토큰, 엑세스 토큰, 사용자정보를 다 받았었다.

• 그렇게 되면 백엔드에서 로그인 페이지로 redirect 까지 시켜줘야 했다. 이 부분은 프론트엔드의 부분이기 때문에 최종적으로

• 프론트에서 엑세스토큰을 받는 부분까지 처리한 뒤 토큰을 넘겨주면, 백엔드에서 해당 토큰으로 Kakao API 에 사용자정보를 요청하는 로직으로 변경하였다.

• 사용자정보를 받아 db에 정보가 없으면 회원가입을 시키고 없으면 그냥 or 로그인을 시킨 뒤 jwt 토큰을 발행해서 프론트에게 넘겨주었다.

• 추가적으로 통합회원 관리를 할 것인가 그렇지 않을 것인가에 대한 고민 끝에, 로그인 방식에 따라 각자 다른 유저로 취급하기로 했다. 그래서 다음과 같이 모델링 수정을 한번 거쳤다.

• id, created_at, updated_at 을 제외한 모든 field 값을 null 로 변경해주었다.

또 만약에 통합회원 관리를 하려면 어떻게 해야하는가에 대한 궁금증이 있었는데, 그렇게 하려면 회원가입을 먼저 시키고 로그인을 하게 한 다음 소셜 로그인을 연동하는 방식으로 진행해야한다.

그래야만 어떤 유저인지 알 수가 있고, 그 때 소셜 로그인을 연동하면 해당 유저 object 를 불러와서 kakao_id 든 google_id 든 해당 field 에 id 값만 추가하면 되기 때문이다.

3. Store Display depending on Latitude/Longitude & map scale & pixel

• 프론트에서 위도, 경도, 지도의 축척, 화면픽셀 값을 받으면 백엔드에서 화면의 위도 경도 바운더리를 계산 후, DB 에서 바운더리 내부에 있는 가게정보 표시했다.

로직은 생각보다 간단했다.

• 지도의 중앙으로 부터 지도의 위,아래/양옆 변에 해당하는 좌표를 구해야했다.

• 그러려면 사용자의 지도 좌표에서 지도 맨 끝쪽 까지의 거리를 알아야 했다.

• 축척이 주어져있어서 cm 당 몇 m 인지 알 수 있었다.

• 모니터 해상도 및 픽셀을 기준으로 실제 사용자의 화면에서 지도가 어느정도 크기인지 구했다.

• 지도의 길이와 축척으로 지도에 나타난 실제 가로세로 길이를 구했다.

• 이후에 중앙으로부터 수직으로 지도 오른쪽 끝부분까지 500m 라는 것을 알았으면 중앙의 위도/경도 + 동쪽으로 500m 를 계산해야했는데, 이 부분을 찾기 위해 스택오버플로우를 뒤져가며 위도/경도 에 거리를 더했을 때 위도 경도를 구하는 공식을 찾으려고 노력했다.

• 위도 경도 사이의 거리를 구하는 모듈은 많았는데, 위도 경도에 거리를 더했을 때 위도 경도를 구하는 모듈은 찾기 힘들었다.

• 그래도 결국 찾아냈다. geopy 라는 모듈의 distance method 를 사용하여 해결했다.

• 동서남북의 boundary 를 구한 뒤, db 에 addresses 테이블을 Q 객체로 필터링 했다.

DPI, INCH, SCALE_LEVEL 상수로 선언

get_boundary_range()

--> 한가지 문제점은 넘겨받는 인자 수가 5개나 된다는 것이다. 그래서 리팩토링 할 때 저 위도, 경도, 축척, 가로픽셀, 세로픽셀의 정보를 담고있는 *object 를 만든 뒤 그 object 자체를 함수에 넘겨줄 예정이다. *

그렇게 하면 훨씬 더 깔끔해질 것 같다.

store filtering with lat,lng boundary range

이 때 프론트 단에서 DPI 값을 구하는 모듈을 결국 못찾아서 백엔드에서 직접 DPI 값을 역으로 조정하면서 적절한 값을 찾았다. 프론트 테스트 환경에서 200 이 딱 오차없이 맞아서 DPI 를 200 으로 고정했다.

Distance between Store and Metro Station

haversine 모듈을 이용하여 위도/경도 간 거리를 구했다.

4. Store filtering with many categories & pagination

• 가게 정보를 보내줄 때, 프론트에서 두번 요청을 했다.
• 첫 번째 요청은 지도에 표시할 가게를 먼저 요청(업종, 가격범위 필터링 포함)
• 이후, 두 번째 요청은 가게 페이지 목록에 들어갈 가게 요청(리뷰순, 평점순 필터링 포함)

두 개의 API 를 만들기에는, 필터링을 해도 어차피 같은 data set 인데, 여러 API 를 만드는 것이 비효율적이라고 생각했다.

-> 같은 view 에서 가격범위, 업종, 리뷰 개수, 평점평균 에 따라 필터링 후 페이지네이션 까지 작성하고 파라미터만 다르게 받아서 처리하는 방식으로 로직을 구현했다.

• 필터링 과정에서 exclude(), annotate(), order_by(), field lookup 등 다양한 QuerySet API 를 활용하여 깔끔한 코드를 작성할 수 있었다.

• 또한 이 과정에서 select_related, prefetch_related 를 통해 DB 데이터를 메모리에 caching 하여 반복문 마다 쓸데없는 쿼리 수를 감소시켰다.

5. Store Search with keywords

• 가게 이름, 가게 주소, 근처 지하철역, 업종 이름으로 필터링을 했다.

• Q 객체를 사용하여 | 연산자로 필터링에 걸린 모든 store object 를 담았고, 중복된 object 들을 거르기 위해 distinct() 메소드를 사용했다.

• select_related, prefetch_related 를 사용하여 for 문마다 쿼리가 db 를 hit 하는 횟수를 감소시켰다.

6. Sign-Up, Text Authentication with Naver API

• 원래는 네이버에 문자인증 서비스라는 것이 따로 API 로 존재하는 줄 알았는데, 그냥 sms API 만 있어서 우리가 직접 문자인증 로직을 구현하기로 했다.

1. 휴대폰 번호를 입력받으면 프론트에서 백엔드로 핸드폰 번호 전달
2. 네자리 난수를 생성하고 네이버 문자인증 API 를 사용하여 해당 핸드폰 번호로 난수 전달
3. 성공적으로 메시지가 전달 되면, 프론트엔드에 해당 난수를 bcrypt 로 복호화 불가능하게 해싱해서 local storage 에 보관하게 함
4. 사용자가 문자를 받고 인증번호를 입력한 뒤 인증버튼을 누르면 프론트엔드는 local storage 에 가지고 있던 해싱된 난수 값과 사용자가 입력한 값을 백엔드에게 보낸다.
5. 백엔드는 해싱된 난수값과 사용자가 입력한 값을 bcrypt.checkpw 메소드로 비교한 뒤 맞으면 프론트에게 jwt 의 payload 에 exp 정보를 담아 토큰의 유효시간을 설정한 뒤 SECRET_KEY 로 SHA-256 알고리즘을 통해 jwt 를 암호화하여 프론트에게 전달한다.
6. 프론트는 jwt 를 local storage 에 저장한 뒤, 회원가입 시 form 에 입력된 값과 jwt 를 함께 백엔드에게 전달한다.
7. 백엔드는 jwt 를 검사하고 서버가 발행한 jwt 가 맞으면 회원가입을 시킨다.

--> 이렇게하면 db 를 거치지 않고 문자인증을 할 수 있다.

우리가 외부 도움없이 스스로 이런 로직을 생각해내고 적용했다는 점이 정말 뿌듯했고, 잘 할 수 있다는 자신감을 심어준 기능이였다.

Clean Codes

1. @classmethod

• 비슷한 정보들을 넘겨주다 보니, 같은 로직이 너무 많은 문제를 직면했다.

-> 빈번하게 사용되는 해당 가게의 리뷰 평점 평균과, 전체 리뷰 개수를 구하는 로직을 classmethod 로 만들어서 필요할 때마다 간편하게 사용했다.

2. class inheritance & method overiding with super()

• unit test 진행 시, 한 Test 클래스의 setUp() 에서 세팅해뒀던 코드가 다른 Test 클래스들에게도 많이 사용되고 있었다.

-> 불필요한 반복을 줄이기 위해 Base 클래스 를 만든 뒤, 다른 클래스에서 Base 클래스를 상속했다. -> setUp() 부분만 super() 로 메소드를 오버라이딩해서 사용했다. -> 이 때 Base 클래스에 __test__ = False 를 안하면 테스트 실행마다 Base 클래스가 계속 테스트되기 때문에 꼭 설정해줘야한다.

wrap-up

1차 프로젝트와 비교했을 때 훨씬 성장한 나를 볼 수 있었다.

내가 구현해야 할 기능에 매몰되서 내 것만 하는 것이 아니라, 내가 좀 느리게 가더라도 팀원들을 도우며 같은 속도로 가려고 했다.

다만 아쉬운점은, 프로젝트 발표였는데 우리는 마지막에 욕심을 내서 추가로 기능을 구현하려다가 발표준비가 다른 팀들에 비해 조금 미흡했던 점이 걸렸고, 팀원들한테 미안했다. 정말 잘 했다고 생각했고 기능 구현도 많이 했는데 발표에서 전부 다 우리가 했던 것들을 자랑하지 못해서 살짝 아쉬웠다.

개발자로서 코딩을 잘하는 것이 물론 중요하지만, 잘 만들고 마지막에 만든 결과물을 어필하는 능력까지 개발자의 몫이고 중요한 덕목이라고 생각한다.

다음부터는 준비를 더 잘 해야겠다!

그리고 다른 팀원들은 속으로 우리 팀을 어떻게 평가할지는 모르겠지만 내가 생각할 때 우리는 목표를 위해서 잘 달려온 것 같다.

서로를 믿고 도와주고 힘들더라도 묵묵하게 각자 맡은 부분을 끝까지 잘 해낸 승옥 님, 성훈 님, 나은 님, 호열 님에게 감사하고

코드리뷰를 통해 많은 인사이트를 주신 지훈 멘토님께도 감사드린다.

좋은 프로젝트에 좋은 팀원들이여서 좋았다.

두 달동안 정말 바쁘게 달려와서 두달이란 시간이 정말 빠르게 흘러갔다는 걸 이제서야 체감한다. 앞으로 한달동안 협업을 하게 될 회사에서는 또 어떤 일들이 있을지 무엇을 또 새롭게 배울지 기대하는 마음으로 회고를 마무리한다.

BEFORE

AFTER

select_related 쿼리셋 메소드를 사용하여 store 와 one-to-one 관계에 있는 address, category, open_status 를 미리 가져와 python 메모리에 caching 해뒀다.

prefetch_related 를 사용하여 one-to-many 관계에 있는 storeimage_set 을 미리가져와 caching 해두었다.

두 메소드의 차이점은 기준이 되는 Entry object 에서 참조하는 모델이 single object 이냐 multiple object 냐의 차이다.

거의 절반으로 쿼리가 줄었다. 지금은 store object 두개에 대해서 for 문을 돌아서 차이가 별로 안나는 것 처럼 보일 수 있지만, 나중에 10개 100 개에 대해 for 문을 돌면 차이가 매우 크게 날 것이다.

그래서 해당 요청을 mocking 하던 중 마주했던 어려움들을 어떻게 풀어갔는지 소개하려고 한다.

mock.patch 로 requests.get() 의 return_value 를 그냥 dict 로 했더니, 뒤에 오는 json() 에서 dict has no attribute json 라는 에러가 발생했다. 그래서 return_value 를 requests.Response() 로 바꿔보기로 했다.

Modifying requests.Response() object

with patch

requests.get 의 return_value 를 실제 requests.Response object 를 만들어 값을 변경해주는 방법을 사용했다.

왜냐면 views.py 코드에서 requests.get 의 attribute 인 json() 까지 mocking 해 줄 생각을 못했었기 때문이다.

어쨌든 그 생각을 하기 전에는 다음과 같은 과정을 거쳐서 문제를 해결했다.

실제로 requests.Response() 객체를 만든 뒤 ._content attribute 에 mock_content dictionary type 객체를 bytes 객체로 변환해주면 requests.Response.json() 의 값이 dictionary type 의 mock_content 가 된다.

--> 이렇게 했을 때는 쓸데없이 실제 object 를 만들어서 조작해야되기 떄문에 1. 귀찮고 2. 그만큼 메모리를 낭비하게 된다.

다음 방법을 보자.

patch decorator

실제로 requests.Response() 객체 자체를 만들지 않고, requests.get.json() 자체의 return_value 를 mocking 하는 아주 간단한 방법이 있었다.

1. mocking 할 모듈을 patch 데코레이터 인자로 넘겨줌

2. 함수의 파라미터로 데코레이터 인자로 넘겨받은 mocking 할 모듈 object를 받음 이 때 넘겨받은 인자를 print 해보면 name 이 get 인 MagicMock object 라는 것을 알 수 있다. <MagicMock name='get' id='140646286606096'>

3. MagicMock object 의 return_value 값을 response 에 할당한다. 이 때 response 를 print 해보면 name 이 get() 인 MagicMock object 로 변했다. <MagicMock name='get()' id='140369968892704'>

get 과 get() 의 차이다.

get 은 모듈 자체이고 get() 은 object 이다.

• print(mocked_request.json.return_value) 를 해보면 <MagicMock name='get.json()' id='140564181636624'>

• print(mocked_request.return_value.json.return_value 를 해보면 <MagicMock name='get().json()' id='140260556133904'>

우리가 mocking 해야 할 instance 는 다음과 같다.

response = requests.get(KAKAO_USERINFO_REQUEST_URL, headers=headers).json() 간략히 나타내면

requests.get().json() 이고, 이를 풀어보면 requests.Response().json() 이 된다.

설명이 길었지만, 핵심은

wrong way

이 방법이 아니라

  response = mocked_request
  response.json.return_value = mock_content        

right way

이 방법으로 해주어야 한다는 것이다.

  response = mocked_request.return_value
  response.json.return_value = mock_content        

이렇게 하면 성공적으로 mocking 이 된다.

• 프론트에서는 카카오 map api 로 가게가 영역 내에 있을 때 백엔드로 부터 가게 좌표와 정보를 받아와 해당 좌표에 마커를 표시한다.

• 가게가 보여지는 지도의 영역에서 벗어나면 백엔드에서 가게 정보를 더이상 보내지 말아야 한다.

• 근데 영역에서 벗어나도 계속 백엔드에서 정보가 보내져서 알고봤더니 DPI 의 문제였다.

• 프론트쪽에서 지도를 이동하는 테스트를 진행했는데, 이 때 사용됐던 제품은 맥북프로 m1 기준이였다.
• 나는 DPI 96 으로 세팅해놓고 하고 있었는데, DPI 값을 바꾸면서 테스트해보니 테스트 모니터 해상도 기준 DPI 는 200 이였다.
• 그래서 DPI 를 200 으로 놓고하니 아주 정확하게 지도영역 바깥으로 벗어나는 순간 가게 정보를 받아오지 않았다.

근데 문제는 DPI 값이 기종마다 해상도마다 다를것이기 때문에 이 값을 프론트에서 받아오는 방법을 찾아야한다.

아직 못찾았다 ..

• Enum class 에 인스턴스들을 선언한다.
• 처음에는 Enum.__memebers__ 로 Enum class 의 변수 명들을 가져와서, 입력되는 데이터가 그 중에 없으면 에러를 리턴하려고 했으나
• input 값은 모두 베이커리, 카페 이런 한글로 들어오기 때문에, 한글을 변수로 선언할 수는 없었다.
• 그래서 Enum class 를 iterate 하면서 각 변수의 value 들을 담은 list 를 만드는ExtendedEnum 클래스를 생성했다. 해당 클래스는 Enum 클래스 상속을 받았다.

validation

다음과 같이 category_name 이 ExtendedEnum 클래스를 상속받아 만든 CategorySet 에 없으면 transaction.set_rollback(True) 를 call 해서 모든 db 수정 값을 초기화 시킨다.

2. 성공하면 해당 API 요청을 save 하기

3. 공유하기

스크럼 작업 스케줄 관리 공간인 Trello 에 프론트 팀원들이 키값을 알 수 있도록 공유했다.

Only Backend side Without Frontend

앞서 말한 것 처럼 이 코드는 프론트엔드 없이 백엔드에서 혼자 모든걸 다 처리하는 코드이다.

import jwt
import requests

from django.shortcuts import redirect
from django.views     import View
from django.http      import JsonResponse

from .models import User

from my_settings import SECRET_KEY, HASHING_ALGORITHM, KAKAO_RESTAPI_KEY


KAKAO_REDIRECT_URL         = 'http://localhost:8000/user/login/kakao/oauth'
KAKAO_TOKEN_REQUEST_URL    = 'https://kauth.kakao.com/oauth/token'
KAKAO_USERINFO_REQUEST_URL = 'https://kapi.kakao.com/v2/user/me'


class KakaoLoginView(View):
    def get(self, request):
        client_id    = KAKAO_RESTAPI_KEY
        redirect_url = KAKAO_REDIRECT_URL

        return redirect('https://kauth.kakao.com/oauth/authorize?client_id={}&redirect_uri={}&response_type=code'.format(client_id, redirect_url))


class KakaoLoginCallbackView(View):
    def get(self, request):
        try:
            code = request.GET.get('code')

            data = {
                    'grant_type'  : 'authorization_code',
                    'client_id'   : KAKAO_RESTAPI_KEY,
                    'redirect_uri': KAKAO_REDIRECT_URL,
                    'code'        : code
                }

            token_response = requests.post(KAKAO_TOKEN_REQUEST_URL, data=data).json()

            access_token  = token_response.get('access_token')
            refresh_token = token_response.get('refresh_token')
            error         = token_response.get('error')

            if error:
                return JsonResponse({'message': 'INVAILD_REQUEST, {}'.format(error)}, status=400)

            headers = {'Authorization': 'Bearer {}'.format(access_token)}

            response = requests.get(KAKAO_USERINFO_REQUEST_URL, headers=headers).json()

            kakao_user_id       = response.get('id')

            if kakao_user_id:
                user, _   = User.objects.get_or_create(kakao_id=kakao_user_id)
                jwt_token = jwt.encode({'user_id': user.id}, SECRET_KEY, algorithm=HASHING_ALGORITHM)

                return JsonResponse({'token' : jwt_token}, status=200)
            else:
                return JsonResponse({'message': 'INVALID_ACCESS_TOKEN'}, status=400)

        except KeyError:
            return JsonResponse({'message': 'KEY_ERROR'}, status=400)

1. How to get Authorization Code (인가코드)

• RESTAPI KEY 로 인가코드부터 받아야 한다.

카카오 API 명세의 인가 코드 받기 부분을 참조해보자.

postman 을 이용해 GET 요청을 통해 파라미터로 값을 넘겨주었다.

--> 성공적으로 인가코드를 받을 수 있었다.

2. How to get access_token

• 받은 인가코드로 access_token 을 받아야 한다.

카카오 API 명세의 토큰 받기 부분을 보자.

postman 을 이용해 POST 요청으로 파라미터로 값을 넘겨주었다.

--> 성공적으로 access_token 을 받을 수 있었다.

3. How to get user information

• 받은 access_token 으로 카카오톡에 가입 된 유저 정보를 받아올 수 있다.

CSRF 방어

나중에 자세히 공부 할 예정이다.

결론은 css 1인치는 무조건 96px 이다.

https://www.pixelto.net/px-to-cm-converter

https://blog.hyungsub.com/entry/DPI-%EC%8A%A4%ED%84%B0%EB%94%94-V1

Models.py 안에 함수를 정의하면 views.py 에서 할 일을 줄일 수 있다.

예를들어 스타벅스 사이즈마다 가격 다를 때 view 에서 처리해주면 귀찮으니까, Model 자체에서 사이즈 별로 연산하는 메소드를 클래스 안에 정의해놓고, <Model object>.method() 로 쓰면 됨.

소셜 로그인 DB 관리

통합회원관리

어떤 유저가 google, fb, kakao 로 가입했을 때 그 유저가 한 유저인 걸 알고싶을 땐, 통합회원관리를 해야한다.

그래서 먼저 로그인을 한 상태에서 google, fb, kakao 를 각각 인증하면 나중에 로그인 할 때 해당 소셜로그인으로 로그인 할 수 있도록 db 에 해당 필드 id 를 추가한다.

통합회원관리 x

통합회원관리를 안하고 동일한 유저가 google, fb, kakao 로 가입한 걸 서로 다른 세명의 유저로 인식할것이라면, 앞서 설명했던 것들을 생각할 필요 없다.

그냥 위 코드처럼 모든 field 를 null=True 해서 저장하면 된다. 그런다음 kakao 로 로그인을 하면, kakao_id 필드만 체크해서 로그인시키면 된다.

Curl syntax -> Python syntax

API 문서를 읽다보면 다음과 같이 종종 request 방법에 대한 예제가 curl 문으로 적혀있는경우가 많다.

그럴 땐 https://curl.trillworks.com/ 로 가서 변환해보면 된다.

물론 100 프로 동작한다는 보장은 없기 때문에, 에러가 날 경우 오탈자가 있는지 체크해봐야한다.