객체를 지향하는 것의 의미를 좀 더 확실히 알게 되니까, 보이지 않았던 것들이 보이기 시작한다. 아는 만큼 보인다고, 좀 더 많은 것들을 다시 봐야겠다는 생각이 든다.
친구가 회사 막내라서 카페에 가면 메뉴를 조사해야 된다고 한다. 그런데 마땅한 어플을 찾기 힘들어서 좀 만들어달라고 해서, 어제 할 것도 없고 해서 간단하게 웹으로 만들었다.
Quasar.js를 활용했는데, 꽤 괜찮은 것 같다.
메뉴 사이트는 링크에서 확인할 수 있다. 예전에는 ElementUI를 활용했었는데, 이제 Quasar로 넘어갈 것 같다.
객체지향에 대한 책을 조금 더 읽고 난 뒤, 그룹웨어를 만들어볼까 한다. 어느 회사를 가든 사내 시스템이 존재할테니 그룹웨어를 만들어 보면서 객체지향을 적용 해보는게 좋은 공부가 될 거라고 생각한다. 언어는 Golang
으로 갈 예정이다.
Rust
분명히 Rust
도 미래에 뜰 것 같은 언어라는 느낌이 든다. 물론 이미 지금도 꽤 핫한 감자임이 분명하다. 게다가 보니까 Mozilla에서 만들었더라. Wasm언어로 많이 사용될 것 같은 느낌이 든다. 조만간 공부 시작해야 될 것 같다.
회사일 얘기가 빠질 수 없다. 최근에 SSO연동 관련 작업을 진행했는데, 통합로그인 방식과 개별로그인 방식 두 가지 방식이 있었고, 우리 서비스는 통합로그인 방식이라 통합로그인 방식으로 가이드 문서를 받아 살펴보았다.
그런데, 가이드문서에 나온 사용자 정보를 주고 받는 과정이 조금(많이) 어이가 없었다. 과정은 이렇다.
대략 위의 과정으로 나와있었는데... 맨 처음에 봤을때 도저히 이해가 안갔던 내용이 바로 4 ~ 5 과정이었다.
SSO 서버에서 우리 서버로 사용자 정보를 보내준다는 것 같은데, 그러면 받았다 치면, 그 뒤로 넘어오는 사용자를 넘겨줬던 사용자 정보와 어떻게 매칭을 시키라는 건지? (사용자를 식별할만한 식별 값이 전혀 없는데?)
사용자는 그럼 그 뒤에 어디로 넘어온다는 건지? redirect_url으로 넘어온다는 건가?
설마 사용자가 redirect_url로 POST와 함께 넘어온다는 건가? 근데 리다이렉트는 POST가 당연히 안되는데?
이 의문 때문에 팀끼리 상의해봤고, 개발하는 다른 친구한테도 물어봤었는데 도저히 문제의 답이 나오질 않았다. 설마 사용자 정보를 POST로 묶어서 보내주는건 아닐테고 말이다.
그래서 가이드 문서를 본 다음날, 직접 전화해서 물어봤는데... 사용자가 로그인하면 그 정보를 폼에 묶어서 스크립트로 Submit을 작동시키게 한다고 하더라.. 그러니까 설마했던 방식대로 사용을 한다는 뜻이었다.
솔직히 너무 어이가 없었다. 아니 그러면 그 정보를 어떻게 믿는다는 말인가?
일단 답변을 듣고 구현은 했다. 구현을 하고 난 뒤, 문의 메일을 보냈다. 우린 이런 과정을 통해서 도저히 로그인 처리를 할 수 없다고.
그렇게 몇 번 메일을 주고 받고 통화를 한 결과, 실제로 OAuth 방식과 비슷하게 작동하는 모듈을 이미 SSO 서비스 업체에서 구현을 했고, 개별로그인 서비스에서는 이 방식을 사용한다고 했다. 그런데 통합로그인 방식에서 굳이 저런 POST방식을 사용한 이유는, SSO 서비스를 사용해야할 여러 다른 우리 같은 서비스 업체측에서 사용 방법이 어렵다(?)는 항의가 와서 그냥 저런 것도 만들었다고 한다😨
세상에나... 나중에 어찌 감당하려고; 솔직히 SSO 서비스 구현하신 분도 많이 황당하셨을 것이다. 그런데 어쩌겠는가;
아무튼... 상식 밖의 일들이 발생하고 있다는게 조금 놀라웠다. 최소한 기본은 지켜야하지 않을까?
어쨌든 오브젝트는 짱짱책이다. 그리고 좀 더 바빠졌으면 좋겠다😅