🔥 TIL - Day 21

📌 認証...追加...

1つ目のプロジェクトでは時間が長くないため、認証を考慮せず、目標機能の実現だけを重視しています.2つ目のプロジェクトが開始され、認証ロジックが実装され、既存の機能に認証を追加する必要があります.
今日の目標は認証に関する話題は以下の通りです.
JWT 토큰方式の認証を使用しており、トークンはクッキーに入れて管理されている状態です.したがって、要求に対するサーバの権限を検証するには、Cookieを確認する必要があります.
パラメータはクッキーのtokenに渡されます.伝達されるトークンのペイロード部分が必要であるため、decodeが実行され、ペイロードのuser_idがuser_idであるかどうかを検証することによってトークンが検証される.トークン検証ロジックは後で再考されます.(仮!!)

# 토큰 검증 메서드
def verify_token(mytoken):
    # 인코딩된 토큰의 payload 부분 디코딩
    token = jwt.decode(mytoken, jwt_secret, algorithms=['HS256'])
    # 디코딩된 payload의 user_id가 users DB에 있는지 확인
    user = db.users.find_one({'user_id': token['user_id']}, {'_id': False})

    return user

要求事項を整理する.

現在認証されているクライアントは、自分が追加したお気に入りしか表示できません.

を削除しても、お気に入りを追加した人だけができます.

のお気に入りを追加すれば、どのユーザーが作ったのか知るべきです.

お気に入り情報を管理するDB(컬렉션)がuser_idを持っていれば、すべてが解決されます.今思えば当たり前だが、時間がかかった.
論理を一つ一つ検証しましょう.
1.自分が追加したお気に入りしか見えません.즐겨찾기 조회 APIが呼び出されると、トークンを検証するために、Cookieは最終的にuser_idを取り出す.このようにして出されたuser_idを条件として즐겨찾기 컬렉션に問い合わせる.즐겨찾기 컬렉션は登録時にuser_idを持っているので、自分が追加したお気に入りを検索するしかありません.
2.お気に入りを削除できるのは、お気に入りを追加したクライアントのみです.즐겨찾기 삭제 APIが呼び出されると、トークン検証により得られたuser_idと、削除するお気に入りとして登録されている법안의 IDとを条件として、delete_oneの方法でお気に入りを削除する.
3.お気に入りが追加されたクライアントを知る必要があります.즐겨찾기 추가 APIが呼び出されると、トークン検証によって得られたuser_idが즐겨찾기 컬렉션のDocumentに追加される.
これはあまり難しくない問題ですが、熟考するのではなく、符号化から、長い時間がかかりました.論理を実現するには、まず大きな図を描いてから始めなければならない.

📌 mongoDB update $push, $unset

これは、お気に入りAPIに認証を追加実施した際に知ったmongoDB関連技術である.
お気に入りを追加する場合は、登録した법안의 IDをuser collectionに追加する必要があるので、実現したいときに実現しにくいところがあります.

{
  ...,
  bookmarks: [
    bookmark_id1, bookmark_id2
  ],
  ...
}

上記形式でDocumentを構成する場合、bookmarsの値はリスト([])形式であり、リストに値を追加する場合はどうすればよいか.
私が見つけた答えは$pushです.bookmarksリストのlaw_idとappendと同じです.

db.users.update (
	{'조건key':'조건value'},
	{'$push':{'bookmarks':law_id}}
)

2つ目のケースは逆で、bookmarksリストから値を削除します.
答えは$unsetです.bookmarksリストからlaw_idが削除されたのと同じです.

db.users.update(
	{'조건key':'조건value'},
	{'$unset': {'bookmark_id':law_id}}
)

mongoDBについてはまだよく知られていないので、Documentのデザインが正しいかどうかは分かりません.しかし、NoSQLであり、まだ開発段階なので随時変更可能です.