피들러 피들러(Fiddler)는 무료로 사용할 수 있는 웹 디버깅 툴입니다. 컴퓨터 간 주고받는 네트워크 트래픽을 포착해서 어떤 요청이나 응답에 문제가 발생하는지 확인할 수 있습니다. 애플리케이션의 통신에 문제가 있을 때 자주 사용됩니다. 예를 들어, 로그인 실패, 특정 기능 동작 실패 등처럼 문제가 있으면 피들러로 1차적인 확인이 가능합니다. 피들러 세션 수집, 저장 방법 1. 문제가 되는 동작을 수행합니다. 또는 세션 저장을 원하는 동작을 수행합니다. 그러는 동안 피들러는 생성된 트래픽을 포착해서 결과로 출력합니다. 아무 동작도 하지 않아도 자동으로 트래픽이 생성되기도 합니다. 2. 피들러에 세션이 쌓였으면 세션을 저장합니다. 메뉴에서 File > Save > All sessions 순으로 클릭하세요..
리디렉션? 리다이렉션? redirection의 정확한 발음은 무엇인지 모르겠습니다. 둘 모두 사용되고 있습니다. 구글 번역은 리디렉션으로 발음하기 때문에 저도 리디렉션으로 부르겠습니다. 리디렉션 URL 리디렉션은 한 URL에서 다른 URL로 사용자를 보내는 웹 서버의 기능입니다. 예를 들어, www.example_A.com으로 접속하면 www.example_B.com URL로 넘어가는 식입니다. 1. 리디렉션 사용 이유 기업 입장에서 여러 상황에 대응하기 위해 리디렉션을 사용합니다. 사이트의 상호명을 변경한 경우, 웹 사이트 두 개가 하나로 합쳐진 경우, 업데이트된 콘텐츠로 트래픽을 유도하는 경우 등이 예시입니다. 요즘 자주 보이는 단축된 URL 역시 리디렉션 기술이 활용된 것입니다. 물건 구매 링크나 ..
사이트 URL을 요청하면 로그에 HTTP 상태코드가 표시됩니다. 상태코드 200은 문제없이 정상적으로 응답함을 의미합니다. 간혹 상태코드 304도 발견된다. 문제가 있는 건가 싶은 생각이 들 수도 있지만, 304는 에러가 발생한 게 아니라 요청을 했으나 페이지의 상태가 변경된 게 없다(not modified)는 뜻입니다. 예를 들어, 페이지를 새로고침(F5)하면 발생할 수 있는 상태코드입니다. 분명 상태코드가 200인데 사이트에 코딩된 UI가 안 보이는 경우가 간혹 있습니다. IE 같은 브라우저에서 지원하지 않는 기능이 담겨 있으면 그런 상황이 발생할 수 있습니다. 그럴 때 화면을 새로고침 시도하면 304 상태코드가 로그에 남는습니다. 그 로그를 보고 에러가 발생했다고 생각하면 잘못된 판단이 됩니다.
https는 웹에서 데이터를 전송할 때 사용되는 통신 프로토콜입니다. SSL은 데이터가 전송될 때 통신 채널을 보호하는 수단입니다. 사이트의 URL이 http가 아닌 https로 되어 있다는 것은 http 통신을 SSL로 암호화하고 있다는 의미입니다. 때문에 SSL과 https는 같은 뜻은 아니지만 항상 함께 사용됩니다. SSL이란? SSL은 Secure Socket Layer의 약자입니다. 온라인 상에서 통신을 암호화하는 기술입니다. 이 기술로 사용자의 소중한 데이터를 보호합니다. 사이트 구축 시 SSL을 사용하기 위해서는 별도의 인증서가 필요합니다. 개인정보가 요구되는 사이트는 대부분 이 기술을 활용합니다. 예를 들어 법률, 의료, 결제, 금융, 개인 정보 수집, 사용자 아이디, 비밀번호 등을 활용하..
모든 웹 사이트는 웹 서버가 있습니다. 웹 서버가 없다면 우리가 알고 있는 인터넷은 존재할 수 없는 것입니다. 웹 서버(Web Server)란 웹 사이트를 실행하는 컴퓨터입니다. 사용자의 요청에 따라 웹 페이지를 전달하는 게 웹 서버의 주목적입니다. 웹 서버 작동방식 웹 서버는 클라이언트-서버 모델을 따릅니다. 클라이언트-서버 모델이란 클라이언트가 요청을 하면 서버가 응답하는 방식의 통신을 수행하는 구조를 말합니다. 웹에서 클라이언트는 크롬, 사파리, 엣지 같은 브라우저입니다. 즉 사용자 → 브라우저(요청) → 웹 서버(응답) → 브라우저 → 사용자처럼 상호작용합니다. 웹 브라우저와 웹 서버는 HTTP(Hypertext Transfer Protocol)라는 통신 규약을 사용해 통신합니다. 때문에 웹 서버..
-로컬저장소 생성 -$ git init [저장소 폴더명] -로컬저장소에 커밋 -$ git add [파일명] -$ git commit -m "메시지" -원격저장소에 커밋 -$ git remote add origin [깃허브 레포지토리 주소] -원격 저장소에 연결됐는지 확인 -$ git remote -v -master 브랜치에 push -$ git push –u origin master -이제부터 $ git push | $ git pull로 사용
#깃 클론 하는 법 -자기 컴퓨터에 폴더 만들고 깃연동 -Ex) 폴더명 test이면 -$ git init test -폴더 진입 -$ cd test -이름, 이메일 설정 -$ git config user.name "이름" -$ git config user.email "깃허브 이메일" -깃 클론 -$ git clone [깃허브 레포지토리 주소] -깃허브 레포지토리 폴더 진입 -$ cd [폴더명] -깃허브 레포지토리에 커밋된 파일 내 컴퓨터로 받아오기 -$ git pull -내 컴퓨터로 작업한 파일 깃허브에 올리기 -$ git add [파일명] -$ git commit -m "메시지" -$ git push #깃 브랜치 만드는 법 -브랜치 만들고 스위칭 -$ git checkout -b [브랜치명] -해당 브랜..
pwd : 현재 위치 경로 표시 ls : 현재 디렉터리의 디렉터리와 파일 이름 표시 git init : 초기화. 해당 폴더를 git 저장소로 씀 git add 파일명 : 수정 파일 스테이지로 저장 git status : 현재 상태 확인(스테이징 상태인지 커밋상태인지) git commit -m "메시지" : 커밋(버전을 만듬) git log : 커밋한 버전을 나열해서 보여줌 git log --stat : 어떤 커밋인지까지 상세히 나옴 git commit -am "메시지" : add와 commit 동시에 진행 git add . : 수정한 파일 한번에 스테이지로 추가(add) git diff : 수정 내용 한 줄씩 확인 git restore --staged 파일명 : 스테이지에 올린(add) 걸 다시 내림 g..
@RequestMapping 대신 @PostMapping @GetMapping 쓰는 이유가 궁금했다. 구글링으로 여러 블로그를 찾아봤지만 "코드가 줄어들기 때문"이라는 짤막한 답변이 대부분이었다. @RequestMapping(value="경로", method=RequestMethod.GET) @RequestMapping(value="경로", method=RequestMethod.POST) 이렇게 긴 코드가 @GetMapping("경로") @PostMapping("경로") 이렇게 짧아진다는 설명이다. 참고로 @GetMapping과 @PostMapping 어노테이션은 @PutMapping, @DeleteMapping, @PatchMapping과 함께 스프링 4.3부터 등장했다. 틀린 말은 아니지만 이건 질문..
프로젝트 생성 주요 폴더, 파일 확인 pom.xml 자바 버전, 스프링 프레임워크 버전 수정 버전 참고 Java 8 : 1.8 or 8 Java 9 : 9 Java 10 : 10 Java 11 : 11 Java 12 : 12 필요한 라이브러리 추가 4.0.0 spring.jpa test SpringMVCTest war 1.0.0-BUILD-SNAPSHOT 11 5.2.16.RELEASE 1.6.10 1.6.6 org.springframework.data spring-data-jpa 2.0.1.RELEASE com.oracle.database.jdbc ojdbc8 18.3.0.0 runtime javax.xml.bind jaxb-api 2.3.0 javax.persistence javax.persisten..