개발이랑 일상이랑

JWT토큰을 파싱하는동안 토큰의 유효시간을 확인하는데 만약 유효시간이 지나있으면 expired... 에러가 난다 토큰이 유효하지 않으면 다시 토큰을 요구하는 방식이 refresh 토큰이다 검증후에 사용자가 가진 정보를 가져야할 필요가 있을떄? ->security context

토큰을 이어서 보내는것 -> bearer 방식 (인증할때 많이 이용한다) HTTPONLY -> js로 cookie에 접근할 수 없다. 오직 http에서만 쿠키를 핸들링 할 수 있도록 함.. 토큰의 용도는 무엇일까..? JWT는 HEADER와 PAYLOAD, SIGNATURE로 나뉘고 PAYLOAD에는 유효기간이 있다. JWT는 만료시간만으로는 다른곳에서 탈취해서 사용할 수 있기때문에 토큰이 노출되면 위험하다.. 어떻게 안전하게 사용할수 있을까? ->secret token을 같이 발행하는 방법도 있지만 완벽한 보안방법은 아니다... 제3자를 껴서 하는 인증을 OAuth라고 한다... MAC ADDRESS - 네트워크에 할당된 고유식별자이다 (전세계에 하나밖에없음) (/login , email,pw) -> ..

jwt는 그냥 문자열이다. dest (destination : 목적지) 시큐리티에서 5번째필터가 중요하다... (우리가 이 필터앞에 새로운 필터를 끼워넣을거라서..) 시큐리티필터중에 한 필터에서 인증을 시도하거나 성공시 조건을 반환할 수 있는 필터가 있다.(여기서 성공시 문자열을 반환할 예정인데 이 문자열은 JWT토큰이다) 로그인을 처리하는 필터와 api를 체크하는 필터 두개를 만들것 OncePerRequestFilter : 매번 동작하는 필터이다

403에러를 시큐리티에서 처리하고싶으면? 403에러를 커스터마이징한다. 쿠키에는 String 밖에 들어갈 수 없는데 한글은 utf로 인코딩해서 넣어주어야 한글이 깨지지 않는다. csrf().disabled()를 쓰는이유는? 세션당 번호를 하나씩 주고 번호를 요구한다(GET방식이 아닌 모든방식을 할때는 요구한다) 근데 토큰값이 매번 바뀐다. api서버를 만들때는 csrf토큰을 보통은 이용하지 않는다(매번 요청마다 토큰을 보내주면 복잡해지니..) 인가provider가 있으면 db에 있는 정보로 authentication을 걸어줄 수 있따. 이때 userDetailsService라는 아이를 바꿔준다 /// EntityGraph의 type Load(명시한 아이는 EAGER 나머지는 entity에 명시된 대로) ..

부트의 autoconfiguration때문에 security의존성을 추가하는순간 동작이 바뀐다 시큐리티는 커스텀설정을 따로 잡는다(configuration) 1. 어노테이션베이스 설정 2. 직접 configuration을 잡아주는 설정 스프링 시큐리티는 암호화된 패스워드를 입력해야지만 사용이 가능하다(password encoder) 이런 암호화한 로직을 구글이만든 bcrypt를 이용한다 브루트포스공격 ->아무거나 값을넣어보는것 솔트 -> 섞는것 암호화는 되는데 복호화가 안되는것을 뭐라고하나-> ? 암호는 항상 메세지와 키로 구분된다 bcrypt암호화는 복호화를 할수 없다 . 단지 암호화한 값이 만들어진것이 유효한것인지만 체크해준다.

패르소나를 디테일하게 선정하자 페르소나는 주제가 정해진 이후 바로 만들게 된다. 마인드맵을 이미지화 하자 이해관계자의 요구사항을 정리하자 - 액셀로정리(구글드라이브) security는 filter와 interceptor를 알아야 한다. jwt를 이용하는 방식으로 한다. 1.JWT 2.인증/인가 3.커스텀처리 security주의사항 *username => id라고 생각해야한다. *Role_ => 권한을 의미한다. application의 보안과 web의 보안은 다르다. application을 만드는 시대에서는 ACL(Access Controll List)이라는것을 만들었다. 상속보다는 조합을 써라 라는 말이 있다 security는 조합하는 방식을 쓴다. 추상화를 하는 진짜목적은 if else를 없애는것 시큐..

*중요 목록데이터를 뽑을때는 반드시 limit가 걸리는지 확인해야한다.

manytoone은 코드는 좀 더 쓰지만 복잡하지는 않은데 onetomany는 복잡성이 조금 증가한다. 수정할때 조심해야할 점이 있다 oneToMany는 parent Entity와 child Entity의 관계라고 말한다. @OneToMany(orphanRemoval = true) (고아는 삭제해줘,, 이 아이를 참조하고있는 부모객체가 없으면 같이 삭제하도록하는 기능) 첨부파일을 올릴때 방법 1. form태그 2.Ajax -반드시 알아야하는 JS객체 ->FormData 파일업로드를 할때 1. 파일체킹을 해야한다(일반파일, 그림파일에 따라 썸네일처리도 다르게 해야한다..) 2. 다운로드처리... 썸네일을 thumnailator.. file copy는 .... jdk에서 files.copy 실제로 프로젝트할..

pk로 해석하면 pk로 관리해야한다. 영속성 전이 (cascade) 객체의 영속상태가 바뀌면 같이 영향을 받도록 하는것 @Transactional어노테이션은 추가적으로 해야할 일이 있을떄 하나의 업무단위로 묶어서 일들을 전부 해결하도록 하는 어노테이션이다.

파일 업로드 하는방식 1.테이블에 종속적으로 파일업로드를 할 수 있다. 댓글은 일반적으로는 하나의 댓글에 첨부파일 하나만 넣게되는 경우가 많다. 파일업로드할때 신경쓰일것들이 몇가지 있따 1. 동일파일이름처리 2. 파일경로 manyToOne과 OneToMany는 관계를 잡는 기준을 어떻게 두어야하나... ->UI / UX의 관계의 관점에서 생각하자 (게시글을 수정할때 첨부파일이 변경되고, 댓글을수정할때 첨부파일이 수정된다.. 이렇게 종속적일땐 OneToMany가 괜찮다...) OneTOMany를 걸면 무조건 테이블이 하나생긴다 (2개의 테이블을 연결시켜주는 테이블이 복합pk로 생긴다) 테이블을 만들지 않고 바로 연결하려면 MapedBy라는 어노테이션을 사용한다.. oneToMany를 쓰는 가장 큰 이유가 ..