EntityManagerFactory는 애플리케이션 당 한 개를 생성하는 것이 적절하므로 @BeforeAll 설정을 통해 모든 테스트가 실행되기 전 딱 한 번 호출하도록 한다. EntityManager는 요청 단위마다 생성하는 것이 적절하므로 @BeforeEach 설정을 통해 각각의 테스트 메소드가 실행되기 전 호출하도록 한다. 각각의 테스트 메소드가 실행된 후 호출되는 @AfterEach 설정을 통해 사용했던 EntityManager 객체를 반납하고 모든 테스트가 실행 된 후 딱 한 번 호출 되는 @AfterAll 설정을 통해 EntityManagerFactory 객체를 반납하도록 한다.
public class A_EntityManagerLifeCycleTests {
private static EntityManagerFactory entityManagerFactory;
private EntityManager entityManager;
@BeforeAll
public static void initFactory() {
entityManagerFactory = Persistence.createEntityManagerFactory("jpatest");
}
@BeforeEach
public void initManager() {
entityManager = entityManagerFactory.createEntityManager();
}
@AfterAll
public static void closeFactory() {
entityManagerFactory.close();
}
@AfterEach
public void closeManager() {
entityManager.close();
}
}
테스트를 2번 실행하며 EntityManagerFactory와 EntityManager의 해시코드를 출력해 라이프 사이클을 확인한다.
엔터티 매니저는 엔터티를 저장하는 메모리상의 데이터베이스이다. 엔터티 저장, 수정, 삭제, 조회 등 엔터티와 관련된 모든 일을 한다. 엔터티 매니저는 스레드 세이프 하지 않기 때문에 동시성 문제가 발생할 수 있어 스레드 간 공유 하면 안된다. 그래서 Web의 경우 일반적으로는 request scope와 일치 시킨다.
2. EntityManagerFactory
엔터티 매니저를 생성할 수 있는 기능을 제공하는 팩토리 클래스이다. 스레드 세이프 하기 때문에 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간 공유해서 재사용한다. 스레드 세이프 한 기능을 요청 스코프마다 생성하기에는 비용(시간, 메모리) 부담이 크기 때문에 application 스코프와 동일한 싱글톤으로 생성해서 관리하게 된다. 따라서 데이터 베이스를 사용하는 애플리케이션 당 한 개의 EntityManagerFactory를 생성한다.
3. PersistenceContext
엔터티를 영구 저장하는 환경을 말한다. 엔터티 매니저에 엔터티를 저장하거나 조회하면 엔터티 매니저는 영속성 컨텍스트에 엔터티를 보관하고 관리한다. 영속성 엔터티를 key value방식으로 저장하는 저장소 역할을 한다. 영속성 컨텍스트는 엔터티 매니저를 생성할 때 하나 만들어진다. 그리고 엔터티 매니저를 통해서 영속성 컨텍스트에 접근할 수 있고 영속성 컨텍스트를 관리할 수 있다.
4. persistence.xml 생성
persistence.xml파일은 JPA의 설정 파일이다. 이 파일에는 엔티티 매니저 팩토리를 설정하기 위한 내용이 들어간다.persistence-unit엘리먼트는 엔티티 매니저 팩토리를 식별하기 위한 이름을 지정하며,properties엘리먼트는 데이터베이스 연결 정보와 hibernate 설정을 지정한다.
resources/META-INF/persistence.xml파일을 아래와 같이 생성한다.
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.2">
<!-- 엔티티 매니저 팩토리를 식별하기 위한 이름 설정 -->
<persistence-unit name="jpatest">
<properties>
<!-- 데이터 베이스 연결 정보 -->
<property name="javax.persistence.jdbc.driver" value="com.mysql.cj.jdbc.Driver"/>
<property name="javax.persistence.jdbc.user" value="{사용자 이름}"/>
<property name="javax.persistence.jdbc.password" value="{비밀번호}"/>
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://{DBMS 호스트}:{포트}/{데이터베이스 이름}"/>
<!-- hibernate 설정 (실행 되는 sql 구문을 format 형태로 보여준다) -->
<property name="hibernate.show_sql" value="true"/>
<property name="hibernate.format_sql" value="true"/>
</properties>
</persistence-unit>
</persistence>
5. JUnit
JUnit은 단위 테스트를 위한 프레임워크이다. 코드의 품질을 개선하고 유지보수성을 높이기 위해 사용된다. JUnit은 메소드 단위로 테스트를 수행하며, 예상한 결과와 실제 결과를 비교하여 테스트를 수행한다. 이를 통해 개발자들은 코드의 문제점을 발견하고 수정할 수 있게 된다.
JPA는 엔티티를 저장하는 환경인영속성 컨텍스트(Persistence Context)를 통해엔티티를 보관하고 관리한다.
엔티티(Entity) @Entity, @Table, @Id, @Column과 같은 어노테이션을 통해 SQL이 아닌 DB 테이블과 매핑되게 작성된 클래스
2. 엔티티의 영속성 컨텍스트(Persistence Context)에서의 생명주기
엔티티 메니저가 엔티티를 저장하는 공간으로 엔티티를 보관하고 관리한다.
엔티티 매니저가 생성될 때 하나의 영속성 컨텍스트가 만들어 진다.
엔티티의 생명주기
상태
설명
비영속(new/transient)
엔티티가 영속성 컨텍스트와 전혀 관계가 없는 상태
영속(managed)
엔티티가 영속성 컨텍스트에 저장된 상태
준영속(detached)
영속성 컨텍스트에 저장되었다가 분리된 상태
삭제(removed)
엔티티가 삭제된 상태
병합(merge)
엔티티가 준영속 상태인 엔티티가 다시 영속상태로 변경된 상태
3. 영속성 컨텍스트가 엔티티를 관리하는 원리
1차 캐시2
영속성 컨텍스트 내부에 Map으로 관리되는 캐시(key는@Id이며 매핑한 식별자이고 value은 엔티티 인스턴스이다.)이며 이 곳에 있는 엔티티는 캐시에서 바로 불러와서 조회 성능이 올라간다.
동일성 보장
반복해서 호출 시 1차 캐시에서 같은 엔티티 인스턴스를 가져올 수 있다.
트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
(엔티티 등록(INSERT)을 예로 들면) 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 저장(flush) 대신 쓰기 지연 SQL 저장소에 INSERT SQL을 차곡차곡 쌓게 되며 커밋 시에 쿼리를 데이터베이스로 보내는데 이를 트랜잭션을 지원하는 쓰기 지연이라고 한다.
플러시(flush):flush()는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
플러시 절차
영속성 컨텍스트에 보관할 때 최초 엔티티 상태를 복사해서 스냅샷으로 저장해 두고 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾아서 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 보낸다.
쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 저장한다.
플러시를 하는 경우
em.flush()를 직접 호출한다.
트랜잭션 커밋 시 플러시가 자동 호출한다.
JPQL 쿼리 실행 시 플러시가 자동 호출한다.
변경 감지(dirty checking)
SQL에 의존적이지 않도록 엔티티의 데이터 변경을 감지하고 데이터베이스에 자동으로 반영하는 기능을 변경 감지라고 한다. 영속성 컨텍스트에 보관할 때 최초 엔티티 상태를 복사해서 저장한 스냅샷과 이를 비교하여 감지한다. 영속 상태의 엔티티에만 적용된다.(준영속이나 비영속은 해당되지 않는다.)
자바 진영의 ORM(Object Relational Mapping) 기술 표준으로 ORM 기술을 사용하기 위한 표준 인터페이스의 모음이다.
ORM은 자바 객체와 DB테이블을 매핑하고 자바 객체간의 관계를 토대로 SQL을 생성 및 실행 할 수 있으며 대중적인 언어에는 대부분 ORM 기술이 존재한다.
JPA 2.1 기준 표준 명세를 구현한 구현체들(Hibernate, EclipseLink, DataNucleus) 중에 대부분 Hibernate를 사용하므로 JPA를 활용하기 위해서는 Hibernate를 사용하게 된다.
ORM(Object relational mapping)
객체-관계 매핑. 자바 플랫폼 SE와 EE를 사용하는 응용프로그램에서 객체는 객체 지향적으로 설계하고 관계형 데이터베이스는 관계형 데이터베이스의 패러다임대로 설계할 수 있도록 중간에서 매핑을 해주는 기술을 말한다.
2. JPA 역사
1997년 IBM에서 개발되었고 1999년에 Sun Microsystems로 인수된 EJB(Enterprise JavaBeans)라는 자바 표준이 있었는데 지저분한 코드와 느리고 제대로 동작하지도 않는 결함이 많은 기술이었다.
Gavin King이 EJB 컨테이너에 의존하지 않는 ORM 프레임워크인 Hibernate를 만들게 되고 오픈소스화가 되어 EJB는 사라지게 되었다.
이후 Java와 GavinKing이 같이 Java표준을 만들게 되었고 2006년에 JPA 1.0이라는 JPA의 초기버전이 나온 이후 현재까지 JPA는 2.1버전까지 사용되고 있다.
EJB(Enterprise JavaBeans)
비지니스로직과 시스템 서비스를 이용하는 로직을 분산하고 그 사이의 규약을 정의한 것으로 비지니스 로직을 탑제한 부분을 'Enterprise Bean'이라고 부르며 Database 및 Transaction 처리와 같은 시스템 서비스 로직을 탑제한 부분을 'Container'라고 부른다.
3. JPA의 특징
영속성 컨텍스트가 엔티티를 생명주기를 통해 관리한다.
native SQL을 통해 직접 SQL을 해당 DB에 맞게 작성할 수도 있다.
DBMS별로 dialect(방언, 사투리)를 제공한다.
4. JPA의 사용 이유
1. JPA의 장점
객체지향과 관계지향이라는 서로 다른 패러다임 불일치를 해소해 주며 SQL 중심이 아닌 객체지향 패러다임 중심의 개발이 가능하다.
개발자가 직접 SQL을 따로 작성하지 않아도 SQL문을 작성해 주므로 생산성이 향상된다.
SQL을 수정할 필요가 없으므로 설정 및 필드 변경시 SQL이 자동 수정되어 유지보수가 향상된다.
DB의 종류에 따라 SQL문에 있어 다소 차이가 있지만 JPA는 개발자 대신 이를 판단하고 해당 DB에 맞는 SQL을 작성해 준다.
캐시를 활용한 성능 최적화로 인해 트랜잭션을 처리하는 시간이 굉장히 많이 단축된다.
2. JPA의 단점
너무 복잡한 SQL을 작성하기에는 적합하지 않다.
JPA를 제대로 이해하지 못하고 작성시 성능저하가 발생할 수 있다.
객체지향 패러다임과 관계형 데이터베이스 패러다임에 대한 이해가 없는 상태로는 제대로 이해할 수 없다.
복잡한 동적 SQL같은 경우 순수 JPA만으로는 부족한 부분에 있어 추가 라이브러리를 활용해야 할 경우가 생길 수 있다.
5. 마이바티스(MyBatis)와 JPA
Mybatis는 SQL Mapper로 SQL Mapping을 사용하는 영속성(DB저장) 프레임워크이다. 개발자가 직접 SQL코드를 작성하고 객체에 대해 매핑을 위한 설정을 모두 직접 처리해야 한다. 또한, 수정이 이루어질 시 SQL뿐 아니라 매핑 될 객체까지 같이 수정해야 하는 번거로움이 있다.
JPA와 마이바티스는 분류상 서로 다르다. JPA는 ORM 기술이고, Mybatis는 SQL Mapper의 한 종류이다.
어플리케이션이 고도화 되면 JPA를 구현하여 손이 많이 가는 것 보다 Mybatis가 답이 될 수도 있다. (JPA가 무조건 좋은 것이 아니다.다만 JPA는 추가 라이브러리를 활용하면 복잡한 SQL이나 동적 SQL에 있어서 도움을 받을 수 있다.)
FormLogin() 메서드 호출 시 양식을 기반으로 인증을 활성화하는 필터로 로그인된 사용자의 url에 사용자 이름과 암호를 제출하는 로그인 양식으로 기본 로그인 페이지를 생성하게 되며 실패한 로그인 시도에 대한 사용자 정의할 수 있는 오류 메시지를 포함하는 기능을 제공하고 있다.
로그인 요청 시 기본 로그인 페이지 생성을 담당하는 필터이다.
@Bean
public SecurityFilterChain configure(HttpSecurity http) throws Exception {
http.formLogin().loginPage("/auth/login") // 해당 요청시 로그인 페이지로 이동됨
.defaultSuccessUrl("/") // 로그인 성공시 해당 페이지로 이동함
.failureUrl("/") // 로그인 실패시 해당 페이지로 이동됨
}
BasicAuthenticationFilter
기본 인증을 처리하는 Spring security에서 제공하는 필터로 기본 인증은 사용자 자격 증명(사용자 이름 및 암호)이 인코딩되어 각 요청에 HTTP 헤더로 전송되는 간단한 인증 메커니즘이다.
인증이 필요한 요청을 가로채고 기본 인증 체계로 Authorization 헤더가 있는지 확인하여 헤더가 있는 경우 필터는 인코딩된 자격 증명을 추출하여 사용자 인증을 시도한다.해당 필터는 base 64 인코딩 형식으로 자격 증명을 전송하기 때문에 HTTPS를 사용한 양식 기반 인증을 하는 것이 더욱 안전하다.
실제 인증은 AuthenticationProvider에서 담당하며 AuthenticationManger에서 구성이 되어 있다. 이러한 방식으로 BasicAuthenticationFilter를 구성하게 되면 SpringSecurity는 요청이 있을 때 Authorization 헤더에서 인코딩된 자격 증명을 추출하여 사용자 인증을 시도할 때 기본 인증 프로세스를 처리하게 된다.
해당 필터는 base 64 인코딩 형식으로 자격 증명을 전송하기 때문에 HTTPS를 사용한 양식 기반 인증을 하는 것이 더욱 안전하다.
public class BasicAuthenticationCustomFilter extends BasicAuthenticationFilter{
// 로직 작성
}
http.addFilter(new BasicAuthenticationCustomFilter()) // 필터 커스텀
RememberMeAuthenticationFilter
세션이 만료된 사용자에게 Remember-me 토큰을 기반으로 사용자를 자동으로 인증할 수 있도록 한다.
해당 필터를 구현하게 되면 RememberMeServices를 상속받아 구현해야 하며 토큰 유효성 검사 및 인증 설정을 해주어야 한다. PersistentTokenBasedRememberMeServices 구현이 사용되며 UserDetailService 구현이 필요하다.
해당 필터는 적절한 보안 조치가 필요하며 토큰은 애플리케이션의 보안을 보장하기 위해 안정하게 저장되고 적절하게 검증되어야 한다.
public class RememberMeAuthenticationCustomFilter extends RememberMeAuthenticationFilter {
// 로직 작성
}
http.addFilter(new RememberMeAuthenticationCustomFilter ()) // 필터 커스텀
SecurityContextHolderAwareRequestFilter
HttpServletRequest 에 액세스하는 컨트롤러 또는 기타 필터와 같은 후속 구성 요소에서 보안 컨텍스트를 사용할 수 있으며 해당 구성 요소가 보안 컨텍스트에서 현재 사용자의 인증 및 권한 부여 정보를 검색할 수 있다.
애플리케이션이 활성화 되어 있을 때 Security에 의해 자동으로 추가된다.
HttpServletRequest 에 SecurityContextHolder를 설정하는 필터로 현재 보안 컨텍스트를 인식하도록 보장하는 Spring Security에서 제공하는 필터이다. 텍스트를 인식하도록 보장하는 Spring Security 에서 제공하는 필터로 사용자 요청에 대한 보안 컨텍스트를 설정하여 후속 처리 구성 요소가 보안 정보에 액세스할 수 있도록 한다.
public class SecurityContextHolderAwareRequestCustomFilter extends SecurityContextHolderAwareRequestFilter{
// 로직 작성
}
http.addFilter(new SecurityContextHolderAwareRequestCustomFilter()) // 필터 커스텀
AnonymousAuthenticationFilter
익명 사용자에게 인증을 요구하지 않고 애플리케이션에 특정 부분을 액세스할 수 있도록 하는 filter이다.
익명 사용자의 인증 정보를 관리하는 객체는 AnonymousAuthenticationToke 구성되어 있으며 기본 설정으로 이름은 anonymous User 권한 및 역할로 Granted Authority 목록을 생성하여 ROLE_ANONYMOUS로 익명 사용자에게 할당된다.
인증 객체를 생성하여 다른 인증이 설정되지 않으면 SecurityContextHolder 에 설정하는 역할을 하게 된다.
public class AnonymousAuthenticationCustomFilter extends AnonymousAuthenticationFilter{
// 로직 작성
}
http.addFilter(new AnonymousAuthenticationCustomFilter ()) // 필터 커스텀
sessionManagementFilter
사용자의 요청에 따라 세션을 효과적으로 관리하기 위해서 사용하는 필터이다.
사용자의 세션을 관리하는 필터로 새로운 세션을 생성하거나 무효화, 고정 세션 공격 보호 등 세션의 동시성 제어를 포함한 세션 정책을 시행하게 된다.
public class sessionManagementCustomFilter extends sessionManagementFilter{
// 로직 작성
}
http.addFilter(new sessionManagementCustomFilter()) // 필터 커스텀
http..sessionManagement() // 세션 설정을 해주겠다는 메소드
.maximumSessions(1) // 동일 세션으로 1명의 사용자만 로그인 허용
.expiredUrl("/") // 이미 로그인이 되어 세션 생성에 제한이 되었을 경우 리다이렉트 할 주소
.maxSessionsPreventsLogin(false); // boolean 값으로 false : 이전 사용자의 강제 로그아웃 true : 신규 사용자의 로그인 실패
ExceptionTranslationFilter
액세스가 거부될 때 인증 프로세스를 시작하는 역할을 하는 AuthenticatiojnEntryPoint의 인스턴스로 구성되어 있다. 인증 및 권한 부여 관련 예외를 포착하여 로그인 페이지로 리다이렉션을 하거나 오류를 반환하는 것과 같은 응답을 트리거하도록 되어 있다.
인증 및 권한 부여 프로세스 중에 발생하는 예외를 포착하여 이를 로그인 페이지로 리다이렉션 처리하거나 오류 응답을 반환하는 것과 같은 적절한 변환을 하는 역할을 하게 된다.
public class ExceptionTranslationCustomFilter extends ExceptionTranslationFilter{
// 로직 작성
}
http.addFilter(new ExceptionTranslationCustomFilter()) // 필터 커스텀
http.exceptionHandling()
.accessDeniedPage("/access-denied") // Exception 발생시 이동할 페이지
FilterSecurityInterceptor
보안 규칙을 기반으로 액세스 제어를 수행하는 SpringSecurity에서 제공하는 키 필터이다. 권한 부여 규칙을 적용하고 사용자가 특정 리소스에 액세스하거나 특정 작업을 수행할 수 있는지를 결정하게 된다. FilterSecurityInterceptor는 SpringSerucity 필터 체인에 있으며 보호된 리소스에 도달하기 전에 요청을 가로채게 된다.
정의된 보안 구성에 대한 요청된 url 및 관련 HTTP 메서드를 평가하여 사용자가 진행할 수 있는 권한이 있는지 확인한다.
public class FilterSecurityCustomInterceptor extends FilterSecurityInterceptor{
// 로직 작성
}
http.addFilter(new FilterSecurityCustomInterceptor()) // 필터 커스텀
http.authorizeRequests()
.antMatchers("/public").permitAll() // 해당 요청은 모두가 사용이 가능함
.anyRequest().authenticated()
인증된 사용자의 로그아웃 프로세스를 처리하는 Spring Security 필터이다. 로그아웃 요청을 가로채고 세션 무효화, 인증 지우기, 지정된 로그아웃 성공 url로 리다이렉션과 같이 사용자를 로그아웃하는데 필요한 작업을 수행한다.
사용자 인증 취소 : contextHolder에서 사용자 인증을 삭제하여 사용자를 로그아웃
사용자 세션 무효화 : http 세션과 연결된 경우 logoutFilter는 해당 세션을 무효로 하여 사용자가 세션 내에서 더 이상 인증되지 않도록 할 수 있다.
로그아웃 관련 작업 수행 : LogoutFilter는 쿠키 지우기, Remember-me 토큰 제거 또는 사용자 정의 로그아웃 핸들러 호출과 같은 추가 작업을 실행할 수 있다.
http
// ...
.logout()
.logoutUrl("/logout") // Configure the logout URL
.logoutSuccessHandler(logoutSuccessHandler) // Specify the LogoutSuccessHandler implementation
.and()
// ...
// Add the LogoutFilter to the filter chain
http.addFilterBefore(new LogoutFilter(logoutSuccessHandler, new SecurityContextLogoutHandler()), LogoutFilter.class);
UsernamePasswordAuthenticationFilter
사용자 이름과 암호를 포함하는 인증 요청 처리를 하기 위해 Spring security에서 제공하는 핵심 구성 요소이다. 요청을 가로채고 제공된 자격 증명을 사용해서 사용자의 인증을 시도하게 된다. 사용자 인증을 위해 AuthenticationManager에서 인증 절차를 진행하게 된다.
public class UsernamePasswordAuthenticationCustomFilter extends UsernamePasswordAuthenticationFilter {
// 로직 작성
}
http.addFilter(new UsernamePasswordAuthenticationCustomFilter()) // 필터 커스텀
Autorization & Authentication인가를 위해서 Principal을 아이디로, Credential을 비밀번호로 사용하는 Credential 기반의 인증 방식을 사용하게 된다.
Authentication(인증) : 해당 사용자가 본인이 맞는지를 확인하는 절차
Autorization(인가) : 인증된 사용자가 요청한 자원에 접근 가능한지를 결정하는 절차
접근 주체 (Principal) : 보호받는 Resource에 접근하는 대상
비밀번호 (Credential) : Resource에 접근하는 대상의 비밀번호
Spring security는 인증 절차를 거친 후에 인가 절차를 진행하게 되며 인가 과정에서 해당 리소스에 대한 접근 권한이 있는지를 확인하게 된다.
UsernamePasswordAuthenticationToken
RememberMeAuthenticationToken
JwtAuthenticationToken
OAuth2AuthenticationToken
해당 클래스는 Spring Security에서 제공하는 Authentication 인터페이스의 특정 구현이다. 사용자 이름과 암호를 자격 증명으로 포함하는 인증 요청을 나타낸다. 클래스는 사용자의 이름 및 암호 기반 인증을 수행할 때 사용자의 자격 증명을 캡슐화하는데 사용되며 일반적으로 인증 프로세스 중에 생성되며 인증을 위해 인증 관리자에게 전달된다. 해당 토큰은 인증을 위해 관리자에게 전달되며 일반적으로 사용자 데이터베이스 또는 기타 인증 메커니즘에 대해 자격 증명을 유효성 검사를 진행한다. 인증에 성공하면 인증된 Authentication 개체가 반환되며 이 개체는 securityContextHolder에서 설정하여 보안 컨텍스트 내에서 사용자의 인증을 설정할 수 있다. 이외로 다음과 같은 클래스를 활용할 수 있다.
AuthenticationMananger
해당 인터페이스는 Authentication 객체 인증을 담당하는 Spring Security의 핵심 구성 요소로 사용자 자격 증명의 유효성을 검사하고 보안 컨텍스트 내에서 사용자의 id를 설정하는데 사용된다. AuthenticationManager 인터페이스의 기본 메소드는 authenticate(Authentication authentication)이다. 이 매서드는 Authentication 개체를 입력으로 사용하고 인증 프로세스를 수행하고 인증에 성공하면 Authentication 개체를 반환하고 인증에 실패하면 예외를 throw한다.
ProviderManagerProviderManager는 복합 인증 공급자 역할을 진행하게 되며 즉, AuthenticationProvider 인스턴스 목록을 보유하고 주어진 인증 요청에 대하여 적절한 인증 객체를 찾기 위해 반복한다. ProviderManager의 Authenticate 메서드가 호출되면 해당 목록의 각 AuthenticationProvider에 인증 요청을 순차적으로 위임하며 각 공급자는 인증 요청에 따라 특정 인증 논리를 수행한다. 공급자가 요청을 성공적으로 인증하면 인증된 Authentication 개체를 반환하여 공급자가 요청을 인증할 수 없는 경우 null을 반환하게 된다. AuthenticationException을 발생시킨다.
Spring Security의 AuthenticationManager 인터페이스 구현으로 인증 요청을 AuthenticationProvider 구현 체인에 위임하는 핵심 구성 요소이다.
UserDetailsService
인증 프로세스 중에 사용자별 데이터를 로드하는 Spring Security의 핵심 구성 요소로 백엔드 데이터 소스에서 사용자 아이디, 암호 및 권한과 같은 사용자 세부 정보를 검색하는데 사용하게 된다. 인터페이스의 기본 메서드는 사용자 이름을 입력으로 사용하고 개체를 반환하는 UserDetailsService이다. 개체는 사용자의 세부 정보를 나타내며 인증 및 권한 부여 목적으로 사용된다. loadUserByUsername(String username)을 상속받아서 사용한다. 해당 예제에서 CustomUserDetailsService 클래스 인터페이스를 구현한다. userDetailsService 메서드 loaUserByUsername 일반적으로 데이터베이스 LDAP 서버 또는 기타 사용자 리포지토리와 같은 데이터 소스에서 사용자 세부 정보를 검색한다. userDetails 사용자가 발견되면 사용자의 세부 정보를 나타내는 개체를 만들고 반환한다. 인터페이스 UserDetails는 사용자 이름, 암호(인코딩됨) 및 GrantedAuthority 사용자의 권한이나 역할을 나타내는 객체 모음을 검색하기 위한 메서드를 제공한다.
UserDetails
메서드
getUsername() : 사용자의 이름을 반환
getPassword() : 사용자의 비밀번호를 반환한다.
getAuthorities() : 사용자와 관련된 권한 또는 역할 나타내는 GrantedAuthority 객체 모음이다.
isEnabled() : 사용자 계정의 활성화 또는 비활성화 여부를 나타낸다.
isAccountNonExpired() : 사용자의 계정이 만료되었는지 여부를 나타낸다.
isAuccountNonLocked() : 사용자 계정이 잠겨 있는지 여부를 나타낸다.
iscredentialsNonExpired() : 사용자의 자격 증명(암호) 만료 여부를 나타낸다.
인터페이스는 핵심 사용자 정보를 나태는 객체로 사용자 이름, 암호, 권한 및 사용자의 관련 속성을 포함하여 사용자에 대한 세부 정보를 캡슐화 하여 관리한다. UserDetails 개체는 일반적으로 인증 중인 사용자를 나타내기 위해 인증 프로세스 중에 사용되며 userDetails 인터페이스에서 제공하는 몇 가지 중요한 특성 및 메서드이다.
SecurityContextHolder
SecurityContextHolder의 주요 역할
보안 컨텍스트 : SecurityContextHolder는 현재 사용자의 보안 관련 정보를 보유하는 SecurityContext 객체를 유지한다.
보안 컨텍스트 모드 : securityContextHolder는 보안 컨텍스트를 관리하기 위해 다양한 모드를 지원한다.
MODE_THREADLOCAL : 이 모드에서 보안 컨텍스트는 ‘ThreadLocal’을 사용하여 현재 스레드에 바인딩 된다. 각 스레드에는 자체 보안 컨텍스트가 있으며 다른 스레드에서 코드를 실행할때 컨텍스트가 자동으로 전파된다.
MODE_INHERITABLETHREADLOCAL : MODE_THERADLOCAL과 유사하지만 보안 컨텍스는 원래 스레드에서 생성된 자식 스레드에 의해 상속된다.
보안 컨텍스트 설정 : 정적 SecurityContextHolder.setContext(SecurityContext context) 메서드를 사용하여 보안 컨텍스트를 설정하는 것이 가능하다. 일반적으로 이는 수동 또는 AuthenticationManager 또는 UserDetailsService와 같은 Spring Security 구성 요소에 의해 성공적인 인증 후에 수행된다.
보안 컨텍스트 검색: 현재 보안 컨텍스트는 SecurityContext 개체를 반환하는 정적 SecurityContextHolder.getContext() 메서드를 사용하여 액세스하는 것이 가능하다. SecurityContext에서 권한과 함께 인증된 사용자를 나타내는 Authentiacation 객체를 얻는 것이 가능하다.
보안 컨텍스트 지우기 : 보안 컨텍스트를 정리하면 정적 SecurityContextHolder.cleacontext() 메서드를 호출학 되며 이것은 일반적인 로그아웃 중 혹은 보안 컨테스트가 더 이상 필요하지 않을 때 수행된다.
애플리케이션 내에서 현재 사용자의 보안 컨텍스트에 대한 액세스를 제공하는 중앙 구성 요소이다. 인증된 사용자 세부 정보 및 부여된 권한과 같은 보안 관련 정보를 저장하고 액세스하는 컨테이너 역할을 하게 된다. Security 프레임워크의 일부이며 보안 컨텍스트와 상호 작용하는 정적 메서드를 제공한다.
Spring Security는 스프링 기반 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 프레임워크이다.
Security는 인증과 권한에 대한 부분을 Filter의 흐름에 따라서 처리를 하게 되며 보안과 관련된 옵션을 체계적으로 제공해주기 때문에 개발자가 일일이 보안과 관련된 로직을 작성하지 않아도 되는 장점을 가지고 있다.
용어 정의
Principal : 접근 주체(= 아이디)
사용자, 디바이스, 시스템 등의 행위를 하는 주체를 의미
Credential : 자격 증명(=비밀번호)
Secured Resource : 보안이 적용되는 리소스
일반적으로 메서드를 통해 보호가 된다.
Authentication : 인증
Principal이 믿을 수 있는지 파악하는 것으로 일반적으로 id/password를 검사하게 된다.
Authorization : 인가
인증이 완료된 principal이 어떤 행위를 할 권한이 있는지 확인한다.
ROLE_ADMIN, ROLE_GUEST, ROLE_MEMBER의 role에 기반해서 접근이 가능하다.
Authority, Role : 권한
리소스에 대한 접근 제한. 모든 리소스는 접근 제어 권한이 존재한다.
2. Security 기능
인증 및 접근 제어
사용자의 인증과 접근 제어를 처리하여 인증되지 않는 액세스를 방지한다. 사용자의 자격 증명을 확인하고 권한 부여 및 접근 권한 검사를 수행하여 인가된 사용자만 보호된 리소스에 액세스가 가능하다.
CSRF(Cross-Site-Request Forgery) 방어
csrf 공격을 방지하기 위해 요청에 csrf 토큰을 추가하고, 이를 사용하여 유효한 요청인지 검증을 하게된다. 이를 통해 악성 사용자의 요청 위조를 방지할 수 있다.
XSS(Cross-Site Scripting) 방어 : XSS 공격을 방지하기 위해 출력 데이터의 이스케이프 처리를 제공하고 있으며 이를 통해 악성 스크립트가 삽입되는 것을 방지하고 사용자의 브라우저에서 안전하게 실행을 보장한다.
세션 관리 :Spring Security는 세션 관리를 통해 세션 하이재킹 및 세션 고정 공격을 방지한다. 적절한 세션 id 생성, 세션 유효성 검사, 세션 제한 시간 설정 등의 기능을 제공하여 세션의 안전성을 강화한다.
보안 헤더 설정 : Spring Security는 보안 헤더를 설정하여 다양한 보안 취약점을 방지한다. Content Security Policy (CSP), X-Content-Type-Options, X-XSS-Protection 등의 헤더를 설정하여 악성 스크립트 실행, mime 타입 스니핑을 방지한다.
로그인 실패 및 계정 잠금 : Spring Security는 로그인 실패 횟수 제한, 계정 잠금등의 기능을 제공하여 무차별 대입 공격 및 계정 탈취를 방지한다.
보안 취약점 패치 : 보안 취약점에 대한 업데이트와 패치를 지속적으로 제공하여 애플리케이션의 보안을 유지하고 개선한다. 취약점에 대한 경고 및 권장 사항을 제공하여 개발자가 적절한 조치를 취할 수 있도록 한다.
3. 웹 해킹 종류
CSRF (Cross-Site Request Forgery)
공격 흐름
피해자가 악의적인 웹사이트 방문
악의적인 웹사이트는 피해자의 브라우저에 실제로 수행되어야 하는 요청에 위조하여 피해자 사이트로 전송한다.
피해자의 브라우저는 위조된 요청을 실행하고, 이때 피해자의 세션 인증 정보가 함께 전송된다.
서버는 피해자의 세션 인증 정보를 확인하여 해당 요청을 처리하게 되어 악의적인 동작을 실행한다.
Security의 CSRF 공격 방지를 위한 기능
CSRF 토큰 : CSRF 토큰을 포함해 위조된 요청인지 확인한다. 서버는 요청을 처리하기 전에 토큰의 일치 여부를 확인하여, 일치하지 않는 경우 요청을 거부
CSRF 헤더 : X-CSRF-Token 이라는 이름의 헤더를 요청에 추가하여 CSRF 공격을 방지한다. 클라이언트는 서버에서 받은 토큰을 헤더에 포함해 요청 시 전송하며 서버는 이를 확인하여 변조를 확인
CSRF 보호 설정 : CSRF 보호 설정을 활성화할 수 있으며 이를 통해 기본적인 CSRF 보호 기능을 제공하여, 토큰 생성, 토큰 저장소, 토큰 전송 방식 등을 구성할 수 있다.
악의적인 사용자가 피해자의 인증된 세션을 이용하여 비정상적인 요청을 실행하는 공격 형태이다. 공격자는 사용자가 이미 인증된 세션을 가지고 있을 때, 피해자가 의도하지 않은 동작을 수행하도록 요청을 위조한다.
XSS
Stored Xss
저장형 xss 공격은 보안이 취약한 서버에 악의적인 사용자가 악성 스크립트를 저장함으로써 발생하며 비정상적인 방법이 아닌 서버에서 제공하는 게시판, 사용자 프로필에 악의적으로 동작하는 스크립트가 그대로 저장된 후 클라이언트의 브라우저로 전달되어 문제가 발생하게 된다.
Refiected Xss
요청 메시지에 입력된 스크립트 코드가 즉시 응답 메시지를 통해 출력되는 취약점으로 입력된 스크립트가 반사되는 것처럼 동작하기 때문에 붙은 이름이다.
SQL INJECTION과 함께 웹상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법을 말하며 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게 되어 의도하지 않은 행동을 수행하게 되거나 쿠키 및 세션 등 민감한 정보를 탈취당하게 된다. 크로스 사이트 스크립팅은 자바스크립트를 사용하여 공격하는 경우가 많으며 공격 방법이 단순하고 가장 기초적이나 많은 웹사이트가 xss에 대한 방어 조치를 하지 않아 공격받는 경우가 많으며 여러 사용자가 접근할 수 있는 게시판 등에 코드를 삽입하는 경우가 많으며 때에 따라서는 메일과 같은 매체를 통해서 전파된다. 공격 방법에 따라 명칭이 분류되며 다음과 같은 기법이 있다.
세션 하이제킹
공격 흐름
사용자 세션 생성됨
사용자가 웹 애플리케이션이나 서비스에 로그인하면 서버에 세션이 생성된다. 서버는 고유한 세션 식별자(세션 쿠키)를 클라이언트 측에 저장되는 사용자 세션에 할당하게 된다.
세션 토큰 교환
사용자의 브라우저와 서버 간의 후속 상호 작용 중에 클라이언트는 요청을 인증하고 서버에 올바른 세션과 연결하기 위해 http 요청에 세션 식별자를 쿠키에 포함한다.
세션 가로채기
공격자는 네트워크 트래픽 스니핑, 맬웨어 사용 또는 중간자 공격 실행과 같은 네트워크의 취약성을 악용하여 세션 식별자를 가로채게 된다.
세션 하이재킹
공격자가 세션 식별자를 획득하면 이를 사용하여 사용자 세션을 가장 할 수 있으며 세션 식별자를 직접 사용하거나 자신의 브라우저 또는 스크립트에 삽입하여 대상 세션에 대한 무단 액세스를 얻을 수 있다.
하이재킹된 세션 악용
공격자는 하이재킹된 세션을 제어하여 손상된 세션과 관련된 권한 및 기능에 따라 다양한 악의적인 작업을 수행할 수 있다. 여기에는 민감한 정보 도용, 무단 거래 수행 또는 사용자 계정 설정 조작이 포함됨
세션 하이재킹 또는 세션 도용이라 불리는 공격은 공격자가 컴퓨터 네트워크에서 사용자의 세션을 장악하려고 시도하는 보안 공격이다. 이 공격에서 공격자는 인증 및 세션 관리에 사용되는 세션 토큰 또는 세션 식별자를 가로채고 조작하여 사용자 세션에 대한 무단 액세스 권한을 얻는 것을 목표로 한다.
세션 고정공격
공격 흐름
초기 세션 식별자
공격자는 세션 식별자 또는 토큰을 생성하고 사용자가 이를 인증에 사용하도록 속인다.
사용자 인증
사용자가 악성 링크를 클릭하여 웹 애플리케이션 또는 서비스에 액세스한다. 응용 프로그램은 공격자가 제공한 세션 식별자를 합법적인 세션으로 받아들인다.
세션 하이재킹
사용자가 인증되면 공격자는 고정된 세션 식별자를 악용하여 사용자 세션에 대한 무단 액세스 권한을 얻을 수 있다. 네트워크 트래픽을 가로채거나 XSS 취약점을 활용하는 등 다양한 방법을 사용하여 세션을 하이재킹할 수 있다.
하이재킹된 세션 악용
공격자는 세션을 제어하여 사용자를 대신해 악의적인 활동을 수행하게 됨
공격자가 미리 결정된 세션 식별자 또는 세션 토큰을 사용하도록 사용자를 속이는 보안 공격 유형이다. 이 공격은 사용자가 공격자가 제어하는 세션으로 인증하도록 강제하여 사용자의 브라우저와 웹 응용 프로그램 간의 신뢰를 악용하는 것이다.
Content Security Policy (CSP)
콘텐츠 보안 정책은 xss 및 데이터 주입과 같은 다양한 유형의 공격을 완화하고 보호하기 위한 웹 애플리케이션에서 구현하는 보안 메커니즘으로 csp는 웹 개발자가 웹 페이지를 로드하고 실행할 수 있는 콘텐츠를 지정하는 일련의 규칙 또는 정책을 정의하고 시행할 수 있도록 해주는 http 헤더이다.
X-Content-Type-Options
"nosniff": 이 지시문이 "nosniff" 값이 있는 헤더에 포함된 경우(예: "X-Content-Type-Options: nosniff") 브라우저가 선언된 콘텐츠 유형을 엄격하게 준수하도록 지시합니다. 응답하고 콘텐츠 유형 스니핑을 수행하지 않습니다. 서버가 콘텐츠 유형을 지정하면 브라우저는 이를 신뢰할 수 있는 값으로 취급하고 콘텐츠 유형을 추측하려고 시도하지 않습니다.
"none": 이 지시문은 더 이상 사용되지 않으며 사용해서는 안 됩니다. 이전에는 MIME 스니핑을 완전히 비활성화하는 데 사용되었습니다. 그러나 이제 동일한 효과를 얻기 위해 "nosniff" 지시어를 사용하는 것이 좋습니다.
브라우저 응답의 콘텐츠 유형을 해석하는 방법을 제어하기 위해 웹 서버에서 사용할 수 있는 http 응답 헤더이다. 브라우저가 선언된 콘텐츠 유형에 의존하는 대신 응답 콘텐츠 유형을 추측하고자 할 때 발생하는 mime 스피닝 공격에서 보호하는 데 도움이 되는 보안 헤더이다.
X-XSS-Protection
"0": 브라우저에서 XSS 보호 기능을 비활성화합니다. 브라우저는 XSS 공격을 감지하거나 차단하려고 시도하지 않습니다.
"1": 브라우저에서 XSS 보호 기능을 활성화합니다. 브라우저가 잠재적인 XSS 공격을 감지하면 악성 스크립트를 차단하고 페이지를 실행하지 않고 렌더링하려고 시도합니다.
"1; mode=block": 브라우저에서 XSS 보호 기능을 활성화하고 잠재적인 XSS 공격이 감지되면 페이지가 차단되도록 합니다. 이 지시문은 더 엄격하며 공격이 의심되는 경우 페이지가 렌더링 되지 않도록 합니다.
XSS-Protection은 최신 웹 브라우저에 제공하는 내장 xss 보호 메커니즘을 활성화 또는 비활성화하기 위해 웹 서버에서 사용할 수 있는 HTTP 응답 헤더이다. XSS 공격은 공격자가 악의적인 스크립트를 웹 페이지에 삽입한 뒤 다음 다른 사용자의 브라우저 컨텍스트에 실행되어 잠재적으로 무단 액세스 또는 데이터 도난으로 이어질 때 발생한다. X-XSS-Protection 헤더를 통해 웹 개발자는 브라우저의 XSS 보호 기능 동작을 제어할 수 있으며 다음과 같은 방식을 사용한다.
스니핑
스니핑 종류
패킷 스니핑
개별 네트워크 패킷 캡처와 검사가 포함되며 네트워크 인터페이스를 무차별 모드로 설정하면 스니퍼 도구 또는 소프트웨어가 네트워크의 다른 장치로 향하는 패킷을 캡처하여 사용자가 포함된 데이터를 분석
이더넷 스니핑
이더넷 스니핑은 특히 이더넷 네트워크를 통한 데이터 전송의 기본 단위인 이더넷 프레임 캡처 및 분석에 중점을 둔다. 네트워크 모니터링 또는 보안 분석에 활용
무선 스니핑
wi-fi 스니핑이라고 하는 무선 스니핑에는 무선 네트워크 트래픽 캡처 및 분석이 포함된다. 올바른 도구와 기능을 사용하면 공격자 또는 보안 전문가가 장치 간의 무선 통신을 가로채 무선으로 전송되는 패킷을 캡처한다.
네트워크 트래픽
네트워크 통신 패턴, 흐름 및 콘텐츠 모니터링 및 검사가 포함된다. 패턴을 분석하고 이상을 식별하여 보안 전문가는 네트워크 내에서 잠재적인 위협이나 비정상적인 동작을 탐지한다.
컴퓨터 네트워크 및 보안의 맥락에서 스니핑은 분석 또는 승인되지 않는 목적을 위해 네트워크 트래픽을 가로채고 캡처하는 행위를 이야기한다. 여기서 데이터 패킹이 네트워크를 통과할 때 캡처하여 공격자나 승인된 엔티티가 패킷의 내용을 검사 할 수 있도록 한다. 네트워크 스피닝은 이를 수행하는 개인의 상황과 의도에 따라 합법적일 수 있고 악의적일 수 있다.
변수 표현식의 OGNL을 활용한 조건식으로 조건문을 작성하면 결과가 true일 때 해당 태그 범위가 처리된다.
else문
th:unless="${ONGL을 통한 조건식}"
변수 표현식의 OGNL을 활용한 결과가 false일 때 해당 태그 범위가 처리된다.
다중조건처리문
th:if="${ONGL을 통한 조건식 and ONGL을 통한 조건식...}"
변수 표현식의 OGNL을 활용한 조건식들과 and 또는 or를 통해 다중 조건문을 작성하고 결과가 true일 때 해당 태그 범위가 처리된다.
switch문
th:swith="${...}과 th:case="리터럴"
th:switch와 th:case를 통해 해당 조건의 값이 어떤 case에 해당되는지에 따라 태그를 선택할 수 있다.
each문
th:each="변수 : ${collection값}"
컬렉션에 해당하는 값들을 하나씩 변수에 담아 collection의 크기만큼 반복하여 태그를 처리한다.
if문 / else문 / 다중조건처리문
// ModelAndView의 Model에 추가
mv.addObject("num", 1);
mv.addObject("str", "바나나");
<p th:if="${ num > 0 }">넘어온 값은 0보다 크다.</p> <!-- 조건에 해당되면 -->
<p th:if="${ num < 0 }">넘어온 값은 0보다 작다.</p>
<p th:unless="${ num < 0 }">넘어온 값은 0보다 크다.</p> <!-- 조건에 해당하지 않으면 -->
<th:block th:if="${ str == '사과' }"> <!-- th:block을 사용할 수도 있다. -->
<p>사과 좋아요!</p>
</th:block>
<th:block th:if="${ str == '바나나' }">
<p>바나나 좋아요!</p>
</th:block>
<!-- and나 or를 사용해서 다중 조건 처리도 가능하다. -->
<p th:if="${ num > 0 or num <= 10 }">1부터 10까지의 양수</p>
<p th:if="${ str != null and str == '바나나' }">바나나 좋아요!</p>
<!-- #strings라는 타임리프에서 제공하는 Utility Objects에서 제공하는 메소드를 통해서도 null에 대한 처리를 할 수 있다. -->
<p th:if="${ !#strings.isEmpty(str) and str == '바나나' }">바나나 좋아요!</p>
switch문
// ModelAndView의 Model에 추가
mv.addObject("str", "바나나");
변수 표현식(${...})에서 SpringEL을 사용하여 단순한 변수가 아닌 Object, List, Map같은 객체의 값들을 불러올 수 있다.
종류
문법
설명
Object
${객체명.속성명}
해당 객체의 속성값을 불러온다.
${객체명['속성명']}
${객체명.속성의 getter()}
List
${List객체명[index번째 객체].속성명}
List에서 index번째 객체의 속성을 불러온다.
${List객체명[index번째 객체]['속성명']}
${List객체명[index번째 객체].속성의 getter()}
${List객체명.get(index번째 객체).속성의 getter()}
${List객체명.get(index번째 객체).속성명}
Map
${Map객체명['객체의 키값']['속성명']}
Map에서 키값에 해당하는 객체의 속성을 불러온다.
${Map객체명['객체의 키값']['속성명']}
${Map객체명['객체의 키값'].속성의 getter()}
// ModelAndView의 Model에 추가 (name, age, gender, address)
MemberDTO member = new MemberDTO("홍길동", 20, '남', "서울시 서초구");
mv.addObject("member", member);
List<MemberDTO> memberList = new ArrayList<>();
memberList.add(new MemberDTO("홍길동", 20, '남', "서울시 서초구"));
memberList.add(new MemberDTO("유관순", 22, '여', "서울시 노원구"));
memberList.add(new MemberDTO("장보고", 40, '남', "서울시 종로구"));
memberList.add(new MemberDTO("신사임당", 30, '여', "서울시 성북구"));
mv.addObject("memberList", memberList);
Map<String, MemberDTO> memberMap = new HashMap<>();
memberMap.put("m01", new MemberDTO("홍길동", 20, '남', "서울시 서초구"));
memberMap.put("m02", new MemberDTO("유관순", 22, '여', "서울시 노원구"));
memberMap.put("m03", new MemberDTO("장보고", 40, '남', "서울시 종로구"));
memberMap.put("m04", new MemberDTO("신사임당", 30, '여', "서울시 성북구"));
mv.addObject("memberMap", memberMap);
<p>Object</p>
<ul>
<li th:text="${ member.name }"></li>
<li th:text="${ member['age'] }"></li>
<!-- 위 두가지 방식은 getter가 필요 없지만 getGender()는 반드시 해당 클래스에 getter가 있어야 한다. -->
<li th:text="${ member.getGender() }"></li>
</ul>
<p>List</p>
<ul>
<li th:text="${ memberList[1].name }"></li>
<li th:text="${ memberList[1]['age'] }"></li>
<!-- 위 두가지 방식은 getter가 필요 없지만 getGender()는 반드시 해당 클래스에 getter가 있어야 한다. -->
<li th:text="${ memberList[1].getGender() }"></li>
<li th:text="${ memberList.get(1).getGender() }"></li>
<li th:text="${ memberList.get(1).address }"></li>
</ul>
<p>Map</p>
<ul>
<li th:text="${ memberMap['m03'].name }"></li>
<li th:text="${ memberMap['m03']['age'] }"></li>
<!-- 위 두가지 방식은 getter가 필요 없지만 getGender()는 반드시 해당 클래스에 getter가 있어야 한다. -->
<li th:text="${ memberMap['m03'].getGender() }"></li>
</ul>
변수 표현식의 값을 불러오지만 escape가 적용되어 태그를 단순 문자열로 처리하고 html에 표현한다.
escape 미적용
th:utext="${...}"
변수 표현식의 값을 불러오지만 escape가 적용되지 않아 태그를 태그로써 인식하게 처리하고 html에 표현한다.
value 속성 적용
th:value="${...}"
변수 표현식의 값을 불러와 태그의 value값을 지정한다.
리터럴 치환
th:text=”|리터럴${…}리터럴|”
‘| ‘를 양 옆에 사용하면 ‘+’를 쓰지 않고 문자열 합치기를 할 수 있다.
블럭태그
th:block
범위를 지정하고 싶을 때 사용한다. th:block을 통해 해당 범위에 변수나 객체를 적용하거나 조건에 해당되는지에 따라 해당 범위를 보여주거나 보여주지 않을 때 사용할 수 있다.
지역변수
th:with="변수명1 = ${...}, 변수명2 =${...}, ..."
변수 표현식(${...})을 통해 불러온 값을 해당하는 변수명으로 해당 태그 범위의 지역변수가 되게 한다.
security 인증 정보 여부
sec:authorize="isAuthenticated()”
타임리프에서 시큐리티 적용 시 로그인, 로그아웃에 대한 이벤트를 줄 수 있다.
타임리프 네임스키마
<html xmlns:th="http://www.thymeleaf.org">
escape 적용/미적용, value 속성 적용
태그의 값을 태그 내부의 값으로 작성하기 위해서는 th:text 또는 th:utext를 사용할 수 있다. th:text는 escape가 적용되어 태그를 단순 문자열로 처리하지만 th:utext는 escape가 적용되지 않아 태그를 태그로써 인식할 수 있다. (DB에 태그가 포함된 문자열을 저장했을 시 유용
th:value는 태그의 value값을 지정할 수 있다.
// ModelAndView의 Model에 추가
mv.addObject("hello", "hello!<h3>Thymeleaf</h3>");