import spock.lang.Specification
class UpdateBizFleetOrderVinsToPurchasedHandlerTest extends Specification {
}
* 이때, 주의할 점은 클래스를 ctrl + command + T 로 만들 때, 기존에 Test Library JUnit으로 사용하시던 분들은 Groovy로 바꿔줘야 합니다.
4. 라이프 사이클에 맞는 메소드 생성
def setupSpec() {} // 모든 테스트 케이스 실행 전 실행 (@BeforeClass)
def setup() {} // 각 테스트 케이스 실행 전 마다 실행 (@Before)
def cleanup() {} // 각 테스트 케이스 실행 후 마다 실행 (@After)
def cleanupSpec() {} // 모든 테스트 케이스 실행 후 실행 (@AfterClass)
1. openSession(): 마이바티스 설정 파일의 설정을 그대로 사용하는 바이바티스 객체 생성
2. openSession(boolean autoCommit): 마이바티스 설정을 그대로 사용하되 자동 커밋 여부를 변경함
3. openSession(Connection connection) : 마이바티스 연결 정보를 갖는 커넥션 타입 객체를 피라미터로 전달해서 마이바티스 객체 생성 : 만들어진 객체만큼 연결 객체가 갖는 여러 정보를 생성 시점에 설정 가능 : 연결 정보를 직접 사용하기 때문에 "마이바티스와 별도로 트랜잭션 제어 가능"
2번의 경우,association 태그 내에서 resultMap에 지정한 형태로 결과 값을 담게 된다.
도메인 관계
[User] 1:1 [Board] [Apply] N:1 [Board]
@Data public class User { private Long id; pirvate String name; }
@Data public class Board { private Long id; private String name; private User user; // has one relation ( association ) private List<Apply> apply; // has many relation ( collection ) }
public class Apply { private Long id; private Board board; // has one relation ( association ) private User user; // has one relation ( association ) }
mybatis:
config: mybatis-config.xml // config 위치 : static 바로 아래
type-aliases-package: kia.com.mybatistest.model // dao,dto가 위치한 곳
mapper-locations: mybatis/mapper/*.xml // mapper를 위한 xml 파일이 위치한 곳 ( static 아래가 아닌 resources 아래 )
### Mapper interface 작성
@Repository
@Mapper
public interface UserMapper {
List<UserDto> getAllUserDataList();
}
public interface UserServiceInterface {
public List<UserDto> getAllUserDataList();
}
### Service implement 작성
@Service
@RequiredArgsConstructor
public class UserService implements UserServiceInterface {
private final UserMapper userMapper;
@Override
public List<UserDto> getAllUserDataList() {
return userMapper.getAllUserDataList();
}
}
### Test Controller 구성
@RequiredArgsConstructor
@RestController
public class MemberTestController {
private final UserService userService;
@GetMapping("/user/test")
public List<UserDto> getAllDataList() {
return userService.getAllUserDataList();
}
}
위의 service 코드를 controller에 @RequestParam 을 통해 간단하게 나타낼 수 있습니다.
@PostMapping("/save")
public String process(
@RequestParam String username,
@RequestParam String password,
Model model
) {
Member member = new Member(username, password);
memberRepository.save(member);
model.addAttribute("member", member);
return "save-result";
}
1) 비연결성 : HTTP는 인터넷상에서 불특정 다수의 통신 환경을 기반으로 설계되었습니다. 만약, 서버에서 다수의 클라이언트와 계속 연결을 유지한다면 많은 리소스가 발생합니다. 그래서 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질을 가지게 되는데 이를 비연결성이라고 부릅니다. 하지만 이러한 비연결성은 모든 요청에 대해 매번 새로운 연결을 시도하므로 연결/해제에 대한 오버헤드를 가집니다.
2) 무상태 서버가 클라이언트의 상태를 보존하지 않음으로 클라이언트의 상태를 알 수 없는 상태입니다.
이러한 무상태는 로그인이 필요없는 단순한 서비스 소개 화면 정도의 구현에는 유용합니다.
하지만 사용자가 로그인한 상태를 서버에 유지 시켜 줘야 하는 경우 무상태로는 설계를 할 수 없게 됩니다.
이를 위해 세션과 쿠키를 조합하여 상태를 유지합니다.
Cookie
클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
사용자 인증이 유효한 시간을 명시할 수 있음
유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지됨
Response Header 에 Set-Cookie 속성을 사용해 클라이언트에 쿠키를 만들 수 있음
Cookie 구성요소
이름 : 쿠키를 구별하는데 사용되는 이름
값 : 쿠키의 이름과 관련된 값
유효시간 : 쿠키 유지시간
도메인 : 쿠키를 전송할 도메인
경로 : 쿠키를 전송할 요청 경로
Cookie 동작방식
클라이언트가 페이지를 요청
서버에서 쿠키 생성
HTTP 헤더에 쿠키를 포함시켜 응답
브라우저가 종료되어도 쿠키 만료 시간이 있다면 클라이언트에서 보관함
같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
서버에서 쿠키를 읽어 이전 상태 변경할 필요가 있을 때 쿠키를 업데이트
Cookie 사용 예시
방문 사이트에서 "아이디,비번 저장하시겠습니까?"
쇼핑몰 장바구니 기능
자동로그인, 팝업에서 "오늘 더 이상 이 창 보지 않음" 체크
Session
브라우저와 웹 서버가 연결되어 브라우저가 종료될때까지의 시점
세션은 쿠키를 기반으로 하지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 서버 측에서 관리
서버는 클라이언트 구분을 위해 세션 ID를 부여하며, 웹 브라우저가 서버에 접속해 브라우저를 종료할 때가지 인증상태 유지
접속 시간에 제한을 두어 일정 시간 응답 없을 경우 유지되지 않게 설정 가능
사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋음
하지만 사용자가 많아질수록 서버 메모리를 많이 차지함
즉, 동접자 수가 많은 경우 웹 서버에 과부하를 주게 됨
Session 동작 방식
1. 클라이언트가 브라우저를 통해 서버에 접속한다.
2. 서버는 세션id를 쿠키에 담아 되돌려준다.
3. 클라이언트는 세션id를 담은 쿠키인 세션 쿠키를 이후 요청부터 계속해서 전달한다.
이를 세션 기반 인증 방식이라고 하며, 간단하게 세션이라고 부른다.
Session 사용 예시
로그인 같이 보안상 중요한 작업 수행할 때 사용
JWT
JSON 객체를 사용해서 토큰 자체에 정보들을 저장하고 있는 Web Token
세션은 사용자 수 만큼 서버 메모리를 차지하기 때문에, 최근에는 이러한 토큰 기반 인증 방식을 사용한다.
JWT 구성
- Header
Signature 를 해싱하기 위한 알고리즘 정보들이 담겨져 있음
- Payload
서버와 클라이언트가 주고받는, 시스템에서 실제로 사용될 정보에 대한 내용을 담고 있습니다.
여기에 담는 정보의 "한 조각" 을 클레임이라고 부릅니다. 이 클레임은 토큰에 여러개가 들어갈 수 있습니다.
