/secu/all의 주소로 접속했을때 이제 로그인 안한 사용자에게는 로그인창 링크를, 그리고 로그인한 사용자에게는 로그아웃 링크를 보여주도록 코드를 위와 같이 고칩니다. 실행해보면 로그인 한후 /secu/all 들어가면 로그아웃을 볼수있고 로그아웃된 상태로 들어가게 되면 로그인을 볼수 있다. (sec:authorize 태그에 의해 조건식처럼 로그인한 사용자와 그렇지 않은 사용자가 보여지는 내용이 살짝 달라짐)

== 이제 자동로그인 기능을 구현해보겠습니다. 한 번 로그인하면 일정 시간동안 로그인로직 없이도 로그인유지가 되도록 만드는것으로 먼저 테이블을 추가합니다. (아래 테이블 양식으로 만드는게 스프링시큐리티의 공식 문저 권장사항) 테이블이 새로 생성되었다면 security-context.xml을 위와 같이 수정해줍니다. 604800초 만큼 자동로그인이 유지되도록 해 주는것으로 설정은 자유

로그인 화면에 checkbox를 구현합니다. name속성에는 remember-me를 주면 됩니다. customLogin.jsp 로그인시 f12 -> application->storage에서 세션발급여부를 검사하면 JSESSIONID에 이어서 remeber-me라는 쿠키가 추가로 발급되는것을 볼 수 있습니다. 그리고 DB쪽의 persistent_logins 테이블을 조회해보면 특정 유저의 마지막 접속 시점이 기록으로 자동기록 됩니다. 브라우저를 다 껏다 켜도 로그인이 유지되는지 /secu/admindm으로 브라우저를 완전히 껏다가 접속해도 유지되면 성공.

== 로그아웃시 remember-me 쿠키를 파기해야 합니다. security-context.xml에 위와 같이 추가합니다.

== 모든 주소를 하나하나 security-context.xml에 security-intercept-url태그를 추가해 시큐리티를 적용하는 것은 복잡하고 관리도 어려운 일입니다.

따라서 이제는 어노테이션으로 처리하는 방법에 대해 배워봅니다.

먼저 servlie-context.xml의Namespace탭에서 security를 체크해줍니다.

servlet-context.xml에도 역시 -5.0을 제거 제거가 완료 되었다면 security:global-method-security태그를 추가하고 아래 두속성을 모두 enabled로 고쳐줍니다.

이제 security-context.xml내부의 security:intercept-url을 주석처리하면 검증요건 없이 접속이 잘 되는걸 확인할 수 있습니다.

실행하면 멤버주소로 들어가지는걸 확인할 수 있습니다.

SecurityController로 와서, /member와 /admin 패턴에 위와 같이 @PreAuthorize 어노테이션과 표현식을 추가합니다. 실행해보면 /secu/member아까와 달리 로그인창이 뜨는걸 확인할수 있습니다. 로그인후 /secu/member 로 user0으로 들어가면 접근실패가 뜹니다. /secu/all로 들어가면 접근이 허용되는걸 확인할 수 있습니다.

-- member페이지에 관리자페이지로 가기버튼을 관리자 한정으로 볼 수 있게 처리

실행하면 /secu/member user0 pw0 로그인 /secu/member user15 pw15 로그인 /secu/member user22 pw22 로그인 관리자여서 멤버 주소로 접속했을시 관리자페이지로가기가 보인다.

== 회원가입 회원가입은 SecurityController에 /secu/join주소로 처리합니다. get방식으로 폼연결, post방식으로 가입처리를 합니다. 암호화를 위해 PasswordEncoder도 넣어준다. join jspfile를 만들어주고 아이디, 비밀번호, 이름은 MemberVO 변수이름과 member_tbl 컬럼명을 감안해 name속성을 주고 권한은 여러개를 동시에 주기 위해 role이라는 이름으로 체크박스 처리합니다. 스프링 시큐리티 적용 프로젝트에서는 폼에 csrf토큰을 포함해 보내야 합니다.

실행해보면 /secu/join 가입하기를 누르면

이제 받아온 MemberMapper의 데이터를 스프링 시큐리티에서 처리할 수 있도록 커스터마이징 해보겠습니다. com.ict.security에 CustomUserDetailService를 만들고 UserDetailService를 implements 해줍니다.

security-context.xml에는 CustomUserDetailService를 빈컨테이너에 넣어주고, 그걸 이용해 로그인하도록 바꿔줍니다. 실행했을때 콘솔창에 InternalAuthenticationServiceException이 나온다면 제대로 작동한 것입니다. 저렇게 나오는 이유는 UserDetails를 리턴하기로 해놓고 null을 리턴하고 있어서 입니다.

그럼 이제 로그인 로직에서 MemberVO를 UserDetails로 바꾸도록 처리하겠습니다. User를 상속한 CustomUser를 먼저 만들겠습니다.

이제 MemberVO가 입력되면 CustomUser의 생성자를 이용해 vo를 변환할수 있고, CustomUser클래스는 User를 상속받았는데, User는 다시 스프링 시큐리티에서 사용하는 UserDetail을 상속받은 상태입니다. 따라서 MemberVO를 스프링 시큐리티에서 쓸 수 있게 수정한 것입니다.

스프링 시큐리티 심화 기초적인 내용을 배웠다면 이제는 실질적으로 내가 만든 웹사이트에 스프링 시큐리티를 적용하는 방법을 배워보겠습니다. 먼저, jsp에서 스프링 시큐리티 옵션을 쓰는 법을 배워본 다음, 자동로그인 체크와 어노테이션을 이용한 적용까지 배우면 웹 사이트에 스프링 시큐리티를 좀 더 편하게 적용할 수 있습니다.

먼저 admin.jsp파일 내부에서 sec태그를 사용해보겠습니다. c태그 라이브러리 처리 taglib설정을 해주면 됩니다.

CommonController에는 이제 customLogout을 처리한느 폼으로 이동하는 메서드를 추가합니다. 추가로 customLogout.jsp도 생성해줍니다.

그리고 CommonController에 새롭게 /customLogin을 주소로 하는 메서드를 만들고 에러로 접근했는지 로그앙수 상태로 접근했는지 구분하도록 사전세팅 합니다.

views에는 customLogin.jsp를 준비합니다. 이 페이지는 어떻데 이 페이지오게 되었는지와, 로그인시 사용할 폼을 제공합니다.

실행보면 로그인을 하고 로그아웃후 (쿠키삭제후) 다시 로그인 페이지로 돌아가면 토큰 값이 계속 바뀌는걸 확인할 수 있다.

(csrf는 cross-site request forgery공격이라고 불리며, csrf검증로직이 없는 사이트는 form이나 img 태그 내부의 링크설정을 곧이곧대로 받아 처리하기 때문에 악의적으로 공격을 할 수 있게 됩니다. scrf 토큰은 매번 value값이 바뀌고, hidden으로 포함되어 들아가기 때문에 공격자 입장에서는 고정된 쿼리문만 전송해서는 더이상 명령이 작동하지 않고 매번바뀌는 csrf토큰값을 그때그때 찍어서 맞춰야 사실상 완전방어가 됩니다. )

콘솔창을 확인해 보면 admin 페이지로 접속시 admin으로 로그인

member 페이지로 접속시 member로 로그인

로그인을 해보면 제대로 로그인시 제대로된 페이지가 나오고 아이디 비밀번호를 잘못 입력하면 에러페이지가 나옵니다. 다만, 권한검증 등의 로직이 확실하게 처리되지는 않습니다.

이제 로그인 성공을 처리해보도록 해보겠습니다. AuthenticationSuccessHandler를 이용해서 처리합니다. com.ict.security에 먼저 CustomLoginSuccessHandler를 생성하고 AuthenticationSuccessHandler 인터페이스를 구현합니다.

오버라이딩 하는 onAuthenticationSuccess 메서드는 로그인 성공시 실행하는 로직들을 작성해줍니다. (return구문도 각 if마다 붙여주세요. 안붙여주면 리아디렉트가 중복 호출됨)

이제 기존 로그인 처리 로직을 커스텀 처리로직으로 바꿔 적용하기 위해 security-context.xml 내용을 바꿔줍니다.

(앞으로는 다른 로직을 커스텀 작성시

1. 커스텀 로직 작성
2. security-context.xml내부에 bean 생성
3. 태그 적용순으로 진행하면 됩니다. )

실행하면 접근 계정에 따라 로그인이 다르게 처리 잘되는것을 볼수 있습니다.

서버를 돌려 에러가 나는지 안나는지 확인을 해 보겠습니다.

서버 실행 후 에러가 나지 않는것을 확인했다면 SecurityController를 추가 해주고 url 세팅을 하겠습니다.

권한에 따라 접속할 수 있는 형태를 차등으로 두기 위해서 비회원, 회원, 운영자 3단계로 나눠서 접속 주소를 컨트롤러에 세팅합니다.

views 아래에 설정한 주소에 맞는 .jsp파일 3개를 만들어주신 다음 접속이 잘 되는지 확인 해보겠습니다. (all, member도 접속이 잘됨)

연결이 완료 되었다면 이제 필터와 스프링 시큐리티의 역할에 대해 보겠습니다. 기본적으로로는 접속요청을 스프링 시큐리티가 가로채서 확인을 한 다음 진행시킬지 말지를 결정시킨다는 것 입니다. (어떤한 요청이 와도 시큐리티를 거치고 지나감)

이를 위해 security-context 내부에 어떤 url 접속을 가로챌지, 그리고 접근에 따른 처리를 어떻게 할지 세팅해야 합니다. security:http 내부에 security:intercept-url을 먼저 지정할 수 있고 pattern에 접근 패턴을, access에는 권한이 부여된 사용자를 처리할 때는 위와 같이 hasRole('ROLE_직접부여권한명')을 적습니다. 실행해보면 all로 들어갔을때 http://localhost:8181/secu/member 로 들어가면 로그인 창으로 넘어가는것을 확인할 수 있습니다. (로그인이 안됐다면 폼로그인으로 )

/secu/member는 접속이 안 되는것을 볼 수 있습니다. MEMBER 권한을 부여받은 사용자가 로그인한 경우만 접근 가능하기 때문 입니다. (위의 로그인창은 우리가 만든것이 아닌 스프링 시큐리티가 임시로 생성하는 로그인 창 입니다. (나중에 커스터마이징하겠습니다 .))

이제 로그인이 가능한 아이디 하나를 security-context.xml에 부여해 보겠습니다. 이러면 동작 여부를 db를 거치지 않고도 임시로 확인 가능합니다. 아이디 비밀번호는 name,password에 각각 member로 권한은 authorities에 "ROLE_MEMBER"를 줍니다. 실행해보면 http://localhost:8181/secu/member member로 로그인 했을시 500에러가 납니다. 그러면 성공! (500이 뜨는 이유는 암호화를 안해났기 때문) 스프링 시큐리티에서는 스프링 5버전부턴느 반드시 비밀번호를 암호화해서 처리하도록 강제됩니다. 우리는 암호화 설정을 하지 않았기 때문에, 우선 암호화 이전에 로그인만 테스트하기 위해 비밀번호 앞에 "{noop}"을 추가해 암호화 기능을 꺼둡니다. 실행해보면 http://localhost:8181/secu/member member로 로그인 했을시

member페이지로 들어가지는걸 확인할 수 있습니다.

로그인을 풀고싶다면 f12->application->stroage->cookies 우클릭후 쿠키를 전부 삭제해주면 로그인이 풀립니다.

다음으로 admin 권한을 처리하겠습니다. admin은 member,admin에 모두 접속 가능하게 두 권한을 나열합니다. 실행해보면 http://localhost:8181/secu/admin admin으로 로그인 로그아웃 하고 http://localhost:8181/secu/member admin으로 로그인 admin계정으로 member주소에 접속이 가능한걸 확인 할 수 있다.

==커스텀 에러페이지 admin주소에 member계정으로 접속을하면 403에러가 뜹니다. 이제 톰캣 에러 페이지가 아닌 다른 화면을 처리해 보겠습니다.

접근 제한 페이지는 (에러페이지) security-context.xml 상단의 security:http 태그 내부를 위와 같이 고칩니다. 접근 주소는 /accessError이외에 다른 주소를 넣으면 작동하지 않습니다. CommomComtroller를 만들어서 접근주소 /accessError를 처리하도록 세팅합니다. views 폴더에 accessError.jsp를 생성해주고 에러 메세지를 출력하도록 코드를 작성해보겠습니다. 실행해보면 admin주소에 member 계정으로 접속을 하면 에러가 뜨는걸 확인할 수 있습니다.

== 스프링 시큐리티에서 제공하는 기본 에러 페이지 처리 방식이고 커스터마이징을 할 경우는 AccessDeniedHandler 인터페이스를 직접 오버라이딩해 구현해야 합니다. 대신 오버라이딩을 하는 만큼 세팅된 동작에 추가로직을 작성할 수 있습니다. 먼저 com.ict.security 패키지를 만들고 AccessDeniedHandler구현할 CustomAccessDeniedHandler를 만듭니다. 이제 디폴트 AccessDeniedHandler를 사용하는 대신 커스텀 핸들러를 쓰도록 security-context.xml을 위와 같이 수정합니다. security:http내부 속성도 모두 삭제해 디폴트 설정을 못쓰게 만들어주세요. beans graph에도 추가되어있는지 학인해주세요 (스프링 시큐리티는 계층 구조가 매우 복잡하니 주의) 실행하면 콘솔창에 이전과 달리 먼저 CustomAccessDEniedHandler를 처리는 내요의 로그가 뜬다면 제대로 연동된것

security_prj프로젝트를 생성하겠습니다.

https://velog.io/@one_2s/rest-%EC%83%88%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EC%84%B8%ED%8C%85%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95 (프로젝트 세팅 참고)

pom.xml에 spring-security-web 5.0.7 RELEASE 버전 spring-security-config 5.0.7 RELEASE 버전 spring-security-core 5.0.7 RELEASE 버전 spring-security-taglibs 5.0.7 RELEASE 버전
추가 해줍니다.

프로젝트 내부 WEB_INF폴더 내부의 spring폴더에 Stpring Bean Configuration File을 선택해 security-context.xml파일을 만듭니다. (이 파일의 용도는 스프링 시큐리티용 bean관리 컨테이너 입니다. ) 위에 상단을 http로 끊고 security-5.0.xsd 에서 -5.0을 지워주면 된다.

다음으로 web.xml설정을 해줍니다. 필터를 이용해 스프링 동작에 관여하도록 코드를 수정해줍니다. (오타가 나지 않게 주의 해야함 . 제대로 적어도 에러남) 에러를 없애려면 먼저 빈 컨테이너에 있는 시큐리티 관련 로직을 web.xml에서 인식하도록 설정해줘야 합니다. root-context인증 경로 아래에 security-context.xml을 푸가해 주세요.

board_tbl에 replycount컬럼을 추가하겠습니다. (commit;꼭 해줘야함)

com.ict.domain BoardVO에 방금 추가한 replyCount를 추가해줍니다.

boardMapper.xml에 select부분에 replyCount 추가 해줘야함 (별을 이용해서 다 불러오고 있기 때문에 따로 수정은 필요없음)

boardMapper 인터페이스에 bno는 해당 게시물의 번호, amount는 변동값을 나타내며, 마이바티스는 기존적으로 하나의 파라미터를 쓰는것을 전제로 하기 때문에 위와 같이 2개 이상을 정의 할때는 @Param 어노테이션을 붙여준다.

boardmapper.xml amount로 댓글의 증감을 나타내고, bno로 해당 글이 몇번이 었는지 카운팅해 댓글 숫자를 가늠합니다.

이제 댓글 추가와, replyCount 컬럼 업데이트라는 작업이 댓글 쓰기라는 하나의 서비스에 동반실행됩니다. 즉, 트랜잭션의 대상이 됩니다. replyServiceImpl내부에서 boardMapper를 사용할 수 있게 처리 합니다.

삭제시 댓글 갯수를 1줄이는 작업부터 하겠습니다. 먼저rno만을호 bno를 유추해야 하기 때문에 ReplyMapper쪽에 getBno메서드를 정의 및 구 구현합니다. ReplyMapper.xml

메서드는 리플 삭제라는 하나의 서비스 기능 구현에 실행시에는 정작 3개의 쿼리문을 돌려야 하기 때문에 반드시 트랜잭션이 적용해야 합니다.

boardList.jsp

실행해 보면

댓글이 삭제되는걸 확인 할 수 있습니다.

========= register

replyServiceImpl

실행해보면

댓글작성을 하고

글목록으로 나가면 댓글 갯수가 늘어난걸 확인할 수 있다.

== 글삭제시

1. 댓글 전체 삭제(replyMapper에 쿼리문 및 메서드 추가해야함)
2. 글 삭제 순 으로 삭제되어야 논리적 구조가 맞으므로 개선해 보겠습니다. 먼저 replyMapper.java replyMapper.xml

boardServiceImpl

실행해보면 196608번이 삭제된걸 확인할수 있습니다.

Sammple1Mapper 인터페이스와 Sample2Mapper 인터페이스는 mapper xml은 따로작성하지 않고, 어노테이션으로 구문을 작성합니다. Sammple1Mapper Sample2Mapper

방금 생성한 두 테이블에 같은 길이의 문자열을 집어넣는 서비스를 생성하기 위해 SampleTxService인터페이스, SampleTxServiceImpl 구현 클래스를 만들어 줍니다. SampleTxService SampleTxServiceImpl

src/test/java 내부의 com.ict.service 패키지 내부에다 SampleTxServiceTests 클래스를 만들어서 테스트를 해봅니다. 26글자를 테이블 두개에 넣어주는 로직 입니다. abcd ~를 addDate에 넣어주겠다 addDate를 집어 넣을때 mapper1 mapper2를 호출

실행하면 빨간불이 들어오고 둘다 안들어온걸 확인할 수있다. @@Transactional을 빼고 돌리면 col1에는 들어왔지만 col2에는 안들어온걸 확인할 수 있다.

@@Transactional이 있는 상태로 abcd 5글자 이내로 실행해보겠습니다. col1 col2 둘다 들어간걸 확인할 수 있다.

== 파라미터 넣는 방법== 이번에는 execute 구문에 args를 이용해 파라미터를 추적해 보겠습니다. 분명히 로깅자체는 마음에 들지만, 파라미터별로 무슨 값을 받았는지 알 수 있다면 더 좋기 때문에 LogAdvice에 추가호 위와같이 메서드를 추가합니다. (접근 제한자 모두 허용 com.ict.service.SampleService로 시작하는 모든 클래스 doAdd(String.string)인 메서드 타겟이며 파라미터는 각각 str1, str2로 명명) 메서드명이 doAdd여야 실행하겠고 파라미터 이름은 String1 String2이어야 한다. 옆에 저 화살표가 떠야 되고 갖다되면 어디에 적용되는지 알 수 있다. 실행 하면 BeFore === 이게 먼저 나오고 str1 에는 123 str2 에는 456이 들어오는걸 확인 할 수 있다.

Advice는 한 메서드에 2개 이상도 동시에 적용받을 수 있기 때문에 테스트 코드를 실행하면 이번에는 2개가 모두 실행됩니다. 둘다 @Before이기 때문에 원본 메서드 이전에 작성된 순서대로 실행 후 핵심로직이 실행 됩니다.

다음은 에외가 발생했을때만 작동하는 @AfterThrowing 을 추가해보겠습니다. LogAdvice 내부에 작성해줍니다. SampleServiceTests에서는 일부러 에러를 발생시켜보겠습니다. 실행했을때 빨간불이 나오면서 에러가 뭐였는지 로깅을 해줍니다. 제대로 맞게 넣으면 실행하면 예외가 안나오는걸 확인할 수 있습니다.

@Around는 메서드 실행 내내 실행되는 특이한 경우입니다. 특히, @Around와 함께 사용하는 ProceedingJoinPoint객체를 활용하면 파라미터와 예외 등등을 한 번에 처리할 수 있습니다. (메서드의 실행요소 시간을 구하는 Advice 입니다)

LogAdvice.java 실행 해보면

==============

스프링의 AOP와 트랜잭션

AOP를 응용해 트랜잭션을 이해하고 적용해 보겠습니다. 먼저 트랜잭션은 2개이상의 쿼리문이 실행된다면 전부 실행되고 실패한다면 전부 실패하게 만드는 것을 의미합니다. 4가지 원칙에 따라 기능을 묶어주는것을 트랜잭션이라고 합니다.

트랜잭션 실습을 위해 pox.xml에 라이브러리를 추가해줍니다. prj-aop프로젝트 spring-jdbc 5.0.7버전 spring-tx 5.0.7버전 HikariCP 4.0.3버전 log4jdbc-log4j2-jdbc4 1.16버전 mybatis 3.5.6 버전 Spring bridge f 2.0.6 버전 ojdbc8 추가

src/main/resources 내부에 log4jdbc.log4j2.properties파일 추가 root-context.xml을 열고 Namespace탭에 tx를 체크해줍니다.

com.ict.dao패키지 내부에 OracleConnectionPoolTest.java를 생성해 테스트를 코드를 실행해줍니다 . 연결 성공!

root-context.xml 내부에 트랜잭션 실행을 위한 transactionManager객체 생성과 annotation-driven 태그 작성 쿼리문을 입력한 마이바티스 매퍼를 스캔합니다.

실행하면 수정 버튼을 눌렀을때 내용만 뜨는 걸 확인 할 수 있다.

다음은 댓글 등록창을 만들어 보겠습니다. 위치는 댓글 목록 아래에 두겠습니다. 역시 간단하게 input태그와 버튼으로 이벤트를 처리합니다.

실행하면 댓글 쓰는 폼이 만들어 진걸 확인할 수 있다.

===============================

스프링의 AOP와 트랜잭션

AOP는 핵심 로직과 보조 로직을 분리하자는 개념에서 출발합니다. 예) 핵심 로직 - 소개팅가기(), 출근하기(), 놀러가기(), 해외여행() (목표가 되는 로직) 보조 로직 - 씻기(), 그루밍(), 대중교통타기() (핵심로직 실행을 위해 실행하는 보조적 기능들)

여태까지는 모든 메서드의 실행요소시간이 몇 초인지 구하고 싶으면 메서드마다 기능을 추가해야 했지만, 이제는 실행요소시간 구하는 기능을 하나만 만들어 두면, 모든 메서드에 기능을 전역적으로 추가하거나 혹은 기능을 추가할 메서드 범위를 지정할 수 도 있습니다. 이런 개념을 AOP라고 부르며, 주로 로그, 보안등 주요 기능은 아니지만 주요 기능을 보조하는 기능을 구현 할때 많이 사용합니다.

AOP용어정리

==== 프로젝트를 생성하겠습니다. prj_aop 프로젝트를 생성하고 pom.xml에가서 값을 수정 해줍니다.

spring-test 5.07버전 lombok 1.18.18버전 aspectjweaver 1.9.0버전 aspectjrt 1.9.0버전 추가

com.ict.service 패키지를 만들어 SampleService 인터페이스 SapmleServiceImpl 구현 클래스를 만들어 줍니다. SampleService.java SapmleServiceImpl.java

(service의 코드는 현재 로그를 기록하는 기능이 없습니다. 보조 기능과 핵심 기능을 따로 개발하는 AOP 개념을 적용해 로깅기능을 추가할 것이기 때문입니다. 로그를 자동기록해주는 Advice를 지금부터 작성해보겠습니다.) com.ict.aop 패키지에 LogAdvice클래스를 생성 LogAdvice.java (pom.xml에서 aspectjrt의 scope 태그를 주석처리 해야 LogAdvice.java내부에서 @Aspect어노테이션이 인식되니 주의)

(@Log4j가 에러나는 경우는 pom.xml의 log4j버전이 1.2.15일경우 exclusions를 남기고 1.2.17인 경우는 삭제하신 다음 두 버전 모두 공통적으로 내부 scope를 주석처리하면 풀림)

LogAdvice.java @Before는 핵심로직 실행 전에 logBefore메서드가 실행됨을 나타내며, 내부 문자열은 규칙에 맞는 메서드 전부를 실행하기 전에 실행됨을 나타냅니다. 위의 경우 맨 앞의 *은 접근제한자 상관 없음, 가운덴는 어느 패키지 어느 클래스까지, 뒤의 *은 클래스명, 메서드명, 파라미터 종류이다. (@Aspect를 받은 클래스는 AOP의 타겟임을 알리는것)

root-content.xml aop, context설정 내부에 작성

이제 컴포넌트 스캔이 되면서 위와 같이 메서드 왼쪽에 화살표 마크가 추가됩니다.

com.ict.service 패키지 내부에 SampleServiceTest클래스를 생성해 작성하고

실행했을때 Proxy객체가 확인되어야 AOP 적용이 완벽하게 된 것입니다.

(insertTest.jsp에서 썻던걸 복사!! 테스트를 해서 성공이 되는걸 확인했기 때문에 알맞게 복사하면 됨)

잘 복사했으면 수정,삭제,닫기 버튼기능들이 잘 작동됨.

==

댓글 디자인을 해보겠습니다.

getJSON부분을 수정해 줍니다. 구문 내에 먼저updeteDate를 받아온 다음. Date 타입으로 변경을 해 줍니다. 그 뒤 getFullYear()로 연도를, getMonth로 월을(0부터 시작) getDate로 일자를 받아와 출력위치에 둡니다. 실행하면 댓글 작성한 시간, 디자인 변경된걸 확인 가능!

모달 닫기 .hide()로 닫고, show()로 연다 closeBtn을 클릭했을때 모달이 닫히도록 처리해보겠습니다. 실행했을때 닫기 버튼이 눌려지면 성공입니다!

=== 삭제버튼 로직 modal-title의 글 번호를 얻어오고, reply의 수정할 글 내용을 가져온 다음 ajax통신을 이용해 delete로직을 실행한 다음 모달을 닫고 댓글목록을 갱신합니다.
실행하면 삭제 버튼을 눌렀을시 삭제가 되는걸 확인 가능

== 수정버튼 로직 전박전으로 delete와 같고, type만 put(patch)로 바꿉니다. 단, 수정은 삭제와 달리 수정할 내용이 동반되므로 data속성도 추가합니다. contentType은 만약 415에러가 뜬다면 추가하면 되는 부분입니다. 실행을 하면

실행하면

댓글 추가 후 폼 태그 안이 비워지게 되도록 하겠습니다.

댓글이 비어지는걸 확인할 수 있다.

이제 모든 댓글은 표출시 버튼을 가질 수 있도록 수정하겠습니다. 결과가 수정 버튼이 생기면 성공!

각 이벤트 버튼 모두가 독립적으로 클릭시 반응하도록 "위임"처리를 했습니다. onclick 이벤트를 처리 할때 두 번째 파라미터로 함수 대신 "부모요소 자식요소"와 같이 적으면, 실제로는 replyLi하위의 button모두가 따로따로 기능합니다.

온클릭 하는법 HomeController.java에 onClockTest메서드를 만들어 줍니다.

viesw - 우클릭 new - jspFile - onClickTest 생성 onClickTest body 태그 안에 작성해주고 ul,button, jquery cdn

script태그에 @requestBtn에 대한 onclick이벤트를 걸어줍니다.

실행했을때 http://localhost:8181/onClickTest 댓글 로딩해오기 버튼을 클릭하면 댓글 내용이 나온느것을 확인할 수 있다.

=== ajax 테스트하기 전체 댓글 불러온느 기능은 많이 사용하므로 함수화 해서 저장해둡니다. 마지막에 한번 호출해서 제대로 작동하는지만 체크하고 넘어갑ㄴ다. 실행하면 http://localhost:8181/test 댓글 목록이 다 나오는걸 확인할 수 있습니다.

=== 댓글 등록화면 테스트 HomeController.java에 insertTest메서드를 만들어 줍니다. viesw - 우클릭 new - jspFile - insertTest 생성

insertTest.jsp body 태그 안에 먼저 작성해줍니다. (AJAX는 form 태그가 필요없음) 실행했을때 (폼은 아니지만 폼형식의 형태가 만들어 지는걸 확인할수 있음) 실행하면 즉, $.getJSON()은 이 페이지에서 데이터를 서버에 요쳥해 가지고 올때, $.ajax()는 이 페이지에 입력된 어떤 자료를 서버에 보낼때 사용하는 기능들 입니다. 이상의 로직들은 페이지 이동 없이 이루어졌습니다. 이런 식으로 rest서버에 ajax요청을 해서 비동기 작업을 하는것이 바로 rest개발 방식이며, 어플리케이션 등에서도 비슷하 수순으로 개발이 이루어집니다.

등록하기 버튼을 누르면 등록 되었습니다 라고 나오고 댓글이 추가되는걸 확인할 수 있다.

먼저 개발시간의 단축을 위해 HomeController 하단에 ajaxText 메서드를 작성합니다.

테스트를 할 test.jsp를 생성합니다 view바로 아래에 생성하면 되고, body태그는 다음과 같이 구성합니다. jquery는 구글 jquery 검색 Download 클릭 Google CDN 클릭 3.x snippet 복사 하면 된다.

DB를 조회해 댓글이 2개이상인 글번호(bno)를 미리 기억해주세요. 없다면 insert구문을 실행해 댓글을 2개 이상 보유한 글을 만들어 줍니다. (글번호 1번으로 진행 하겠습니다) (댓글 추가 전 장에 있음)

(body태그 하단) 첫 번째로는 페이지를 열자마자 해당 글(1번bno)의 글 개수를 콘솔창에 찍어주는 자바스크립트 코드를 작성해보겠습니다. $.getJSON("주소",function(data){ console.log(data.length); }); 는 rest주소에 데이터를 요청하고 받아온 데이터를 data변수에 담아줍니다. (var 대신 let 사용해도됨) 실행하면 1번글에 댓글이 몇개있는지 알수 있다. (댓글 갯수22개)

length를 빼고 데이터로만 조회하면 데이터가 나오는것을 확인할 수있다.

== str내부에 li태그로 구성된 태그를 전체 댓글 개수만큼 반복해서 작성해두록.each구문을 사용하고, 그에 다른 결과는 아까 생성해놨던 ul태그 내부에 삽입하도록 처리 했습니다.

====

삭제로직

삭제로직은 delete요청을 처리하기 위해 @DeleteMapping을 걸어서 로직을 정의합니다.

ReplyCnotroller.java 댓글을 쓴 게시물 번호를 조회를 한 다음 그안에 댓글 번호를 가져옵니다. 저는 (14번을 가져오겠습니다) YARC에 가서 작성을 해주고 돌려보면 14번 댓글이 삭제되는걸 확인할 수 있습니다.

====== 수정로직 PUT, PATCH 방식은 구분이 엄격하지 않기에 위와 같이 두 가지를 모두 포함시켜줍니다. consumes에는 json을 입력받음을 명시하고, produces에는 문자열을 리턴한다고 명시합니다.

ReplyCnotroller.java 댓글을 쓴 게시물 번호를 조회를 한 다음 그안에 댓글 번호를 가져옵니다. 저는 (13번을 가져오겠습니다) YARC에 가서 작성을 해주고 돌려보면 (PUT, PATCH 둘중의 하나로 돌려주면 됨) 13번의 댓글이 수정된걸 확인할 수 있습니다.

src/main/resource 우클릭 new - file - db.properties 생성 (파일명은 아무렇게 적어도 상관없음) 여기 안에 4개를 적어야 합니다.

다음은 전체 글 목록을 요청하는 list메서드를 생성합니다. 이 메서드의 파라미터에는 @PathVariable이라는 어노테이션이 있는데 이는 상단의 {bno}자리에 들어온 요소는 ?bno=과 같이 간주한다는 의미입니다. 이번에는 produces를 확장해 xml,json을 모두 다루게 해보겠습니다.

실행을 해보겠습니다(get방식이라 trac를 안써도됨) 주소 = http://localhost:8181/replies/all/500 xml버전 json버전

============== rest 방식의 가장 큰 차별점:

비동기 예)업비트

mvc는 동기식 데이터가 수시로 넘어가지 않음. 한 번에 화면단에서 쓸 데이터를 다 넘겨주고 일단 화면으로 넘어가면 추가 데이터를 받아올 수 없음 (받기 위해서는 전환이 필요함) 21156

com.ict.controller - 우클릭 new - class - TestController 생성 @RestController 는 일반 컨트롤러와는 달리 이 컨트롤러가 rest방식으로 작동할것이라는 선언을 하는 어노테션입니다. 이제, 이 서버는 .jsp파일을 필요로 하지 않으며, 단순히 결과는 문자열, xml문서,json문서만을 화면에 표시합니다. (클래스 위에 붙인 RequestMapping은 해당 컨트롤러의 공통된 진입주소를 설정해줍니다. )

단순 문자열을 다뤄보겠습니다. 메서드가 리턴은 String으로 하면 그 문자를 화면에 표룽할 뿐입니다. 거기에 더해 F12를 눌러 개발자 도구를 열어 Network탭으로 이동한 다음 다시 새로고침을 하면 위와 같은 서버가 전송한 데이터에 대한 정보가 나와있습니다.

com.ict.controller / 우클릭 package / com.ict.domain 생성 com.ict.domain / 우클릭 new / class / TestVO 생성 RestController에서 객체 (vo등)은 전부 json으로 변환됩니다. 먼저 테스트용 vo를 생성해보겠습니다.

TestController에서 방금 생성한 TestVO를 리턴하는 메서드를 생성하겠습니다. TestController 실행하면 500에러가 뜹니다. 이유는 json타입을 반환하기 하지만 변환하는 기능이 바로 작동하지 않기 때문입니다. 따라서, mvnrepository에서 jackson-databind 라이브러리를 새로 pom.xml에 추가 해줍니다. jackjon-dataformat-xml 도 검색해서 추가해주면 xml형식으로도 같이 처리 할 수 있습니다. pom.xml 그리고 다시 실행 해보면 http://localhost:8181/test/sendVO (xml 형식) http://localhost:8181/test/sendVO.json (.json형식) 나오는 것을 확인할 수 있습니다. json타입을 리턴했음을 명시해주고 있다.

listVO로 처리하는 법 TestController

실행하면 +f12 json으로 나오는거 확인할수 있음 (대괄호 안에 하나하나의 중괄호 데이터로 묶어서 주고 있음) 이렇게 전달받은 객체 리스트 위와 같이 대괄호로 감싸진 json객체의 집합으로 표시됩니다.

json처럼 표현되는 Map자료형 역시 그대로 표현할 수 있습니다. 실행하면 (맵 같은 경우는 중괄호가 아니라 대괄호를 쓴다. ) 객체 내부의 객체로 표현됩니다. 대괄호로 동등하게 나열하는 형태가 아님에 유의

==== 서버는 요청을 처리하며, 결과로 코드를 함께 전송합니다. 그리고 ResponseEntity를 사용하면 개발자가 의도한 타이밍에 의도한 응답을 사요자에게 전달할 수 있습니다.

이제 접속하는 족족 400에러를 발생시키는 ResponseEntity<>를전송해보겠습니다.

HttpStatus.BAD_REQUEST와 같이 HttpStatus 객체를 ResponseEntity객체의 생성자로 넣어 return구문에 제공하면 됩니다. 실행하면 정확한 주소로 접속했음에도 불구하고 400에러가 나는걸 확인 할 수 있습니다. (마치 에러처리를 하듯 상황에 맞는 에러를 전달하면 됩니다. ) new ResponseEntity<>(HttpStatus.BAD_REQUEST); ㄴ> 익명클래스

메세지만 전달할 수 있는것은 아닙니다. 에러가 발생했음에도 불구하고, 데이터를 동시에 전달해야 하는 경우도 있는데 ResponseEntity 객체를 생성할때 파라미터를 2개 넣어주면 됩니다. 실행하면 데이터는 보여주며 404에러를 발생시킬수도 있습니다. 보통 호출한쪽에 에러의 원인과 함께 원인데이터를 제공할때 사용합니다.

=== rest 방식 개발 get - 데이터 조회 post - 데이터 삽입 put - 데이터 수정 delete - 데이터의 삭제 URL부터 시작해 모든 부분을 REST방식으로 구성해 댓글비스를 개발하겠습니다.

== oraclel를 켜 댓글을 위한 테이블을 작성해줍니다. 댓글은 글과 무조건 연동되기 때문에 이를 감안해, 외래 키까지 걸어주도록 하겠습니다. 쿼리문을 실행해 테이블을 생성후, SpringBoardPrj로 옮겨 작성합니다.

다시 SpringBoardPrj 게시판 프로젝트로 돌아와주시고 domain에 이제 리플 관련 정보를 처리할 수 있는 VO를 생성합니다. SpringBoardPrj - com.ict.domain / 우클릭 new / class / ReplyVO 생성 ReplyVO

com.ict.mapper / 우클릭 new / interface / ReplyMapper.java 생성 com.ict.mapper / 우클릭 new / interface / ReplyMapper.xml 생성 ReplyMapper.java ReplyMapper.xml 위에 작성하고 쿼리문 작성해주면 됩니다.

com.ict.service / 우클릭 new / interface / ReplyService.java 생성

com.ict.service / 우클릭 new / class / ReplyService.Impl.java생성 ReplyService.java (ReplyService.java는 com.ict.mapper를 복사하면됨.) ReplyService.Impl.java

com.ict.controller / 우클릭 / new / class / ReplyController.java 생성 컨트롤러가 기능을 사용할 수 있도록 서비스 객체도 내부에 생성합니다. 상단의 작성해주고 @RequestController(화면단이 없음)

컨트롤러에 대한 rest 방식 요청을 하기위해 크롬창의 메뉴 -> 도구 -> 더보기 -> 확장프로그램에 들어가서 메뉴바를 열어 좌측하단에 Chrome웹 스토어를 열고 rest client를 검색후 Y.A.R.C를 클릭해 다운받아 줍니다. (고정도 해줌) 어떤 메서드로 요청할지를 정할수 있어서 기존의 get, post외에도 put/patch,delete요청이 가능합니다.

다시 컨트롤러로 와서 registger를 추가해줍니다. post방식의 글 추가 패턴은 consumes는 전달할 데이터의 형태를 저장하는것으로 json인 경우 위와 같이 적습니다. priduce 역시 json 데이터 처리시 위와 같이 작성합니다.

연습용 프로젝트를 만들어 보겠습니다. file - new - Spring Legacy Project 클릭 Project name = prj_rest_2 Spring MVC Project 클릭 com.ict.controller 작성하고 finish pom.xml 내부 수치변경을 진행합니다. 11번 라인 94번 라인 116번 라인 139번 라인 수정 해준다. 그리고 Mvnrepository에서 spring-test 5.0.7.Release 버전 spring JDBC 5.0.7 Release 버전 spring-tx 5.0.7.Release 버전 hikariCP 4.0.3 버전 mybatis 3.5.6 버전 mybatis-spring 2.0.6 버전 log4jdbc-log4j2-jdbc 1.16 버전 (한 칸 아래 JDBC 4.1과 혼동X) lombok 1.18.18 버전 ojdbc8 18.15.0.0 버전 검색해서 복사하고 붙여넣기 해준다.

프로젝트 파일 우클릭 -> Maver -> Update Project를 클릭해 자바버전을 1.8버전으로 업데이트 합니다.

프로젝트의 src/main/resources 폴더에 log4jdbc.log4j2.properties 라는 이름으로 file를 생성하고 내용을 위와 같이 적습니다. log4jdbc.spylogdelegator.name=net.sf.log4jdbc.log.slf4j.Slf4jSpyLogDelegator

Root-context.xml로 이동해 hikariCP 관련 설정과 마이바티스 관련 설정을 진행합니다. 먼저 hikairCP의 HikariConfig와 HikariDataSource 객체를 bean-container에 넣어줍니다.

root-context.xml파일 하단의 Namespaces 탭을 클릭하고 mybatis-spring, context을 체크합니다.

이후 sqlSessionFactory 객체를 생성한 다음 밑에 마이바티스 스캔을 하고, root-context.xml 하단의 Beans Graph 탭을 클릭해서 제대로 객체들이 들어왔나 체크 합니다. (또는 S가 붙었는지)

한글 인코딩을 처리하기 위해 web.xml 파일의 web-app 태그 사이에 위와 같이 적어넣습니다. 일부 화면에 표시되는 한글, 그리고 폼에서 POST로 전송되는 한글 처리를 위해 이렇게 세팅해주면 됩니다.

src/test/java com.ict.controller 우클릭 / 패키지 com.ict.persistence 생성

com.ict.persistence 우클릭 / new class / OracleConnectionPoolTest 생성

OracleConnectionPoolTest 커넥션풀을 하기위해 테스트 하기 위해 작성

실행하면

초록불, 마이바티스 연결시작! 나오면 성공!