presentation
presentation

2020년 1월 둘째 주

January 09, 2020
report

System Design: Tinder as a microservice architecture, Gaurav Sen, 2018.7.2

Tinder Architecture

  1. Store Profiles (Images) - 5 images per user
  2. Recommend matches (Active 유저의 수)
  3. note matches
  4. Direct Messaging

Image를 저장할 때의 관건은 File vs Blob(DB)

features you get when you use DB(Storing Images as Blob)

  1. Mutability - not really need Mutability. why not just save separate file
  2. Transaction guarantees - there’s no need to do some atomic operation on images
  3. indexes(Improve Search) - because we don’t need to search data on Blob (it’s just 0s and 1s), it’s not also needed
  4. Access Control

good things when you use File System

  1. Cheaper
  2. Faster
  3. Content Delivery network

How to implement Updating Profiles

on traditional Monolitic system, you can have user account and password(or token) on request and update profile and send success response. that’s enough for now. but what if we have another feature on tomorrow and need authentication for that feature too.

good way is to have a Gateway Service and so decouple system and no need to duplicate authentication logic.

How to send Direct Messages

Protocol

on Client-Server communication protocol, HTTP? it is inefficient. peer-peer protocol would be better. XMPP is what you want to use.

on Websocket or TCP

Who’s gonna maintain these connections

It can be served by Gateway Service. but decouple as much as possible. so make Sessions Service.

Noting Recommendation

Profile Service could handle it or Matcher service would handle it.

How to Recommend Matching

there are ages, locations, etc on profile DB. which DB would be good.

  1. Cassandra/Dynamo
  2. sharding -> horizontal partitioning (spliting data by location or ages, and searching)

Optional Chaining for JavaScript

Why You’ll Like JavaScript Optional Chaining, Dmitri Pavlutin, 2019.8.21

When you need to access a property in super nested object, optional chaining can help you avoid long, boring check logic to check if there’s the property.

let name;
if (movie.director != null) {
  name = movie.director.name;
}

can be like below

let name = movie.director?.name;

By using nullish coalescing, you can get default value.

const noValue = undefined;
const value = 'Hello';

noValue ?? 'Nothing'; // => 'Nothing'
value   ?? 'Nothing'; // => 'Hello'

HTTP/2 RFC를 응용한 HTTP/2 Checker의 구현

RFC 명세에 따라 서버의 HTTP/2를 테스트하는 방법을 파이썬으로 구현하는 방법에 대해 서술

What’s going on with the OAuth 2.0 Implicit flow?

Q: 유저 인증한 시점에 redirecturi로 accesstoken을 함께 던져주는 건 왜 안 될까?

A: redirection이 탈취될 경우 키 또한 바로 탈취될 수 있다.

Q: 그럼 authorizationcode를 가지고 /token에 post를 날려서 accesstoken을 얻는 건 안 위험한가?

A: 보안에 100%는 없지만 redirection 도중 탈취되는 것처럼 비교적 쉬운 보안상 문제는 막을 수 있다.

네트워크상의 오고 가는 uri를 로깅해서 access_token을 얻는다거나, 요즘은 브라우저의 extension에게도 권한을 주기 때문에 URL 들을 쉽게 볼 수 있게 된다.

구글 브라우저는 브라우저 히스토리를 싱크하기 떄문에 그 과정에서도 URL은 구글로 가는 도중 다른 곳에서 가져갈 수도 있다.

이런 다양한 경로의 URI 탈취에 비하면 POST Request는 위협의 경우가 다르다.

10년 전 쯤에는 implicit flow를 통해 모바일 앱(public clients - which secret can’t be kept securely)의 Oauth를 구현하는 게 자연스러웠다.

그러다가 PKCE가 나타나서 이를 보완해줬다. (PKCE - makes up a new secret on the fly every time, hashes it and then does the regular OAuth flow)

그렇다면 PKCE는 얼마나 안전한가?

PKCE는 Redirect Step을 보호할 뿐이다. 결국엔 access_token을 가지고 뭔가를 해야하며 그 부분은 기존과 동일하다.

그렇다면 이런 다른 부분에서 오는 구멍을 보안할 방법은 무엇인가?

  • 어떤 코드가 돌고 있는지 확인하고
  • 임의의 모르는 자바스크립트를 CDN에서 로드하지 말고
  • HTTPS를 사용하고(Let’s encrypt)
  • long lived HSTS policy를 설정하고
  • good content security policy

OWASP 참고하세요.