반응형

토이프로젝트를 하던 중 쿠키에 특정 값을 만들어 굽는 작업이 필요했다.

따라서 HttpServletResponse에 addCookie를 하여 쿠키를 구워줬지만 브라우저 개발자도구에서 눈을 씻고 찾아봐도 보이지가 않았다...

 

문제는 Cookie의 path를 설정해주지 않아서였다...

 

쿠키의 path를 설정해주지 않으면 현재 경로에서만 only valid하도록 처리되기 때문에

리다이렉트 되면서 유효하지 않기에 사라져 버리는 것이다.

 

[ 문제코드 ]

쿠키에 setPath를 지정해주지 않음...

 

[ 문제 해결 ] 

setPath를 루트로 지정

 

ref : https://stackoverflow.com/questions/35828087/setting-cookie-not-working-in-spring-web-mvc-4

반응형
반응형

[ jQquery ] jQuery(제이쿼리) 플러그인으로 쿠키 다루기


자바스크립트로도 쿠키를 control할 수 있으나~! jQuery Plugin을 이용하면 훨씬 더 직관적으로 쉽게


쿠키를 컨트롤 할 수 있다.


# 자바스크립트로 쿠키의 특정값을 가져오는 경우


# jQuery Plugin을 사용해서 쿠키 특정값을 가져오는 경우



위에서 보듯 자바스크립트를 이용할 때보다 jQyery를 이용하는 방법이 훨씬 직관적이면서 쉬운것을 볼 수 있다.



사용방법


* cdn으로 jquery.cookie.js를 import해준다. (당연히 jQuery는 import되어 있어야겠죠?) 소스코드를 받아 프로젝트에 내장하는걸 권장

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.4.1/jquery.cookie.js"></script>


위의 스크립트를 import해주면 플러그인의 기능을 손쉽게 사용할 수 있다.


[ 쿠키저장 ] - 쿠키는 브라우저가 열려 있는 동안만 유지

$.cookie('key', 'value');


[ 쿠키만료일 지정 ] 

$.cookie('key', 'value', {expires: 값});


[ 쿠키삭제 ] - 특정도메인이 있는 쿠키의 값인 경우 도메인을 명시해주지 않으면 제대로 삭제되지 않는다. 

* expires기간을 오늘 이전 날짜로 셋팅해주면 자동으로 지워진다.

* 쿠키 설정시 domain과 path를 설정했을 경우 삭제시에도 동일하게 옵션으로 전달해야 삭제가능

$.cookie('BID', '', {domain : "toast.com", expires: new Date(2016, 10, 29, 11, 00, 00)});

혹은 다음처롬도 삭제 가능하다.

$.removeCookie('BID', {path: '/',domain: 'toast.com'});


[ 특정시간만료시 삭제 & secure를 true로 설정시 https를 통해서만 쿠키값을 전송가능하다 ] 

$.cookie(visits, 10, {expires: new Date(2019, 10, 29, 11, 00, 00), secure: true});


자바스크립트를 사용하든 jQuery플러그인을 선택하든 선택은 자유:)

반응형
반응형

스프링부트(Springboot) 사용시 java.lang.IllegalArgumentException: An invalid domain Error 해결하기


스프링에서 쿠키에 setDomain을 할 경우 현재 서버의 도메인 및 상위 도메인 외에 다른 도메인을 셋팅하게 되면 에러가 발생한다.


서버 도메인이 test.com인데 다음과 같이 쿠키에 setDomain을 하게되면


cookie.setDomain(".toast.com");


다음과 같은 에러가 발생한다.


java.lang.IllegalArgumentException: An invalid domain [.toast.com] was specified for this cookie

at org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6265CookieProcessor.java:183)

at org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6265CookieProcessor.java:125)

at org.apache.catalina.connector.Response.generateCookieString(Response.java:989)

at org.apache.catalina.connector.Response.addCookie(Response.java:937)

at org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.java:386)

at com.nhnent.demonaid.cms.CookieMatchingServiceController.getAdRequestFromMedia(CookieMatchingServiceController.java:80)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:220)

.

.

.



[ 원인 ] 


tomcat8 버전 이상에서는 Cookie Header를 파싱하는 기본 CookieProcessor가 RFC6265를 기반으로 하고 다음과 같은 속성을 같는다.

5.2.3.  The Domain Attribute

   If the attribute-name case-insensitively matches the string "Domain",
   the user agent MUST process the cookie-av as follows.

   If the attribute-value is empty, the behavior is undefined.  However,
   the user agent SHOULD ignore the cookie-av entirely.

   If the first character of the attribute-value string is %x2E ("."):

      Let cookie-domain be the attribute-value without the leading %x2E
      (".") character.

   Otherwise:

      Let cookie-domain be the entire attribute-value.

   Convert the cookie-domain to lower case.

   Append an attribute to the cookie-attribute-list with an attribute-
   name of Domain and an attribute-value of cookie-domain.


Domain값 맨 앞자리에 "."을 붙일 경우 "."을 제거하고 파싱하게 된다.


[ 해결 ]

SpringBoot를 사용하고 있는 경우(Embedded Tomcat) 다음과 같은 설정을 해주면 된다. 스프링부트 자바 config클래스에 넣어주면 된다.




[ reference ]

https://jistol.github.io/java/2017/08/30/tomcat8-invalid-domain/

http://hyunc87.tistory.com/34

반응형
반응형

 안녕하세요. 오늘은 전에 읽었던 '그림으로 배우는 HTTP&NETWORK BASIC'이라는 책을 간단히 제가 몰랐거나 나중에 다시 한 번 상기가 필요한 내용들로 정리해보려고 합니다. 아무래도 웹 개발을 하다보니 네트워크 지식들이 필요할 때가 많은데요. 중요한 내용을 바탕으로 쉽게 그림으로 잘 설명되어 있는 책을 골라 읽어보았는데 생각보다 괜찮네요. 기본적인 네트워크 지식이 필요하신 분들에게도 좋은 책이 될 것 같네요. 아무래도 제 주관적으로 중요하다 싶은 내용이나 나중에 한 번 더 봐야 될 부분들에 대해서 정리가 될 것 같은데 보시고 괜찮으시다면 책을 사셔서 보시는걸 추천 드리겠습니다.

[ TCP/IP 계층화 ]
-TCP/IP는 '애플리케이션 계층', '트랜스포트 계층(TCP)', '네트워크 계층(IP)', '링크 계층' 이렇게 총 4계층으로 나뉘어 있다.
> 계층화의 메리트는 인터넷이 하나의 프로토콜로 되어 있다면 어디선가 사양이 변경되었을 때 전체를 바꾸지 않으면 안되지만, 계층화되어 있으면 사양이 변경된 해당 계층만 바꾸면 됩니다.

[ 패킷 ]
-패킷이란 전송하는 데이터의 최소 단위 입니다.

[ IP, MAC ]
-IP(Internet Protocl)의 역할은 개개의 패킷을 상대방에게 전달하는 것. 상대방에게 전달하기까지 여러 요소가 필요한데 그 중에서도 IP와 MAC(Media Access Control Address)라는 요소가 중요하다.
IP주소는 각 노드에 부여된 주소를 가리키고 MAC 주소는 각 네트워크 카드에 할당된 고유의 주소이다. IP주소는 변경 가능하지만 기본적으로 MAC 주소는 변경 할 수 없다.

[TCP, Three way handshaking]
-TCP(Transfer Control Protocol)는 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 정확하게 도착했는지 확인하는 역할을 담당한다. TCP는 상대에게 확실하게 데이터를 보내기 위해 "쓰리웨이 핸드셰이킹(three way handshaking)"이라는 방법을 사용하고 있는데 이 방법은 패킷을 보내고 나서 바로 끝내는 것이 아니라, 보내졌는지 여부를 상대에게 확인하러 간다. 이것은 'SYN'와 'ACK'라는 TCP 플래그를 사용한다. 송신측에서는 최초 'SYN'플래그로 상대에게 접속함과 동시에 패킷을 보내고, 수신측에서는 'SYN/ACK' 플래그로 송신측에 접속함과 동시에 패킷을 수신한 사실을 전한다. 마지막으로 송신측이 'ACK' 플래그를 보내 패킷 교환이 완료되었음을 전한다.

[ HTTP, STATLESS PROTOCOL ]
-HTTP는 상태를 계속 유지하지 않는 스테이트리스(stateless)프로토콜로 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않는다. HTTP에서는 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성된다. 프로토콜로서는 과거의 리퀘스트나 리스폰스 정보를 전혀 가지고 있지 않다. 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability)을 확보하기 위해서 이와 같이 간단하게 설계되어 있는 것이다.

[ 지속연결, 파이프라인화 ]
-HTTP/1.1와 일부 HTTP/1.0에서는 TCP 연결 문제를 해결하기 위해 지속연결(Persistent Connections)이라는 방법을 고안하였다.  지속 연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다. 지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인(HTTP pipelining)화를 가능하게 한다. 파이프라인화에 의해서 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것을, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있게 되었다. 지속 연결 < 파이프라인화(리퀘스트 수가 늘어날 수록 현저한 차이)

[ STATELESS PROTOCOL 이점 ]
-상태를 유지하지 않는다는 점에서 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있다. 또한, 단순한 프로토콜이기에 HTTP가 다양한 곳에서 이용되는 측면도 있다.

[ 쿠키 - STATELESS PROTOCOL 문제 해결 ]
-쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다.

[ 인코딩으로 전송 효율을 높이다 ]
-HTTP로 데이터를 전송할 경우 그대로 전송할 수도 있지만 전송할 때에 인코딩을 실시함으로써 전송 효율을 높일 수 있다. 전송할 때 인코딩을 하면 다량의 액세스를 효율 좋게 처리할 수 있다. 단지, 컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비하게 된다.

[ 레인지 리퀘스트 (Range Request) ]
-다운로드 중 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야하는 문제를 해결하기 위해 일반적인 리줌(resume)이라는 기능이 필요하게 되었다. 리줌을 통해 이전에 다운로드를 한 곳에서 부터 다운로드를 재개할 수 있다. 이 기능 실현을 위해서는 엔티티의 범위를 지정해서 다운로드를 할 필요가 있다. 이와 같이 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트라고 부른다.

[ 콘텐츠 네고시에이션 ]
- 서로 다른 언어를 주로 사용하는 브라우저가 같은 URI에 액세스할 때에 각각 영어판 웹 페이지와 한국어판 웹 페이지를 표시하는 구조를 콘텐츠 네고시에이션(Content Negotiation)이라고 부른다.
서버 구동형 네고시에이션(서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리하는 방식)과 에이전트 구동형 네고시에이션(브라우저에서 표시 된 선택지 중에서 유저가 수동으로 선택하는 방법)이 있다.

오늘 포스팅은 여기까지 하도록 하겠습니다. :)



반응형

+ Recent posts