[김선호] 2단계 - 리다이렉트 필터 & OAuth2 인증 필터 리뷰 요청드립니다 🚀 #21

haero77 · 2025-03-09T04:57:21Z

진영님 안녕하세요, 3주차 미션 2단계 리뷰 요청드립니다.

이번 미션에서 중점적으로 신경을 쓴 부분은 다음과 같습니다.

OAuth2가 프로토콜임을 이해하고, OAuth2 플랫폼별 세부 구현체를 제거 & Client 통합 (리뷰 코멘트 반영)
provider, registration가 서로 다른 개념임을 이해하고, 프로덕션 코드에 이를 반영하기
OAuth2LoginAuthenticationProvider, OAuth2AuthorizationCodeAuthenticationProvider 차이를 이해하고 객체간 책임 구분하기

특히 지난 1단계 미션에서 OAuth2는 프로토콜이고, 플랫폼별로 구현체를 따로 둘 필요는 없다는 중요한 개념을 짚어주시고, OAuth2ClientProperties에서 Map을 활용해 환경변수를 추상화된 형태로 주입받는 방식을 추천해주신 덕분에 '이런 구조라면 플랫폼이 추가될 때마다 유지보수 비용이 꽤 나오겠는데...' 라며 고심하던 부분이 말끔히 해결되는 경험을 할 수 있었습니다. 감사합니다 🙇‍♂️

이번 2단계 미션을 본격적으로 진행하기 전 Spring Security 패키지 구조를 보며 패키지 구조를 다시 잡는 사전 리팩토링을 진행했으며(d3ef98d), 이에 따른 리뷰 요청 범위는 다음과 같습니다.

리뷰 요청 범위

OAuth2 인증 필터 부분이 이해가 잘 되지 않아 Security 코드와 샘플 코드를 참고하며 시퀀스 다이어그램으로 정리하며 공부하느라 시간은 조금 오래 걸렸지만, 그래도 덕분에 OAuth2에 대해 어느 정도 개념이 잡혀가는 듯 해서 기쁘네요. 무엇보다 처음 시큐리티 코드를 마주하며 생긴 두려움이 점차 해소되는 것 같아 점점 자신감도 붙는 것 같습니다 ㅎㅎ

궁금한 점은 개별 코멘트로 남겨두겠습니다. 그럼 리뷰 잘 부탁드립니다..!

- spring security 컨텍스트를 벗어나는 oauth2 프로토콜 그 자체와 매핑되는 클래스이므로 root.oauth2 패키지로 위치 변경

- src.security.oauth2.core/web/registration/userinfo - src.oauth2

…tionRepository 구현

- generates OAuth2AuthorizationRequest contains Redirect URI

- generates ClientRegistration using OAuth2ClientProperties

- save authorizationRequest to HTTP Session

- Lazy initialization 사용

- OAuth2ClientProperties를 직접 사용하지 않고 ClientRegistration을 사용하도록 변경

- OAuth2 Client를 직접 의존하지 않도록 변경 - OAuth2AuthorizationCodeAuthenticationProvider를 통해 AccessToken을 조회하도록 변경

haero77 · 2025-03-09T05:55:43Z

src/main/java/nextstep/security/oauth2/client/registration/ClientRegistrationRepository.java

+public interface ClientRegistrationRepository {
+
+    ClientRegistration findByRegistrationId(String registrationId);
+}


Q. Security에서 왜 어떤 의존성은 주입받고, 어떤 의존성은 자체적으로 생성하는지에 대한 의문

ClientRegistrationRepository를 구현하다가 문득 이런 생각이 들더군요.

Security 코드를 보면 ClientRegistrationRepository는 생성자를 통해 의존성을 주입받는데, 왜 어떤 필드는 생성자에서 직접 인스턴스를 생성할까? 또, 왜 어떤 필드는 생성자가 아닌 인스턴스 필드 선언 시 인스턴스를 생성하고 있을까?

스스로도 의존성을 주입 받을지, 생성자에서 인스턴스를 생성할지, 필드 선언 시에 인스턴스를 생성할지 평소 고민하고 있던 부분이기 때문에 이참에 확실히 기준점을 잡아봐야겠다는 생각이 들었습니다. 그리고 자체적으로 삼은 기준은 다음과 같습니다.

생성자를 통한 의존성 주입

해당 의존성이 이미 스프링 빈으로 관리되어 별도의 인스턴스 생성이 불필요한 경우

다형성으로 인해 런타임에 의존성을 주입받아야하는 경우

생성자에서 인스턴스 생성

인스턴스를 생성해야하는 대상의 생성자를 호출할 때, 의존성을 주입해야하고, 해당 의존성을 현재 생성자에서 주입받고 있는 경우 (e.g. OAuth2AuthorizationRequestRedirectFilter에서 authorizationRequestResolver 생성 시 clientRegistrationRepository 주입)

필드 선언시 인스턴스 생성

위 경우가 아닌 경우 또는 강결합을 통해 객체간 연관성을 강하게 부여하고 싶은 경우

Security도 비슷한 기준으로 의존성을 관리한 것 같은데 혹시 제가 생각하는 방향이 맞을지, 또 위에 대한 리뷰어님의 의견은 어떤지 궁금합니다..!

Spring Security에서 어떤 의존성은 생성자를 통해 주입받고, 어떤 의존성은 직접 생성하는지에 대한 고민은 좋은 궁금증이라고 생각합니다. 그럼 저도 제 생각을 한번 정리해보겠습니다.

Security 내부에서 ClientRegistrationRepository 같은 객체는 생성자를 통해 의존성을 주입받는 방식으로 구현되어있습니다. 이는 이미 스프링 컨테이너에서 관리되는 빈이므로 별도로 인스턴스를 생성할 필요가 없기 때문입니다. 또한, 다형성이 필요한 경우 런타임에 원하는 구현체를 주입받아 동작해야 하기 때문에 생성자 주입을 통해 확장성을 확보하는 것이라고 볼 수 있습니다.

반면, OAuth2AuthorizationRequestRedirectFilter 내부에서 authorizationRequestResolver를 직접 생성하는 경우를 보면, 이 객체는 특정 로직 내에서만 사용되며 외부에서 관리할 필요가 없는 단순한 객체이기 때문에 생성자에서 직접 인스턴스를 생성하는 방식을 선택한 것 같습니다.

그리고 필드 선언 시 인스턴스를 생성하는 경우 있는데, 이 방식은 객체 간 강한 연관성이 필요한 경우 또는 불필요한 주입 과정을 생략하고 객체를 빠르게 초기화하는 것이 더 적절한 경우 사용되는 것 같습니다.

이 것은 저의 관점이니 참고만 해주셔도 좋을 것 같아요.

haero77 · 2025-03-09T07:05:44Z

...ava/nextstep/security/oauth2/client/web/HttpSessionOAuth2AuthorizationRequestRepository.java

+import org.springframework.lang.Nullable;
+import org.springframework.util.Assert;
+
+public class HttpSessionOAuth2AuthorizationRequestRepository implements AuthorizationRequestRepository {


AuthorizationRequestRepository의 주 목적이 state 값을 검증하는 것으로 알고 있는데, 아직 명확하게 state에 대한 필요성을 느끼지 못해서 우선 이 부분은 생략하고 구현했습니다.

state를 사용하는 주 목적이 CSRF 공격 방어 정도로 이해하고 있는데, 혹시 state값이 CSRF 공격 방어 외에 다른 용도로 사용되는 곳이 있을지, 또 필수적으로 구현하는게 맞을지 리뷰어님 의견이 궁금합니다..!

state를 통해 클라이언트가 앞서 보낸 요청에 대한 응답인지를 판단하게 됩니다.
만약 피해자가 피싱사이트에 노출이 되어 로그인을 진행하였을 때 state값이 없는 경우 code 가로채기나 조작을 하게 되는 경우 의도하지 않은 상황을 맞이하게 됩니다.

boorownie

안녕하세요 선호님!
피드백이 조금 늦었네요ㅠ
오리 리뷰어 님이 바쁘셔서 제가 대타로 들어왔습니다 :)
우선 앞선 PR에 연속적으로 코드리뷰를 하기 보다는 현 코드와 시점 기준으로 생각나는 점 몇 자 남겨두었으니 확인해보세요~

내용에도 기록했지만 구현에 많은 시간이 걸릴 것 같은 경우에는 글로라도 계획을 미리 공유해주시면 감사하겠습니다!

boorownie · 2025-03-11T17:01:35Z

src/main/java/nextstep/oauth2/OAuth2ClientPropertiesMapper.java

+
+public class OAuth2ClientPropertiesMapper {
+
+    private final OAuth2ClientProperties properties;


특정 서드파티에 종속적이지 않게 구현하고 이를 위해 설정값을 관리하는 매퍼 구현 👍

boorownie · 2025-03-11T17:10:07Z

src/main/java/nextstep/app/SecurityConfig.java

+                        new OAuth2AuthorizationRequestRedirectFilter(clientRegistrationRepository),
+                        new OAuth2LoginAuthenticationFilter(oAuth2UserService, clientRegistrationRepository),


현재는 clientRegistrationRepository를 주입받고 있군요!
실제 OAuth2AuthorizationRequestRedirectFilter의 경우에도 직접 주입 받는데 잘 구현하셨네요 👍

boorownie · 2025-03-11T17:16:16Z

src/main/java/nextstep/security/oauth2/client/web/OAuth2LoginAuthenticationFilter.java

+    private final ClientRegistrationRepository clientRegistrationRepository;
+    private final AuthorizationRequestRepository authorizationRequestRepository = HttpSessionOAuth2AuthorizationRequestRepository.getInstance();


두 객체는 다른 방식으로 의존성을 주입하고 있는데 기준은 무엇이였나요?

주입 방식을 결정지은 기준은 '스프링 빈으로 등록되었는가' 입니다. 스프링 빈으로 등록되었다면 의존성을 스프링 컨테이너로 주입하고, 그렇지 않다면 생성자 또는 지금처럼 팩토리 메서드 호출로 의존성을 주입합니다.

그럼 결국 '무엇을 스프링 빈으로 등록할 것인가'. 에 따라 의존성 주입 방식이 달라진다는 것이니, 이 기준이 어떻게 정해졌는지 제 생각을 말씀드려볼게요.

AuthorizationRequestRepository

HttpSessionOAuth2AuthorizationRequestRepository외에 추가적으로 구현체가 생길 여지가 드물어 스프링 빈으로 등록하지 않음. (다형성을 이용하여 런타임에 구현체를 주입받을 필요가 없음)

추가로 인스턴스 초기화 과정이 비교적 단순하므로, 기본 생성자 호출 또는 팩터리 메서드 호출을 통해 의존성을 주입.

ClientRegistrationRepository

다형성을 이용하여 런타임에 구현체를 주입받기 위해 스프링 빈으로 등록.

추가로 미션에서는 구현체가 InMemoryClientRegistrationRepository 1개로 유지되지만, 인스턴스 초기화 과정에서 ClientRegistration을 미리 가공하는 등 초기화 과정이 복잡하므로 컨테이너 주입의 편리성 이용.

추가로, HttpSessionOAuth2AuthorizationRequestRepository의 경우 상태(sessionAttributeName)를 갖긴 하지만, 해당 상태가 모든 인스턴스마다 동일하게 유지되어 싱글톤으로 설계하였고, 이에 따라 팩토리 메서드 호출로 의존성을 주입하게 되었습니다..!

(실제 시큐리티에서는 생성자 호출로 의존성을 주입하던데 이 부분의 경우 HttpSessionOAuth2AuthorizationRequestRepository의 의존성을 주입받는 곳이 많지 않다보니 이렇게 설계한 것인가 싶긴 하네요 ㅎㅎ)

boorownie · 2025-03-11T17:17:14Z

src/main/java/nextstep/security/oauth2/client/userinfo/DefaultOAuth2UserService.java

+import java.util.Map;
+import java.util.Objects;
+
+public class DefaultOAuth2UserService implements OAuth2UserService {


DefaultOAuth2UserService는 왜 기본 구현체를 두셨나요? 이는 언제 사용하게 되나요?

OAuth 2.0 로그인 과정의 마지막 부분에서, Resource Server의 유저 정보를 이용하여 신규 가입 여부를 판단해야하는 로직이 있는데 이 때 유저 정보를 가져오는 역할을 수행하기 하기 위해 기본 구현체를 두게 되었습니다. 또, 액세스 토큰을 이용하여 Resource Server에 접근하여 유저 리소스를 가져오는 것은 OAuth 2.0 기본 스펙이다 보니, 기본 구현체가 이 역할을 하는 것이 적절하다고 생각이 들었습니다.

이렇게 구현하고 나니까 앱 개발자는 기본 구현체를 상속 받아서 추가적으로 커스텀 로직을 핀포인트로 딱 집어서 작성할 수 있어서 좋더라고요 :)

TMI) 제가 이 미션을 구현하면서 '프레임워크의 기본 구현체를 상속받아 로직을 작성을 해볼 수도 있구나' 를 깨닫게 되어 실무에서도 이를 활용해볼 수 있었습니다..! (서블릿 필터 레벨에서 발생한 인증 예외를 스펙에 따라 커스텀해야하는 요구사항이 있었는데 이 때 BasicErrorController를 상속해서 구현했습니다..! 정확히 필요한 부분만 커스텀할 수 있어서 전체 예외 처리 아키텍처도 깔끔하게 유지되는 경험을 할 수 있었습니다 :))

boorownie · 2025-03-11T17:19:31Z

...n/java/nextstep/security/oauth2/client/authentication/OAuth2LoginAuthenticationProvider.java

+    private OAuth2AccessToken exchangeToAccessToken(OAuth2LoginAuthenticationToken loginAuthenticationToken) {
+        Authentication unAuthenticated = OAuth2AuthorizationCodeAuthenticationToken.unauthenticated(
+                loginAuthenticationToken.getClientRegistration(),
+                loginAuthenticationToken.getAuthorizationExchange()
+        );
+
+        OAuth2AuthorizationCodeAuthenticationToken authenticated =
+                (OAuth2AuthorizationCodeAuthenticationToken) this.authorizationCodeAuthenticationProvider.authenticate(unAuthenticated);
+
+        return authenticated.getAccessToken();


흐름의 맥락을 잘 파악하셨네요 👍

boorownie · 2025-03-11T17:22:07Z

src/main/java/nextstep/security/oauth2/client/web/OAuth2AuthorizationRequestRedirectFilter.java

+    private final OAuth2AuthorizationRequestResolver authorizationRequestResolver;
+    private final AuthorizationRequestRepository authorizationRequestRepository = HttpSessionOAuth2AuthorizationRequestRepository.getInstance();
+
+    public OAuth2AuthorizationRequestRedirectFilter(ClientRegistrationRepository clientRegistrationRepository) {
+        this.authorizationRequestResolver = new DefaultOAuth2AuthorizationRequestResolver(
+                OAUTH2_LOGIN_REQUEST_URI_PREFIX,
+                clientRegistrationRepository
+        );
+    }


적절한 주입 방법 채택 👍

boorownie · 2025-03-11T17:23:33Z

...main/java/nextstep/security/oauth2/client/web/DefaultOAuth2AuthorizationRequestResolver.java

+    }
+
+    @Nullable
+    private String resolveRegistrationId(HttpServletRequest request) {


사실 이 부분은 스프링 시큐리티와 다르게 구현되어있는 부분인데요,
실제 코드 처럼 Matcher를 사용하게 하려면 어떻게 하면 좋을까요?
구현이 어려우면 계획 정도 공유주셔도 좋아요.

실제 코드 처럼 Matcher를 사용하게 하려면 다음과 같이 구현해볼 것 같습니다!

As Is

DefaultOAuth2AuthorizationRequestResolver 인스턴스 생성 시, OAuth2 인증 요청 URI prefix인 /oauth2/authorization/를 전달.

resolveRegistrationId()에서 직접 HTTP Request URI를 문자열로 비교하여 registrationId 추출.

To Be

특정 URI의 prefix가 일치하면 request 매칭 여부를 참으로 판단하는 RequestMatcher의 구현체 UriPrefixMatcher 구현.

DefaultOAuth2AuthorizationRequestResolver 인스턴스 생성 시, UriPrefixMatcher 인스턴스를 생성하여 파라미터로 넘긴다.

UriPrefixMatcher 인스턴스 생성 시 /oauth2/authorization/를 전달.

Matcher를 이용하여 registrationId를 파싱 및 리턴.

여기까지 설계하고 실제 스프링 시큐리티 구현을 봤는데요, AntPathRequestMatcher에서 내부적으로 RequestVariablesExtractor::extractUriTemplateVariables를 구현하여 registrationId를 추출하는 것을 확인했습니다 :)

boorownie · 2025-03-11T17:24:51Z

...tep/security/oauth2/client/authentication/OAuth2AuthorizationCodeAuthenticationProvider.java

+import nextstep.security.oauth2.client.endpoint.OAuth2AccessTokenResponseClient;
+import nextstep.security.oauth2.client.endpoint.OAuth2AuthorizationCodeGrantRequest;
+
+public class OAuth2AuthorizationCodeAuthenticationProvider implements AuthenticationProvider {


토큰 생성 및 처리 로직 모두 잘 구현해주셨습니다 👍

boorownie · 2025-03-11T17:26:54Z

src/main/java/nextstep/security/oauth2/client/web/OAuth2AuthorizationRequestRedirectFilter.java

+        doFilterInternal((HttpServletRequest) request, (HttpServletResponse) response, chain);
+    }
+
+    private void doFilterInternal(


답변에도 남겨두었듯 state를 프로세스로 녹여봐도 좋을 것 같아요.
이 역시 코드 구현에 오랜 시간이 걸릴 것 같으면 코멘트로라도 계획을 공유해주세요 :)

다음과 같이 구현해볼 수 있을 것 같습니다..!

(클라이언트) OAuth2 로그인 요청

(앱 서버) 리다이렉트 필터에서 state 생성하고, 세션에 저장 후 리다이렉트

(클라이언트) OAuth2 인증 페이지에서 인증 허용 후 앱 서버로 다시 리다이렉트

(앱 서버) 인증 필터에서 URI에 포함된 state 값이 세션에 저장한 state값과 일치하는지 비교
4-1. 일치하는 경우, 세션의 state값 삭제 (state는 탈취 시 문제될 수 있으므로 일회용으로 관리하기 위함)
4-2. 일치하지 않는 경우, 인증 예외 발생

이 부분은 스프링 시큐리티 실제 구현을 확인해보진 않았는데 제가 생각한 플로우랑 비슷할 것 같은 느낌입니다..!

미션 3을 수행할 때는 CSRF 공격에 대한 이해도가 낮아 state의 필요성을 거의 느끼질 못하였는데, 미션 4에서 CsrfFilter를 구현하며 state의 필요성을 조금이나마 느끼게 되었습니다...! (여기까지 내다보시고 미션을 설계 하신 것 같아 감탄했네요..😁)

boorownie

코멘트 남긴 내용에 대한 심도 깊은 답변으로 충분한 학습이 이뤄짐과 고민이 있었던것 같네요 👍
미션 수행하시느라 고생이 많으셨습니다!

haero77 added 16 commits March 9, 2025 13:54

사전 리팩토링 - OAuth2ClientProperties 패키지 위치 변경

34b36b8

- spring security 컨텍스트를 벗어나는 oauth2 프로토콜 그 자체와 매핑되는 클래스이므로 root.oauth2 패키지로 위치 변경

사전 리팩토링 - 미사용 클래스 제거

93ce857

사전 리팩토링 - OAuth2 관련 클래스를 성격에 따라 패키지 구분

d3ef98d

- src.security.oauth2.core/web/registration/userinfo - src.oauth2

(step2-2) docs: update step2 requirements, questions, OAuth2 Flow chart

592788e

(step2-1) registrationId별 ClientRegistration을 담는 일급컬렉션 ClientRegistra…

c5e9bfa

…tionRepository 구현

(step2-1) OAuth2AuthorizationRequestResolver 구현

139e450

- generates OAuth2AuthorizationRequest contains Redirect URI

(step2-1) OAuth2ClientPropertiesMapper 구현

a751086

- generates ClientRegistration using OAuth2ClientProperties

(step2-1) AuthorizationRequestRepository 구현

242ed1c

- save authorizationRequest to HTTP Session

(step2-2) 싱글톤 패턴 구현 시 인스턴스 필드가 null이 되는 문제 수정

0d8aadc

- Lazy initialization 사용

(step2-2) OAuth2LoginAuthenticationFilter 인증 처리 로직 개선

9758bcb

- OAuth2ClientProperties를 직접 사용하지 않고 ClientRegistration을 사용하도록 변경

(step2-2) 미사용 메서드 제거

4d827a9

(step2-2) OAuth2LoginAuthenticationFilter 인증 로직 개선

7424d70

- OAuth2 Client를 직접 의존하지 않도록 변경 - OAuth2AuthorizationCodeAuthenticationProvider를 통해 AccessToken을 조회하도록 변경

(step2-2) OAuth2AuthorizationCodeAuthenticationProvider 구현

e8b6513

(step2-2) 불필요한 상수 제거

61a3bf9

(step2-2) OAuth2 플랫폼별 유저 정보 조회 로직 통합

4caeb8c

(step2-2) 프로덕션 변경에 따른 테스트 수정

143f617

haero77 force-pushed the step2-review branch from ccd12b0 to 143f617 Compare March 9, 2025 05:00

haero77 changed the title ~~[김선호] 1단계 - OAuth2.0 로그인 리뷰 요청드립니다 🚀~~ [김선호] 2단계 - 리다이렉트 필러, OAuth2 인증 필터 리뷰 요청드립니다 🚀 Mar 9, 2025

haero77 changed the title ~~[김선호] 2단계 - 리다이렉트 필러, OAuth2 인증 필터 리뷰 요청드립니다 🚀~~ [김선호] 2단계 - 리다이렉트 필터 & OAuth2 인증 필터 리뷰 요청드립니다 🚀 Mar 9, 2025

haero77 commented Mar 9, 2025

View reviewed changes

boorownie requested changes Mar 11, 2025

View reviewed changes

boorownie approved these changes Mar 28, 2025

View reviewed changes

boorownie merged commit 57b5511 into next-step:haero77 Mar 28, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[김선호] 2단계 - 리다이렉트 필터 & OAuth2 인증 필터 리뷰 요청드립니다 🚀 #21

[김선호] 2단계 - 리다이렉트 필터 & OAuth2 인증 필터 리뷰 요청드립니다 🚀 #21

haero77 commented Mar 9, 2025 •

edited

Loading

haero77 Mar 9, 2025

boorownie Mar 11, 2025

haero77 Mar 9, 2025

boorownie Mar 11, 2025

boorownie left a comment

boorownie Mar 11, 2025

boorownie Mar 11, 2025

boorownie Mar 11, 2025

haero77 Mar 23, 2025 •

edited

Loading

boorownie Mar 11, 2025

haero77 Mar 23, 2025 •

edited

Loading

boorownie Mar 11, 2025

boorownie Mar 11, 2025

boorownie Mar 11, 2025

haero77 Mar 23, 2025

boorownie Mar 11, 2025

boorownie Mar 11, 2025

haero77 Mar 23, 2025

boorownie left a comment


		public class OAuth2ClientPropertiesMapper {

		private final OAuth2ClientProperties properties;

		new OAuth2AuthorizationRequestRedirectFilter(clientRegistrationRepository),
		new OAuth2LoginAuthenticationFilter(oAuth2UserService, clientRegistrationRepository),

		private final ClientRegistrationRepository clientRegistrationRepository;
		private final AuthorizationRequestRepository authorizationRequestRepository = HttpSessionOAuth2AuthorizationRequestRepository.getInstance();

[김선호] 2단계 - 리다이렉트 필터 & OAuth2 인증 필터 리뷰 요청드립니다 🚀 #21

[김선호] 2단계 - 리다이렉트 필터 & OAuth2 인증 필터 리뷰 요청드립니다 🚀 #21

Conversation

haero77 commented Mar 9, 2025 • edited Loading

Choose a reason for hiding this comment

Q. Security에서 왜 어떤 의존성은 주입받고, 어떤 의존성은 자체적으로 생성하는지에 대한 의문

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boorownie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

haero77 Mar 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

haero77 Mar 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

As Is

To Be

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boorownie left a comment

Choose a reason for hiding this comment

haero77 commented Mar 9, 2025 •

edited

Loading

haero77 Mar 23, 2025 •

edited

Loading

haero77 Mar 23, 2025 •

edited

Loading