인증...아..애자일

 

우리 내 서버는 기본적으로 인증서버에서 발급받은 JWT로 접근 통제 하도록 설계 했다.

인증(JWT) 없이 즉, 로그인 없이 사용해야 하는 CASE가 생겼다. (생각지도 못했다.)

 

애초에 이미 고려 했다면 당황하지 않았을것이다.

 

근데... 생각해 보면  처음부터 모든 것을 다 고려하고 나서 하나식 쌓아 올라가는 과정으로 프로젝트를 진행하는 곳은 경험에 비추어 봤을때 거의 없을듯 하다. 그래서 다들..애자일..애자일 하는구만..

 

로그인 없이 사용 할 수 있다는 생각 자체를 못했던 근본적이유는 일단 나한테 있다.

내 머리속은 지금까지 B2B 비지니스 바탕으로 한계가 명확히 그어져 있었다. 그랬기에 생각지도 못했지.ㅠ

 

기본적으로 코드상에서도.. 유연하게 처리할 수 있도록... 확장 가능하도록 설계를 한다지만.. 아예 전혀 다른 스펙의 요구사항은...

저장 데이터 하나 추가하는것이 아니니 ㅡㅡㅎ

 

머리속은 띠용!! 당황스

 

의식의 흐름!!

 

현재 상황 판단)

프론트나 백에서 이미 모든것을 공통으로 사용하도록 코드를 만들었다. "인증정보"가 있고 없고를 갈라치기를 하기는 애매했다.

 

인증자체의 경우는 인그레스를 통해 앞단으로 위임했고

백 서비스 자체는 JWT를 분해해서 기본적인 사용자 정보를 취하는 형태로 설계해서 모든 API 부분에 AOP로 적용했다.

 

프론트(vue)의 경우도 인증서버에서 받은 JWT를 공통으로 처리해서 API를 요청하게 되어 있다.

 

아... 생각보다 작업이 커지겠는데....아... 커지는데....

단순하게 갈리치기로 빽을 가르면 당연히 프론트도 갈라야 하는데..

 

목표!!!)) 기존 코드를 건드리지 않고... 할 방법을 모색해야 한다.

 

아아아아....하다가 Mock가 생각이 났다......하느님 부처님!!!!감사스 

가짜의 JWT를 만들어서..던지면 되는구만!!

프론트에서 사용자의 객체(상태)가 없는경우 인증서버에게 가짜의 JWT를 요청한다... 불행 중 다행인것은 다행이 조회용도로만.. 휴휴휴휴

 

가짜라고는 하지만 우리가 만든 서명은 진짜이기에 때문에 추가 적인 접근제어를 해야 한다.

저것을 들고 다른 api를 호출하면 인증자체는 통과하기 때문에 role을 통해서 2차적인 통제를 진행한다.!

 

쉽게 풀려서 다행이다.ㅠ