•
사용자가 접속 권한을 갖고 있다는 것의 판단은 Session이 열려 있는지에 따라 판단한다.
•
RESTful API는 Stateless한 특성을 갖고 있고 이는 곧 개개인 client의 connection이 열려 있는지 아닌지는 관심 없다는 얘기이다. (REST에서는 Session의 검증을 하지 않는다는 얘기이다.) 즉, 누가 디비 접근 권한을 갖고 있는지에 대해서는 관심도 없고, 따라서 이런 API들은 그저 Http Request를 보낼 수 있는 Endpoint를 제공하기만 할 뿐이다. 그러므로 REST에서는 Session이 아닌 Token이라는 것을 이용한다.
•
Token은 특정 알고리즘에 의해 서버에서 생성될 뿐 아니라 서버만 아는 Private key이기 때문에 Token이 조작 되기는 어렵다. (일반적으로 굉장히 긴 String으로 준다.) 이런 토큰은 다른 곳이 아닌 Local Device Storage에 저장되어 사용자 검증을 하게 되는데, 따라서 검증을 위해 어플이 시작될 때 기기에서 Token 정보를 읽어 가져간다.
•
사용자는 고유의 Token을 읽어 서버로 Http Request를 보내게 된다. 서버는 이를 검증한 뒤 에러 코드를 Response하게 된다. 결과적으로 서버에 작성한 알고리즘 대로 직접 만들어진 Token을 갖고 있고 그것이 유효한 Token이라면 로그인이 가능해지는 것이다.
•
Dart의 ..operation은 현재 return type으로 return하는 것이 아닌 previous의 return type으로 return한다.
•
예를 들어, Matrix4.rotationZ().translate()은 void로 return하게 되므로 transform이 받을 수 있는 Matrix4로 return하도록 만들어야 한다. 이 때, ..operator를 통해서 Matrix4.rotationZ..translate()로 작성하여 해결 할 수 있다.
•
다른 방법으로는 final variable = Matrix4.rotationZ(); 후에 variable.translate();도 가능하다. (translate이 새로운 Object를 내놓는 함수가 아닌 결과를 cumulative assign을 하기 때문이다.)
•
Authentication에는 Generic Error Handling이 필요하다. 일반적으로 통신 에러가 아니기 때문에 try catch로 잘 잡히지 않는다. 이를 고려하여 manual하게 처리해야 한다. 따라서 try catch구문을 이용할 때, 직접 정의한 Exception class에 대해서도 on 키워드를 통해 catch 가능하게 해야하고, Custom Error외에도 Generic Error에 대해서 catch 해야하므로 catch 구문을 추가로 작성한다.
•
try{} on <class> catch(error) {} catch(error) {}와 같이 말이다.
•
?? Operator는 null인지 확인하는 연산자이다.
•
logout은 token, token의 expireDate, userId를 모두 null로 하고 화면 새로 고침하는 로직과 같다.
•
자동 로그인은 device내에 token을 저장하는 것과 같은 로직이다. token이 살아 있는 동안은 자동 로그인 지원하게 되는 것인데, shared_preferences이용하여 구현한다. 저장 타이밍은 login 했을 때 저장할 수 있도록 한다. (shared_preferences도 Future이다.)
•
SharedPreferences.getInstance().setString()을 통해서 저장하고 .getString()을 통해서 읽어 온다.
•
logout 후에는 로컬 data clear해줘야 한다.
•
Root Widget에 붙어 있는 Provider가 여럿이고 그 Provider간의 정보를 주고 받아야한다면 이미 Root라 더 위에 Provider를 둘수는 없다. 따라서 ProxyProvider를 사용해야 한다. ProxyProvider가 MultiProvider의 첫번째 인덱스로 올 수는 없다.
•
import 'dart:async'를 통해서 Timer를 쓸 수 있음