게이트 웨이를 거쳐서 Google OAuth 인증이 되지 않는다. 대신, 직접 인증 서비스 포트를 호출하면 인증 및 회원 가입이 성공한다.
@Override
protected void configure(HttpSecurity http) throws Exception {
JwtAuthenticationFilter authenticationFilter=new JwtAuthenticationFilter(authenticationManagerBean(),facade);
authenticationFilter.setFilterProcessesUrl("/auth/login");
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.addFilter(corsFilter)
.formLogin().disable()
.httpBasic().disable()
.authorizeRequests().anyRequest().permitAll()
.and()
.csrf().disable();
http.logout()
.logoutUrl("/logout")
.deleteCookies("refresh-token");
http.oauth2Login()
.userInfoEndpoint()
.userService(oAuth2Service)
.and()
.successHandler(oAuth2Service::onAuthenticationSuccess);
http.addFilter(authenticationFilter);
}
URL1은 게이트 웨이를 경유할 때이며, URL2는 게이트웨이를 경유하지 않고 직접 인증을 시도할 때를 나타낸다.
http://localhost:8062/writer/oauth2/authorization/google
gatewayserver_1 | 2023-01-13 03:03:15.987 DEBUG [gateway-server,31f7af952b5c8360,31f7af952b5c8360,true] 1 --- [or-http-epoll-7] c.d.a.g.filter.TrackingFilter : diary-cor
relation-id generated in tracking filter: 99f7b2fc-cca7-44a8-a50a-8a4dd5e3a2c4.
gatewayserver_1 | 2023-01-13 03:03:15.998 DEBUG [gateway-server,31f7af952b5c8360,31f7af952b5c8360,true] 1 --- [or-http-epoll-7] c.d.a.g.filter.ResponseFilter : adding co
rrelation id to the outbound headers.31f7af952b5c8360
gatewayserver_1 | 2023-01-13 03:03:15.998 DEBUG [gateway-server,31f7af952b5c8360,31f7af952b5c8360,true] 1 --- [or-http-epoll-7] c.d.a.g.filter.ResponseFilter : complete
outgoing request for http://localhost:8062/oauth2/authorization/google.
게이트웨이 서버에서 리퀘스트 필터와 리스폰스 필터를 모두 거치고 있다.
하지만 인증 서비스에서 작성한 OAuth 로직을 거친 흔적은 남아있지 않다.
http://localhost:8082/oauth2/authorization/google
writerservice_1 | 2023-01-13 02:59:11.980 INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] c.d.a.w.a.s.security.OAuth2Service : load user
by oauth :null
writerservice_1 | Hibernate: select writer0_.writer_id as writer_i1_1_, writer0_.created_at as created_2_1_, writer0_.updated_at as updated_3_1_, writer0_.email as email4_1_, write
r0_.name as name5_1_, writer0_.password as password6_1_, writer0_.provider as provider7_1_, writer0_.provider_id as provider8_1_ from writer writer0_ where writer0_.name=?
writerservice_1 | 2023-01-13 02:59:12.272 INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] c.d.a.w.a.s.security.OAuth2Service : after aut
hentication success : null
writerservice_1 | 2023-01-13 02:59:12.272 INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] a.w.a.s.s.JWTTokenWriterIntoResponseBody : writing j
wt token into response body ...
writerservice_1 | 2023-01-13 02:59:12.275 INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] .d.a.w.a.s.s.r.i.RefreshTokenServiceImpl : updating
refresh token in refresh token service : null
writerservice_1 | Hibernate: select writer0_.writer_id as writer_i1_1_0_, writer0_.created_at as created_2_1_0_, writer0_.updated_at as updated_3_1_0_, writer0_.email as email4_1_0
_, writer0_.name as name5_1_0_, writer0_.password as password6_1_0_, writer0_.provider as provider7_1_0_, writer0_.provider_id as provider8_1_0_ from writer writer0_ where writer0_.wri
ter_id=?
게이트웨이 서버를 거치지 않기 때문에 상관관계 id를 발급해주지 않는다. 로그에 null
로 찍히는 값들이 있는데 바로 게이트웨이에서 지급하는 상관 관계 id이다.
그것을 제외하곤, 인증 로직이 제대로 작동한다.
accessToken이 발급된다. 그리고 회원 가입 로직도 작성해놨기 때문에 db에도 잘 저장된다.
안될 때, 상관 관계 id는 발급해준다. 그래서 한 번 집킨에다 질의를 해봤다.
302는 리다이렉트이며, Client Address는 안될 때 화면의 private address와 동일하다.
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'
(도커 컨테이너 id) 를 활용해서
private address를 확인하니 위 집킨 Client address와 동일한 주소다.
흠... 해결은 아직 못했다. 그래도 생각나는 해결책은 다음과 같다.
1.의 경우, 현재 프로젝트를 많이 뜯어 고쳐야 해서 손이 많이 간다. 그리고 게이트웨이가 할 일이 많아지는 것 같아서 응집성에서도 별로인 것 같고, 게이트웨이의 무상태성을 해친다.
2.가 그나마 현실적인 것 같은데... 관련 지식이 없다. 쩝