cornarong의 블로그

ZIP파일 GItHub에 신규 레포지토리로 등록하기

cornarong — Tue, 6 Aug 2024 14:35:15 +0900

GitHub에서 다운로드한 ZIP 파일을 새 레포지토리로 다시 등록하려면 다음 단계를 따르면 됩니다.

ZIP 파일 압축 해제: 먼저, 다운로드한 ZIP 파일의 압축을 해제합니다. 이 파일에는 원래의 Git 저장소가 포함되어 있을 수 있습니다.
새 Git 레포지토리 생성:
- GitHub 웹사이트에 로그인합니다.
- 오른쪽 상단의 + 버튼을 클릭하고 New repository를 선택합니다.
- 레포지토리 이름과 설명을 입력하고, 필요에 따라 공개/비공개 설정을 합니다.
- Create repository 버튼을 클릭하여 새 레포지토리를 생성합니다.
Git 초기화 및 최초 commit 등록:
- 압축 해제한 폴더에서 파일 주소창에 "cmd"를 입력하여 터미널을 열거나
- 터미널(또는 명령 프롬프트)을 열고, 압축 해제한 폴더로 이동합니다.
- 아래의 명령어 순서로 이 폴더의 Git 초기화 및 최초 commit 등록

1. git init

2. git add .

3. git commit -m "Inital commit"

새 레포지토리에 원격 연결 및 푸시:
- GitHub에서 새로 생성한 레포지토리의 URL을 복사합니다 (HTTPS 또는 SSH).
- 원격 레포지토리를 추가하고, 커밋된 파일을 푸시합니다.
  
  1. git remote add origin https://github.com/username/new-repository.git
  2. git branch -M main
  3. git push -u origin main
  
  * 여기서 https://github.com/username/new-repository.git는 새 레포지토리의 HTTPS의 주소를 붙여넣습니다.

Mybatis 다중 DB 연결 방법 (main, sub)

cornarong — Thu, 4 Jul 2024 18:01:01 +0900

기존 설정되어있는 SE 데이터베이스 외에 추가로 FC 데이터베이스 연결이 필요한 상황에서 사용한 방법입니다.

각 설정파일 내 어노테이션이나 메소드 등 기능들과 흐름에 대한 설명들은 제외했습니다.

일반적이지 않은 상황이라 차후에 저도 참고만 하기위해 단순 사용방법만 작성했습니다.

참고만 해주세요.

나머지는 정보가 많이 있으니 검색해보시기 바랍니다.

* 사용 및 구분 명칭

기존 사용중인 Database : Se / 신규 추가된 Database : Fc

1. properties 또는 yml 설정

* 주의 : 프리픽스(prefix) 설정란에 데이터베이스 주소를 "url" 로 사용중이라면 "jdbc-url"로 변경

# SE DB
spring.datasource.se.jdbc-url=jdbc:log4jdbc:postgresql://{SE_ADDRESS}:{SE_PORT}/{SE_DATABASENAME}?sslmode=require
spring.datasource.se.username={SE_NAME}
spring.datasource.se.password={SE_PASSWORD}
spring.datasource.se.driver-class-name=net.sf.log4jdbc.sql.jdbcapi.DriverSpy

# FC DB
spring.datasource.fc.jdbc-url=jdbc:log4jdbc:postgresql://{FC_ADDRESS}:{FC_PORT}/{FC_DATABASENAME}?sslmode=require
spring.datasource.fc.username={FC_NAME}
spring.datasource.fc.password={FC_PASSWORD}
spring.datasource.fc.driver-class-name=net.sf.log4jdbc.sql.jdbcapi.DriverSpy

* 사용할 DB에 따라 디렉토리, 파일을 정확히 나누어놓고 config 설정만 잘 해놓으면 끝.

2. 기본 디렉토리 및 파일 설정

* Se와 Fc 디렉토리를 나누어 디렉토리에 따라 각각 다른 데이터베이스를 사용하도록 설정합니다.

java config 추가

java/{프로젝트명}/config/SeDatabaseConfig .java 파일 추가
java/{프로젝트명}/config/FcDatabaseConfig.java 파일 추가

java mppper interface 디렉토리 추가

java/{프로젝트명}/mapper/se 디렉토리 추가
java/{프로젝트명}/mapper/fc 디렉토리 추가

resources mapper xml 디렉토리 추가

resources/mapper/se디렉토리 추가
resources/mapper/fc 디렉토리 추가

resources config 추가

resources/mybatis 디렉토리 추가
resources/mybatis/ mybatis-config.xml 파일 추가

SeDatabaseConfig.java

* @Primary 어노테이션으로 해당 데이터베이스가 메인이되는 Database라고 선언해줍니다.

@Configuration
@EnableTransactionManagement
@MapperScan(basePackages = "{프로젝트명}.mapper.se", sqlSessionFactoryRef = "seSqlSessionFactory", sqlSessionTemplateRef = "seSqlSession")
public class SeDatabaseConfig {

    @Primary
    @Bean(name = "seDataSource")
    @ConfigurationProperties(prefix = "spring.datasource.se")
    public DataSource seDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Primary
    @Bean(name = "seSqlSessionFactory")
    public SqlSessionFactory seSqlSessionFactory(@Qualifier("seDataSource") DataSource seDataSource, ApplicationContext applicationContext) throws Exception {
        SqlSessionFactoryBean sessionFactory = new SqlSessionFactoryBean();
        sessionFactory.setDataSource(seDataSource);
        sessionFactory.setConfigLocation(applicationContext.getResource("classpath:mybatis/mybatis-config.xml"));
        sessionFactory.setVfs(SpringBootVFS.class);
        sessionFactory.setMapperLocations(applicationContext.getResources("classpath:mapper/se/*.xml"));
        return sessionFactory.getObject();
    }

    @Primary
    @Bean(name = "seSqlSession")
    public SqlSessionTemplate seSqlSession(@Qualifier("seSqlSessionFactory") SqlSessionFactory seSqlSessionFactory) throws Exception {
        return new SqlSessionTemplate(seSqlSessionFactory);
    }

    @Primary
    @Bean(name = "seTransactionManager")
    public DataSourceTransactionManager seTransactionManager(@Qualifier("seDataSource") DataSource seDataSource) {
        return new DataSourceTransactionManager(seDataSource);
    }
}

FcDatabaseConfig.java

* SeDatabaseConfig.java 의 @Primary 어노테이션만 제거하고, 경로만 Fc로 맞춰줍니다.

@Configuration
@EnableTransactionManagement
@MapperScan(basePackages = "{프로젝트명}.mapper.fc", sqlSessionFactoryRef = "fcSqlSessionFactory", sqlSessionTemplateRef = "fcSqlSession")
public class FcDatabaseConfig {

    @Bean(name = "fcDataSource")
    @ConfigurationProperties(prefix = "spring.datasource.fc")
    public DataSource fcDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean(name = "fcSqlSessionFactory")
    public SqlSessionFactory fcSqlSessionFactory(@Qualifier("fcDataSource") DataSource fcDataSource, ApplicationContext applicationContext) throws Exception {
        SqlSessionFactoryBean sessionFactory = new SqlSessionFactoryBean();
        sessionFactory.setDataSource(fcDataSource);
        sessionFactory.setConfigLocation(applicationContext.getResource("classpath:mybatis/mybatis-config.xml"));
        sessionFactory.setVfs(SpringBootVFS.class);
        sessionFactory.setMapperLocations(applicationContext.getResources("classpath:mapper/fc/*.xml"));
        return sessionFactory.getObject();
    }

    @Bean(name = "fcSqlSession")
    public SqlSessionTemplate fcSqlSession(@Qualifier("fcSqlSessionFactory") SqlSessionFactory fcSqlSessionFactory) throws Exception {
        return new SqlSessionTemplate(fcSqlSessionFactory);
    }

    @Bean(name = "fcTransactionManager")
    public DataSourceTransactionManager fcTransactionManager(@Qualifier("fcDataSource") DataSource fcDataSource) {
        return new DataSourceTransactionManager(fcDataSource);
    }
}

mybatis-config.xml

* 옵션에 따라 그대로 사용하시면 됩니다.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
    <settings>
        <!-- 캐시 활성화 여부 -->
        <setting name="cacheEnabled" value="true"/>
        <!-- null 값에 대해 setter를 호출할지 여부 -->
        <setting name="callSettersOnNulls" value="rue"/>        
        <!-- 지연 로딩 비활성화 -->
        <setting name="lazyLoadingEnabled" value="false"/>        
        <!-- 적극적인 지연 로딩 활성화 -->
        <setting name="aggressiveLazyLoading" value="true"/>        
        <!-- 다중 결과 집합 활성화 -->
        <setting name="multipleResultSetsEnabled" value="true"/>        
        <!-- 컬럼 레이블 사용 여부 -->
        <setting name="useColumnLabel" value="true"/>        
        <!-- 생성된 키 사용 여부 -->
        <setting name="useGeneratedKeys" value="false"/>        
        <!-- 자동 매핑 동작 설정 -->
        <setting name="autoMappingBehavior" value="PARTIAL"/>        
        <!-- 기본 실행기 타입 설정 -->
        <setting name="defaultExecutorType" value="REUSE" />        
        <!-- 기본 문장 타임아웃(ms) 설정 -->
        <setting name="defaultStatementTimeout" value="25000" />        
        <!-- null에 대한 JDBC 유형 설정 -->
        <setting name="jdbcTypeForNull" value="NULL"/>
    </settings>
    <typeAliases>
        <typeAlias alias="hashMap" type="java.util.HashMap" />
        <typeAlias alias="String" type="java.lang.String"/>
    </typeAliases>
    <mappers>
    </mappers>
</configuration>

위 설정을 통해 Se와 Fc 데이터베이스를 구분하여 각각의 설정과 연결을 하고

이후로는 위에서 나누어놓은 디렉토리(SE, FC)에 따라 기존 방식대로 mybatis를 사용하면 됩니다.

Se mapper에 설정한 메소드, 쿼리는 SeDatabase를 바라보고 사용하고

Fc mapper에 설정한 메소드, 쿼리는 FcDatabase를 바라보고 사용하게 됩니다.

[JPA] 더티 체킹(Dirty Checking)? + 동시성 이슈/제어

cornarong — Thu, 13 Jun 2024 16:41:24 +0900

1. 더티 체킹 개념

더티 체킹(Dirty Checking): JPA의 기능으로, 영속성 컨텍스트에 담긴 엔티티의 상태 변화를 자동으로 감지하여 트랜잭션 커밋 시점에 변경 사항을 데이터베이스에 반영하는 메커니즘.

2. 영속성 컨텍스트(Persistence Context)

정의: 엔티티를 영속성 컨텍스트에 담아 관리하는 일종의 캐시.
역할: 엔티티의 상태를 추적하고, 변경된 엔티티를 데이터베이스에 자동으로 반영.

3. 엔티티의 생명주기

비영속 상태(New/Transient): 엔티티가 영속성 컨텍스트에 담기지 않은 상태.
영속 상태(Managed): 엔티티가 영속성 컨텍스트에 담긴 상태. 더티 체킹의 대상.
준영속 상태(Detached): 영속성 컨텍스트에서 분리된 상태.
삭제 상태(Removed): 엔티티가 삭제된 상태.

4. 더티 체킹 동작 원리

변경 감지: 영속성 컨텍스트는 트랜잭션이 시작될 때 엔티티의 스냅샷을 저장. 트랜잭션 종료 시 스냅샷과 비교하여 변경 사항을 감지.
트랜잭션 커밋 시점: 감지된 변경 사항을 데이터베이스에 반영.

5. 트랜잭션 내에서의 더티 체킹 예제

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    @Transactional
    public void updateUserName(Long userId, String newName) {
        // 1. 엔티티 조회: 영속성 컨텍스트에 담김
        User user = userRepository.findById(userId).orElseThrow(() -> new EntityNotFoundException("User not found"));
        // 2. 엔티티 속성 변경: 더티 체킹 대상
        user.setName(newName);
        // 3. 트랜잭션 커밋: 변경 사항이 자동으로 데이터베이스에 반영
    }
}

6. 주요 고려사항

트랜잭션 사용: 더티 체킹은 트랜잭션 내에서 작동.
영속성 컨텍스트: 엔티티가 영속성 컨텍스트에 있어야 더티 체킹이 가능.
명시적 저장: 경우에 따라 명시적으로 save 메서드를 호출하여 변경 사항을 저장할 수도 있음.

7. 신규 엔티티와 더티 체킹

신규 엔티티는 save 호출 시 영속성 컨텍스트에 담기며, 그 이후 변경 사항은 더티 체킹의 대상이 됨.

@Transactional
public void createUser(String name) {
    User user = new User();
    user.setName(name);
    userRepository.save(user);  // 엔티티가 영속성 컨텍스트에 담기고 데이터베이스에 저장됨
}

8. 동시성 이슈

* 동시성 문제는 여러 사용자가 동시에 동일한 데이터를 수정할 때 발생할 수 있음. 예로 두 사용자가 동일한 엔티티를 동시에 수정하고 저장하는 경우 데이터 일관성 문제가 발생할 수 있다.

9. 해결(제어) 방법

- 여러가지 제어 방법이 있고 락을 사용하는 방법 두가지만 간략하게 정리했습니다. 이런 방식이 있다 정도만 알고 활용하면 될 것 같습니다.

1. 낙관적 락(optimistic lock) : 가장 일반적인 해결 방법으로, Optimistic Locking을 활용하여 충돌을 방지한다.
엔티티에 버전 필드(ex. @Version)를 추가하여 버전이 일치하지 않는 경우에는 충돌로 간주하고 예외를 발생시키거나 복구한다.

사용 방법: 낙관적 락은 여러 사용자가 동시에 데이터를 수정할 가능성이 낮을 때 사용된다. 엔티티를 읽을 때 버전 번호나 타임스탬프를 체크하여 충돌을 감지하고, 업데이트시에만 실제로 데이터베이스에서 해당 엔티티의 상태를 확인하고 업데이트한다.
장점: 동시성이 높은 환경에서 성능이 좋다. 일반적인 상황에서 데이터베이스 락을 걸지 않고도 충돌을 피할 수 있다.
적합한 상황: 대부분의 경우에서 사용할 수 있으며, 충돌이 발생할 가능성이 낮은 경우 적합하다.

- optimistic lock 예제)

@Entity
public class Entity {
    @Id
    private Long id;
    
    @Version
    private Long version; // Optimistic Locking을 위한 버전 필드
   
    // getters, setters, other fields...
}

2. 비관적 락(pessimistic lock) : 특정 엔티티를 읽을 때 잠금을 거는 방식. 이 방법은 특히 긴 트랜잭션 내에서 엔티티의 상태가 변경되지 않도록 보장한다. "LockModeType.PESSIMISTIC_WRITE"를 사용하여 엔티티를 잠근다.

사용 방법: 비관적 락은 데이터가 수정될 가능성이 크거나 긴 시간 동안 데이터를 잠금(lock) 해야 할 때 사용된다. 데이터를 읽을 때 바로 데이터베이스에서 잠금을 걸어 다른 사용자가 해당 데이터를 수정할 수 없도록 한다.
장점: 데이터 일관성을 보장할 수 있으며 긴 트랜잭션에서 데이터가 변경되지 않도록 보호할 수 있다.
적합한 상황: 특정 데이터의 동시 수정이 빈번하거나 데이터 일관성을 엄격하게 유지해야 하는 경우에 적합하다.

- pessimistic lock 예제)

public interface EntityRepository extends JpaRepository<Entity, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT e FROM Entity e WHERE e.id = :id")
    MyEntity findByIdWithPessimisticWriteLock(@Param("id") Long id);
}

9. 더티 체킹(Dirty Checking) 정리

* JPA 더티 체킹은 영속성 컨텍스트에서 엔티티의 상태 변화를 자동으로 감지하여 데이터베이스에 반영하는 핵심 기능.

1. 자동 변경 감지: 트랜잭션 내에서 영속성 컨텍스트에 있는 엔티티의 속성 변화를 추적한다

2. 트랜잭션 커밋 시점: 트랜잭션이 커밋될 때, 더티 체킹에 의해 변경된 엔티티의 상태가 데이터베이스에 자동으로 반영된다

3. 영속성 컨텍스트 필요: 엔티티가 영속성 컨텍스트에 관리되어야만 더티 체킹이 작동한다

4. 신규 엔티티의 저장: 신규 생성된 엔티티는 save() 메서드를 통해 데이터베이스에 저장되고, 이후에 발생하는 변경 사항도 더티 체킹을 통해 관리된다

5. 명시적 저장: 경우에 따라 명시적으로 save() 메서드를 호출하여 변경 사항을 데이터베이스에 반영할 수 있다

10. 동시성 해결 정리

1. 낙관적 락 : 충돌이 적을 때 사용하며, 성능을 위해 데이터베이스 락을 피하고 업데이트 충돌을 감지한다.

2. 비관적 락 : 충돌이 발생할 가능성이 크거나 데이터 일관성을 강제로 유지해야 할 때 사용하며, 데이터베이스 락을 활용 하여 데이터를 보호한다람쥐.

git clone - intellij 세팅

cornarong — Mon, 30 May 2022 19:09:10 +0900

프로젝트 권한 받기

File -> new -> Get from Version Control (레포지토리 url 또는 깃허브 계정 연결 시 레포지토리 선택)

* 레포지토리 구조 그대로 따올경우 gradle 인식 못하는 경우 발생

-> build.gradle 우클릭 gradle link? 머머~ 클릭

Project Structure -

java version 설정

Setting -

Enable annotation processing 체크

Build Tools -> gradle -> intelliJ IDEA로 설정(Build and run using, Run tests using)

---------------------------

main 레포지토리 fork 후 내 계정에서 관리

브런치 하나 만들어서 개발 후 Pull requests 요청 팀장급 승인 후 merge 및 코멘트

[Security] Success/Failure Handler Custom (인증성공, 인증실패 핸들러 커스텀)

cornarong — Tue, 28 Dec 2021 22:43:18 +0900

: Security에서 지원하는 인증성공, 인증실패 핸들러를 상속한 클래스를 직접 커스텀하여 사용해보자.

1. 인증성공 핸들러 커스텀

2. 인증실패 핸들러 커스텀

3. config 설정

4. 익명클래스로 처리하는 방법

1. 인증성공 핸들러 커스텀

1. SimpleUrlAuthenticationSuccessHandler를 상속한 커스텀 클래스 CustomAuthenticationSuccessHandler를 만듭니다.

2. requestCache와 RedirectStragey를 사용하여 사용자가 인증 요청 성공시 이전에 접근하려 했던 자원(리소스)의 경로로 바로 보내기 위해서 설정해줍니다. 이전의 접근하려 했던 자원(리소스)가 없는 경우 null을 반환하도록 하여 setDefaultTargetUrl에 설정해준 url로 보내줍니다.

// 인증 성공 핸들러 : CustomAuthenticationSuccessHandler
@Component
public class CustomAuthenticationSuccessHandler extends SimpleUrlAuthenticationSuccessHandler {

    private RequestCache requestCache = new HttpSessionRequestCache();

    private RedirectStrategy redirectStrategy = new DefaultRedirectStrategy();

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws IOException {

        //기본 url 설정, savedRequest가 null일 경우 설정한 페이지로 보내기 위함이다.
        setDefaultTargetUrl("/");

        // 사용자가 인증을 시도하기 이전에 접근을 시도했던 자원이 없을경우 savedRequest는 null로 반환된다.
        SavedRequest savedRequest = requestCache.getRequest(request, response);
        if(savedRequest != null) {
            String targetUrl = savedRequest.getRedirectUrl();
            redirectStrategy.sendRedirect(request, response, targetUrl);
        }else{
            redirectStrategy.sendRedirect(request, response, getDefaultTargetUrl());
        }
    }
}

2. 인증실패 핸들러 커스텀

1. SimpleUrlAuthenticationFailureHandler를 상속한 커스텀 클래스 CustomAuthenticationFailureHandler를 만듭니다.

// 인증 실패 핸들러 : CustomAuthenticationFailureHandler
@Component
public class CustomAuthenticationFailureHandler extends SimpleUrlAuthenticationFailureHandler {

    @Override
    public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response, AuthenticationException exception) throws IOException, ServletException {

        String errorMessage = "Invalid Username or Password"; // 기본 예외 메시지
        
        // exceprion 처리
        if(exception instanceof BadCredentialsException) { 
            errorMessage = "Invalid Username or Password";
        }else if(exception instanceof InsufficientAuthenticationException) {
            errorMessage = "Invalid Secret Key";
        }
        // 파라미터로 error와 exception을 보내서 controller에서 처리하기 위함.
        setDefaultFailureUrl("/login?error=true&exception=" + errorMessage);

        // 부모클래스의 onAuthenticationFailure로 처리를 위임하자.
        super.onAuthenticationFailure(request, response, exception);
    }
}

successHandler와 다르게 failureHandler에서 super클래스를 선언해준 이유

-> 실패와 관련된 여러가지 후속처리를 부모에게 위임하기 위함이다.

-> 모두 super 클래스를 호출하지 않아도 상관은 없다.

3. SecurityConfig 설정

  @Autowired
  private final AuthenticationSuccessHandler customAuthenticationSuccessHandler;
  @Autowired
  private final AuthenticationFailureHandler customAuthenticationFailureHandler;

  http
  .formLogin()
    . // ~생략
    .successHandler(customAuthenticationSuccessHandler) // 1. 성공시 custom success 핸들러를 호출한다.
    .failureHandler(customAuthenticationFailureHandler) // 1. 실패시 custom failure 핸들러를 호출한다.

4. 익명클래스로 SecurityConfig내에서 처리하기.

  http
    .formLogin()
    . // ~생략
    .successHandler(new AuthenticationSuccessHandler() { // 2. 성공시 success 핸들러를 호출한다. 추가로 사용해보자
      // 로그인 성공시 authentication 정보를 매개변수로 -
      @Override
        public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws IOException, ServletException {
        RequestCache requestCache = new HttpSessionRequestCache();
        SavedRequest savedRequest = requestCache.getRequest(request, response); // savedRequest 안에 사용자가 가고자 했던 정보가 들어 있다.
        String redirectUrl = savedRequest.getRedirectUrl();
        // 인증에 성공하면 세션에 저장되어 있던 이전 정보(가고자 했던 경로)를 꺼내와서 이동 시킨다.
        response.sendRedirect(redirectUrl);
      }
    })
    .failureHandler(new AuthenticationFailureHandler() { // 2. 실패시 fail 핸들러를 호출한다. 추가로 사용해보자
      // 로그인 실패시 exception 정보를 매개변수로 -
      @Override
        public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response, AuthenticationException exception) throws IOException, ServletException {
        response.sendRedirect("/loginPage");
      }
    });

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - 인프런 | 강의

초급에서 중.고급에 이르기까지 스프링 시큐리티의 기본 개념부터 API 사용법과 내부 아키텍처를 학습하게 되고 이를 바탕으로 실전 프로젝트를 완성해 나감으로써 스프링 시큐리티의 인증과

www.inflearn.com

[Security] 세션 제어 필터 : SessionManagementFilter, ConcurrentSessionFilter

cornarong — Thu, 9 Dec 2021 20:54:21 +0900

세션 제어 필터 : SessionManagementFilter, ConcurrentSessionFilter

1. SessionManagementFilter의 핵심적인 4가지 기능

1-1. 세션 관리 : 인증 시 사용자의 세션정보를 등록, 조회, 삭제 등의 세션 이력을 관리

1-2. 동시적 세션 제어 : 동일 계정으로 접속이 허용되는 최대 세션수를 제한

1-3. 세션 고정 보호 : 인증할 때 마다 세션쿠키를 새로 발급하여 공격자의 쿠키 조작을 방지

1-4. 세션 생성 정책 : Always, If_Required, Never, Stateless

2. ConcurrentSessionFilter의 기능

매 요청 마다 현재 사용자의 세션 만료 여부 체크
세션이 만료되었을 경우 즉시 만료 처리
session.isExpired() == true ( : 세션 만료되었습니까? == 참)
- 로그아웃 처리
- 즉시 오류 페이지 응답, "This session has been expired"

* 위의 두개의 필터가 연계하여 처리하는 경우

예) 최대 세션 허용개수가 초과 -> SessionManagementFilter에서 이전 사용자 세션 만료 처리

-> ConcurrentSessionFilter가 매 요청마다 세션 만료 여부 체크

정리하면

SessionManagementFilter와 ConcurrentSessionFilter는 서로 연계하여 1-2.동시적 세션 제어 처리를 합니다.

아래의 그림에서 user1과 user2를 예시로 세션 처리 과정의 전반적인 흐름을 그림으로 살펴보겠습니다.

왼쪽의 상단에서 아래로 user1 -> user2 -> user1 순서대로 로그인 및 Get호출을 할 경우 세션이 처리되는 과정을 간략하게 글로 설명해보면 아래와 같습니다.

user1 로그인
- -> ConcurrentSessionControlAuthenticationStrategy에서 세션 허용 개수 확인
- -> ChangeSessionIdAuthenticationStrategy에서 세션 고정 보호 기능 처리
- -> RegisterSessionAuthenticationStrategy에서 세션 정보 등록
- -> 인증 성공

user2 로그인
- -> ConcurrentSessionControlAuthenticationStrategy에서 세션 허용 개수 확인 -> 허용 개수 초과 발생!
- 1번 전략
  - 인증 실패 전략 -> SessionAuthenticationException 예외 발생
  - -> 인증 실패
- 2번 전략 : 이떄 SessionManagementFilter와 ConcurrentSessionFilter가 연계해서 처리하게 됩니다.
  - 세션 만료 전략 -> session.expireNow()로 기존 사용자 세션 만료
  - -> 위에 동일 하게 user2의 세션 고정 보호 기능 처리 및 세션 정보 등록
  - -> 인증 성공

user1 Get호출 (세션 만료 전략으로 인해 user1 사용자의 세션은 만료 상태)
- -> session. isExpired() == true -> 세션 만료
- -> 로그인 실패 (This session has been expired)

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - 인프런 | 강의

www.inflearn.com

[Security] 동시세션제어, 세션고정보호, 세션정책

cornarong — Wed, 8 Dec 2021 22:43:14 +0900

1. 동시 세션 제어

: 동일한 계정으로 인증을 받을 떄 생성되는 세션의 개수가 허용 개수를 초과할 경우 어떻게 세션 유지할지 제어하는 것

최대 세션 허용 개수 초과 시 -> 시큐리티에서 2가지 전략을 제공합니다.

1. 이전 사용자 세션 만료

: 새로운 사용자에게 세션 생성, 이전(기존) 사용자의 세션을 만료시킵니다.

2. 현재 사용자 인증 실패

: 이전(기존) 사용자의 세션을 유지시키고, 새로운 사용자의 인증예외를 발생시킵니다.

사용 방법)

http.sessionManagement() : 세션 관리 기능이 작동

protected void configure(HttpSecurity http) throws Exception {
    http.sessionManagement()
         .maximumSessions(1) // 최대 허용 가능 세션 수, -1 : 무제한 로그인 세션 허용
         .maxSessionsPreventsLogin(true) // 동시 로그인 차단, false : 기존 세션 만료(default)
         .invalidSessionUrl("/invalid") // 세션이 유효하지 않을 대 이동 할 페이지
         .expiredUrl("/expired") // 세션이 만료된 경우 이동 할 페이지

1번 전략 : .maxSessionsPreventsLogin(false) 사용시 기존 사용자 세션 만료

2번 전략 : .maxSessionsPreventsLogin(true) 사용시 새로운 사용자 인증예외 발생

exception : Maximum sessions of 1 for this principal exceeded

2. 세션 고정 보호

세션 고정 공격을 방지하기 위해서 시큐리티는 세션 고정 보호 기능을 제공합니다.

사용자는 공격자가 심어놓은 쿠키로 인증을 하더라도 인증을 할 떄 마다 새로운 세션이 생성됩니다.

사용방법)

http.sessionManagement()
        .sessionFixation().changeSessionId(); // 기본 값 (서블릿 3.1 이상의 기본 값)

        // 새로운 세션 할당, 기존 세션의 모든 어트리뷰트가 새로운 세션으로 이동한다. (서블릿 3.1 이하의 기본 값)
        //.sessionFixation().migrateSession()

        // 새로운 세션 생성, 기존 세션의 모든 어트리뷰트는 새로운 세션으로 옮겨지지 않는다.
        //.sessionFixation().newSession() // 새로운 세션 생성

        // 설정해제, 공격에 방치된다.
        //.sessionFixation().none();

3. 세션 정책

사용방법)

http.sessionManagement()
        .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED);
		//.sessionCreationPolicy(SessionCreationPolicy.ALWAYS)
  		//.sessionCreationPolicy(SessionCreationPolicy.NEVER)
		//.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
    }

.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) : 스프링 시큐리티가 필요 시 생성(기본 값)
.sessionCreationPolicy(SessionCreationPolicy.ALWAYS) : 스프링 시큐리티가 항상 세션 생성
.sessionCreationPolicy(SessionCreationPolicy.NEVER) : 스프링 시큐리티가 생성하지 않지만 이미 존재하면 사용
.sessionCreationPolicy(SessionCreationPolicy.STATELESS) : 스프링 시큐리티가 생성하지도 않고 존재해도 사용하지 않음

[HTTP] 캐시(cache)와 조건부 요청

cornarong — Mon, 6 Dec 2021 16:45:22 +0900

학습내용

캐시 기본 동작
검증 헤더와 조건부 요청
프록시 캐시
캐시 무효화

1. 캐시가 없을 경우

데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
인터넷 네트워크는 매우 느리고 비싸다.
브라우저 로딩 속도가 느리다.
느린 사용자 경험

2. 캐시를 적용할 경우

캐시 가능 시간(유효 시간)동안 네트워크를 사용하지 않아도 된다.
- -> 유효시간이 남아있는 경우에도 매번 검증이 필요한 경우 네트워크 통신이 이루어지지만 Header의 메타 데이터만 주고 받아 데이터 원문이 담긴 Body는 생략되기 때문에 가볍다, 물론 데이터의 수정이 이루어진 경우를 대비해 검증 Header를 가지고 조건부 요청을 해야한다.
- 검증 헤더 : Last-Modifed ,ETag
- 조건부 요청 헤더 : If-Modified-Since, If-None-Match
비싼 네트워크 사용량을 줄일 수 있다.
브라우저 로딩 속도가 매우 빠르다.
빠른 사용자 경험

캐시 시간 초과

캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다.
이 떄 다시 네트워크 다운로드가 발생한다.

검증 헤더와 조건부 요청

캐시 유효 시간이 초과해도, 서버의 데이터가 수정(갱신)되지 않으면 서버에서 304 Not Modified로 Header의 메타 정보만 응답한다. (Body는 생략)
클라이언트는 서버측에서 보낸 응답 Header의 메타 정보로 캐시의 메타 정보를 갱신한다.
클라이언트는 캐시에 저장되어 있는 데이터를 재활용한다.
결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드 한다.
매우 실용적인 해결책

검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modified, ETag
조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기
- If-Modified-Since : Last-Modified 사용
- If-None-Match : ETag 사용
- 조건이 만족하면 200 OK
- 조건이 만족하지 않으면 304 Not Modified

Last-Modifed의 단점

1초 미만(0.x초)단위로 캐시 조정이 불가능 -> 별로 필요 없다고 한다.
날짜 기반의 로직 사용
데이터를 수정해서 날짜가 다르지만, 데이터를 수정했지만 최총 데이터 결과가 똑같은 경우는 비효율적이다.
- 예) 수정 후 다시 원복하여 데이터는 기존의 데이터와 같지만 수정날짜는 변경되는 상황
서버에서 별도의 캐시 로직을 관리하고 싶은 경우
- 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag 정리

진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받는다.
캐시 제어 로직을 서버에서 완전히 관리한다.
클라이언트는 단순히 이 값을 서버에 제공만 한다(클라이언트는 캐시 메커니즘을 모른다)
예)
- 서버 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
- 애플리케이션 배포 주기에 맞추어 ETag를 모두 갱신

캐시 제어 헤더

Cache-Control : 캐시 제어
Pragma : 캐시 제어(하위 호환) -> 정리 생략, 필요시 구글링(중요x)
Expires : 캐시 유효 기간(하위 호환) -> 정리 생략, 필요시 구글링(중요x)

Cache-Control (캐시 지시어/directives)

Cache-Control : max-age : 캐시 유효 시간, 초 단위
Cache-Control : no-cahe : 데이터는 캐시해도 되지만, 항상 원서버(origin서버)에 검증하고 사용
Cache-Control : no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 바로 삭제)

프록시 캐시

클라이언트가 서버에 요청시 서버(원서버)가 먼곳에 위치할 경우(예를들어 한국->미국) 응답 속도가 느려지기 떄문에 클라이언트에 가까운 곳(한국)에 프록시 서버 캐시를 둔다.

이때 사용되는 캐시제시어 public, private등이 있다.-> 정리 생략 필요시 구글링(중요x)

캐시를 적용 안하면 사용되지 않는 것 아닌가요?

요청에 따라 웹 브라우저가 임의로 사용한다.
따라서 확실한 캐시 무효화 응답이 필요하다.

캐시 무효화 (확실한 캐시 무효화 응답)

Cache-Control : no-cache, no-store, must-revalidate
Pragma: no-cache
- HTTP 1.0 하위 호환

1. Cache-Control : no-cache

-> 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용한다. (이름에 주의하자)

2. Cache-Control : no-store

-> 데이터에 민감한 정보가 있으므로 저장하면 안된다. (메모리에서 사용하고 바로 삭제)

3. Cache-Control : must-revalidate

-> 캐시가 만료 후, 최초 조회 시 원 서버에 검증해야 한다.

-> 원 서버 접근 실패시 반드시 오류가 발생해야 한다. (504 Gateway Timeout)

-> 통신 구조 : 클라이언트 --> 프록시 서버 --> 원서버

4. Pragma : no-cache

-> HTTP 1.0 하위 호환이므로 낮은 버전 브라우저 호환을 위해 추가해준다.

여기서 no-cache와 must-revalidate가 같은거 아닌가?

프록시캐시 --> 원서버 네트워크 단절 시 차이가 존재한다.

no-cache : 원서버에 검증을 후 클라이언트로 데이터를 보내야 하는데 네트워크가 알수 없는 문제로 순간 단절 됬으므로 우선 프록시 캐시 서버에 있는 오래된 데이터라도 보여주자. -> 200 OK

must-revalidate : 원서버에 검증을 해야 하는데 접근이 안된다. 중요한 데이터니까 항상 최신화된 데이터를 보내줘야 해! 클라이언트에 오류를 발생하자. -> 504 Gateway Timeout

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., 웹 기술을 사용하는 개발자라면 누구나 OK!꼭 필요한 HTTP의 핵심을 알려드립니다. 확인해주세요!본 강의는 자바 스

www.inflearn.com

[Spring] 웹 스코프(request scope) 와 Provider / 프록시

cornarong — Tue, 30 Nov 2021 18:41:39 +0900

웹 스코프의 특징

웹 스코프는 웹 환경에서만 동작합니다
웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료 시점까지 관리하기에 종료 메서드가 호출됩니다

웹 스코프의 종류

request : HTTP 요청 하나가 들어오고 나갈 떄 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리됩니다
session : HTTP Session과 동일한 생명주기를 가지는 스코프
application : 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프
websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프

학습 내용에 따라 requset 스코프를 기준으로 다루어 보겠습니다. 나머지는 범위만 다르고 동작 방식은 비슷합니다

그림과 같이 클라이언트 A와 B가 동시에 싱글톤 Controller에 HTTP request요청을 하였지만

requset scope인 MyLogger 호출 시 각각 A, B 전용 객체가 생성됩니다.

* 싱글톤 빈과 함께 사용시 문제점

예시로 아래와 같이 로그를 출력하는 'LogDemoController'가 있다.

해당 LogDemoController에서 'LogDemoService'는 정상적으로 의존성 주입이 되지만

'MyLogger'라는 request스코프 객체는 의존성 주입이 되지 않아 실행시 오류를 발생시킨다.

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService; // 싱글톤 스코프
    private final MyLogger myLogger; // request 스코프
    
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
    
        myLogger.log("controller test");
        logDemoService.logic("service test");
        
        return "OK";
    }
}

@Component
@Scope(value = "request")
public class MyLogger {

	// 생략
}

오류

Error creating bean with name 'myLogger': Scope 'request' is not active for the
current thread; consider defining a scoped proxy for this bean if you intend to
refer to it from a singleton;

* 발생이유

스프링 어플리케이션을 실행하는 시점에 싱글톤 빈들은 생성해서 주입해준다.

하지만 request 스코프 빈은 아직생성되지 않았기 때문에 스프링 컨테이너에서 찾을 수 없다.

request 스코프 빈은 실제 고객의 요청이 와야 생성 및 초기화 할 수 있다. (HTTP requset 요청)

즉, Scope가 request이기 떄문에 실제 생성 및 초기화 시점은 HTTP requst 시점이 된다.

해결방법으로는 두가지가 있다.

1. ObjectProvider를 사용한 Provider 방식

2. 프록시 방식(추천)

1. ObjectProvider을 이용한 방식

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService; // 싱글톤 스코프
    
    // 1. Provider 사용
    // 의존성 주입(DI) 시점에 MyLogger을 조회할 수 있는 provider을 제공 받는다.
    private final ObjectProvider<MyLogger> myLoggerProvider;
    
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
    
        // 1. Provider 사용
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("controller test");
        logDemoService.logic("service test");
        
        return "OK";
    }
}

2. 프록시를 이용한 방식

해당 request scope 객체에 proxyMode 설정만 추가해주면 된다.

적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택하고
적용 대상이 인터페이스면 INTERFACES 를 선택한다.

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {

	// 생략
}

이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

아래와 같이 컨트롤러 내부에서도 기존 싱글톤 빈을 사용하는 것 처럼 코드가 간결해진다.

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService; // 싱글톤 스코프
    private final MyLogger myLogger; // request 스코프
    
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
    
        myLogger.log("controller test");
        logDemoService.logic("service test");
        
        return "OK";
    }
}

* 프록시 방식 정리

가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고 있다.
클라이언트가 myLogger.logic() 을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.
가짜 프록시 객체는 request 스코프의 진짜 myLogger.logic() 를 호출한다.
가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다(다형성)

동작 정리

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있
고, 싱글톤 처럼 동작한다.

특징 정리

프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있
다.
사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연
처리 한다는 점이다.
단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨
테이너가 가진 큰 강점이다.
꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다.

주의점

마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워
진다.

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., 스프링 핵심 원리를 이해하고, 성장하는 개발자가 되어보세요! 수강 전

www.inflearn.com

[Spring] 빈 스코프(프로토타입 스코프 / prototype scope)

cornarong — Mon, 29 Nov 2021 22:41:30 +0900

프로토타입(prototype) 스코프

빈 스코프란?

스프링은 빈을 기본적으로 싱글톤으로 생성하기 때문에 스프링 컨테이너의 시작과 함께 생성되어 스프링 컨테이너가 종료될 때 까지 유지됩니다.

스코프는 말 그대로 빈이 유지할 수 있는 범위를 말합니다.

스프링은 다음과 같은 다양한 스코프를 지원합니다.

싱글톤 : 기본 스코프, 스프링 컨테이너의 시작부터 종료까지 유지되는 가장 넓은 범위의 스코프
프로토타입 : 스프링 컨테이너가 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더 이상 관리하지 않는 매우 짧은 범위의 스코프
웹 관련 스코프
- request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프
- session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
- application : 웹의 서블릿 컨텍스와 같은 범위로 유지되는 스코프

빈 스코프는 다음과 같이 지정할 수 있습니다.

// 컴포넌트 스캔 자동 등록
@Scope("prototype")
@Component
public class HelloBean {
}

// 수동 등록
@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
   return new HelloBean();
}

프로토타입 스코프

일반적으로 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환.

반면에 프로토타입 스코프의 빈을 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환.

프로토타입 빈 요청

1. 클라이언트가 프로토타입 스코프의 빈을 스프링 컨테이너에 요청

2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입

3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환

4. 이후에 스프링 컨테이너에 같은 요청이 오면 다시 새로운 프로토타입 빈을 생성해서 반환

여기서 핵심!

스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화 까지만 처리합니다.

* 싱글톤 스코프/프로토타입 스코프 빈 테스트

1. 싱글톤 스코프 테스트)

참고) @Component가 없는데요?
: AnnotationConfigApplicationContext에서 class를 지정해주면 해당 class를 component 자동으로 등록됩니다.

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class SingletonTest {

    @Test
    void singletonBeanFind() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class);
        
        SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);
        SingletonBean singletonBean2 = ac.getBean(SingletonBean.class);
        System.out.println("singletonBean1 = " + singletonBean1);
        System.out.println("singletonBean2 = " + singletonBean2);
        Assertions.assertThat(singletonBean1).isSameAs(singletonBean2);

        ac.close();
    }

    @Scope("singleton")
    static class SingletonBean {
        @PostConstruct
        public void init() {
            System.out.println("SingletonBean.init");
        }

        @PreDestroy
        public void destroy() {
            System.out.println("SingletonBean.destroy");
        }
    }
}

결과)

SingletonBean.init
singletonBean1 = hello.core.scope.SingletonTest$SingletonBean@409c54f
singletonBean2 = hello.core.scope.SingletonTest$SingletonBean@409c54f
22:28:40.693 [main] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - //생략
SingletonBean.destroy

순서대로 빈 초기화 메서드 실행하고, 같은 인스턴스의 빈을 조회하고, 종료 메서드까지 정상적으로 실행되었다.

2. 프로토타입 스코프 테스트)

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class prototypeTest {

    @Test
    void prototypeBeanFind() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);

        System.out.println("find prototypeBean1");
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        System.out.println("find prototypeBean2");
        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);

        System.out.println("prototypeBean1 = " + prototypeBean1);
        System.out.println("prototypeBean2 = " + prototypeBean2);
        Assertions.assertThat(prototypeBean1).isNotSameAs(prototypeBean2);

        ac.close();
        // PreDestroy 가 호출 안된다 -> 만들고 버린다.

    }
    
    @Scope("prototype")
    static class PrototypeBean {
        @PostConstruct
        public void init() {
            System.out.println("PrototypeBean.init");
        }

        @PreDestroy
        public void destroy() {
            System.out.println("PrototypeBean.destroy");
        }
    }
}

결과)

find prototypeBean1
PrototypeBean.init
find prototypeBean2
PrototypeBean.init
prototypeBean1 = hello.core.scope.prototypeTest$PrototypeBean@48d61b48
prototypeBean2 = hello.core.scope.prototypeTest$PrototypeBean@68d279ec

싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행되지만, 프로토타입 스코프의 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고, 초기화 메서드도 실행된다.
프로토타입 빈을 2번 조회 했으므로 완전히 다른 스프링 빈이 생성되고, 초기화도 2번 실행된 것을 확인할 수 있다.
싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 스프링 컨테이너가 종료될 때 빈의 종료 메서드가 실행되지만, 프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 그리고 초기화 까지만 관여하고, 더는 관리
하지 않는다. 따라서 프로토타입 빈은 스프링 컨테이너가 종료될 때 @PreDestory 같은 종료 메서드가 전혀
실행되지 않는다.

프로토타입 빈의 특징 정리

스프링 컨테이너에 요청할 때 마다 새로 생성된다.
스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화 까지만 관여한다.
종료 메서드가 호출되지 않는다.
그래서 프로토타입 빈은 조회한 클라이언트가 직접 관리해야 한다. 즉 종료 메서드에 대한 호출도 클라이언트가 직접 해야한다.

스프링 핵심 원리 - 기본편 - 인프런 | 강의