Jquery cookie 사용하기

POSTED AT 2012/01/09 11:40 | POSTED IN DEV/JQUERY

다운로드 경로 : https://github.com/carhartl/jquery-cookie

간단 사용법

js 파일(jquery.cookie.js) 임포트 한 후

<쿠키생성>

1. 세션 쿠키(Session Cookie)

세션 쿠키는 브라우저 열려있는 동안만 유지된다

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

2. 만료일 지정한 쿠키

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

값의 단위는 일(日)단위 이다

주의할 점은 위 생성방식 모두 디폴트로 쿠키가 만들어진 페이지 경로에만 쿠키가 적용된다

모든 페이지에 쿠키를 적용하려면 아래와 같이 path : '/' 를 설정 해야 한다

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

$.cookie('key' , 'value', { path : '/' });

<쿠키 읽기>

$.cookie('key');

위처럼 하면 저장된 값을 반환한다. 해당 key가 없다면 null 반환

<쿠키삭제>

$.cookie('key', null);

path 옵션을 주어 쿠키를 만들었다면 삭제할때 역시 같은 path 옵션을 줌 (이것 떄문에 삽질 대박함)

<쿠키 생성시 옵션 항목>

expires : 365

쿠키 만료를 일단위로 설정한다 생략하면 세션 쿠키로 만들어진다

path : '/'

쿠키가 적용되는 페이지 경로. 사이트 전체 페이지에 적용하려면 위와같이 설정

domain : 'domain.com'

쿠키가 적용될 도메인 디폴트가 쿠키가 만들어진 도메인이다

secure : true

디폴트는 false 다. true로 설정하면 쿠키전송은 https 프로토콜로만 가능

raw : true

디폴트는 false이다 false 일 경우는 쿠키는 생성되거나 읽을 떄 기본적으로 인코딩/디코딩을 한다(encodeURIComponent / decodeURIComponent 이용)



출처 - http://pengs.pe.kr/294


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


<script language="JavaScript">
<!--
     // 쿠키 생성
     function setCookie(cName, cValue, cDay){
          var expire = new Date();
          expire.setDate(expire.getDate() + cDay);
          cookies = cName + '=' + escape(cValue) + '; path=/ '; // 한글 깨짐을 막기위해 escape(cValue)를 합니다.
          if(typeof cDay != 'undefined') cookies += ';expires=' + expire.toGMTString() + ';';
          document.cookie = cookies;
     }

     // 쿠키 가져오기
     function getCookie(cName) {
          cName = cName + '=';
          var cookieData = document.cookie;
          var start = cookieData.indexOf(cName);
          var cValue = '';
          if(start != -1){
               start += cName.length;
               var end = cookieData.indexOf(';', start);
               if(end == -1)end = cookieData.length;
               cValue = cookieData.substring(start, end);
          }
          return unescape(cValue);
     }
//-->
</script>

쿠키 생성 버튼을 누른 후 쿠키 보기를 눌러 보세요.<br>
쿠키 삭제 버튼을 누른 후 쿠키 보기도 눌러 보세요.<br>
<br>
쿠키 생성 버튼을 누른 후 이 페이지를 닫고 다시 들어와서 쿠키 보기를 눌러보세요.<br>
<br>

<input type="button" value="쿠키 생성" onclick="setCookie('test', 'cookie test, 쿠키 테스트', 1)">
<input type="button" value="쿠키 보기" onclick="alert(getCookie('test'))">
<input type="button" value="쿠키 삭제" onclick="setCookie('test', '', -1)">

 소스 설명

setCookie() - 쿠키를 만드는 함수입니다.
setCookie('쿠키이름', '쿠키값', 만료일)

쿠키이름 : 쿠키이름을 영문으로 넣어주세요.
쿠키값 : 쿠키의 값을 문자열로 넣어주세요.
만료일 : 쿠키의 만료일을 숫자로 넣어주세요
예) 만료일이 1 이면 하루동안 지속되는 쿠키입니다.
예) 만료일이 -1 이면 쿠키가 삭제됩니다.


getCookie() - 쿠키값을 가져오는 함수입니다.
getCookie('쿠키이름')

쿠키이름을 넣어 주면 해당 쿠키의 값을 반환합니다. 쿠키가 있을때만 반환하며
없으면 공백이 반환됩니다.

출처 - http://www.superkts.pe.kr/helper/view.php?seq=263&PHPSESSID=cdf657ead7ae8cc1489d107afa893f49

Posted by linuxism
,

OAuth

Security/OAuth 2012. 5. 22. 09:25


OAuth는 OpenAPI로 개발된 표준 인증 방식으로, 각종 애플리케이션에서 사용자 인증을 거칠때 활용될 수 있다.

목차

  [숨기기

[편집]개요

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디과 비밀번호를 사용하였는데, 이는 보안상 취약한 구조이다.

기본인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였다. 예를 들면 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있다.

OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다.

[편집]역사

2006년 11월 브래인 쿡은 트위터에 OpenID를 탑재하는 작업을 하고 있었다. 같은 시기, 소셜 북마크 사이트인 Ma.gnolia는, 회원이 OpenID를 사용하여 대시보드 위젯으로 서비스에 접속할 수 있는 인증 방법을 필요로 하고 있었다. 이에 쿡, 크리스 메시나, 래리 하프(Ma.gnolia)는 데이비드 리코던(당시 베리사인)과 만나 OpenID를 활용해 트위터나 Ma.gnolia의 API로 인증을 위임하는 방법을 논의했다. 그 결과, API 접근 위임에 대한 공개 표준이 아직 존재하지 않는다는 결론에 이르렀다.

OAuth의 인터넷 커뮤니티는 2007년 4월에 탄생하여, 소수 인원으로 새로운 공개 프로토콜의 초안을 썼다. OAuth 프로젝트를 알게 된 구글의 드위트 클린턴은 지원을 표명했다. 2007년 7월, 팀은 사양 초안을 완성시켰다. 에런 해머래해브가 가세하여 많은 협력자들의 조정을 실시하여, 보다 정식적인 사양을 작성해나갔다. 2007년 10월 3일, OAuth 코어 1.0의 최종 초안이 발표되었다.

2008년 11월, 미네아폴리스에서 열린 제73회의 IETF 회합에서 OAuth의 비공식 회합도 열려 새로운 표준화를 향해 IETF에 OAuth 프로토콜을 제안할지를 논의했다. 회합은 성황을 이루었고 IETF에서 정식으로 OAuth 작업모임을 발족시키는 일에 폭넓은 지지를 얻을 수 있었다.

[편집]용어

OAuth에 관련된 용어들을 간략히 설명한다.

  • 사용자(user): 서비스 공급자와 소비자를 사용하는 계정을 가지고 있는 개인
  • 소비자(consumer): Open API를 이용하여 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션
  • 서비스 공급자(service provider): OAuth를 통해 접근을 지원하는 웹 애플리케이션(Open API를 제공하는 서비스)
  • 소비자 비밀번호(consumer secret) : 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
  • 요청 토큰(request token) : 소비자가 사용자에게 접근권한을 인증받기 위해 필요한 정보가 담겨있으며 후에 접근 토큰으로 변환된다.
  • 접근 토큰(access token) : 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해서 보호된 자원에 접근하기 위한 키를 포함한 값.

[편집]인증방식

OAuth인증은 소비자와 서비스 공급자 사이에서 일어나는데 이 인증 과정은 다음과 같다.[1]

  1. 소비자가 서비스제공자에게 요청토큰을 요청한다.
  2. 서비스제공자가 소비자에게 요청토큰을 발급해준다.
  3. 소비자가 사용자를 서비스제공자로 이동시킨다. 여기서 사용자 인증이 수행된다.
  4. 서비스제공자가 사용자를 소비자로 이동시킨다.
  5. 소비자가 접근토큰을 요청한다.
  6. 서비스제공자가 접근토큰을 발급한다.
  7. 발급된 접근토큰을 이용하여 소비자에서 사용자 정보에 접근한다.

[편집]주석

  1.  http://oauth.net/core/diagram.png

[편집]같이 보기

[편집]바깥 고리



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


OAuth (오오스 [1] )은 브레인 쿡 과 크리스 메시나 시작한 개방형 프로토콜이며, 데스크톱, 모바일 Web 애플 리케이션과 같은 보안 API 인증(authorization)의 표준 방법을 제공한다.

OAuth logo

목차

  [ 숨기기 ] 

배경 편집 ]

매시 업 에 따르면 Web 서비스 제휴가 증가하고 디지털 ID 공유가 문제가되었다. OpenID 와 같은 연합 아이덴티티 가 해결책으로 등장했지만, 이것은 ID 소유자의 인증 수단이며,이를 통해 자원에 액세스할 수 있는지하는 허가 는 다루고 있지 않다. 있는 Web 서비스 A 사용자의 개인 정보가있을 때, 그 Web 서비스 A와 다른 Web 서비스 B가 연계하여 Web 서비스 A의 개인 정보를 Web 서비스 B가 자유롭게 접근할 수있는 상황은 바람직하지 않다. 따라서 Web 서비스 API에 대한 액세스를 허용하는 수단이 필요했다.

역사 편집 ]

2006 년 11 월, 브레인 쿡 Twitter 에서 OpenID 구현을하고 있었다. 같은 무렵, 소셜 북마크 사이트 Ma.gnolia는 회원이 OpenID를 사용하여 Dashboard 위젯 서비스에 액세스하는 것을 허용하는 방법을 필요로하고 있었다. 그래서 쿡과 크리스 메시나, Ma.gnolia 래리 하프는 데이비드 리코돈 (당시 베리사인 )와 만나, OpenID를 사용하여 Twitter 나 Ma.gnolia의 API 인증 위임하는 방법을 논의했다. 그 결과 API 액세스 위임에 대한 개방형 표준 은 아직 존재하지 않는다는 결론에 도달했다.

OAuth의 인터넷 커뮤니티 는 2007 년 4 월에 탄생한 소수 인원으로 새로운 오픈 프로토콜의 초안을 썼다. OAuth 프로젝트 것을 알았 Google 의 데위토 클린턴은 지원을 표명했다. 2007 년 7 월 팀 사양의 초안을 완성시켰다. Eran Hammer-Lahav가 더해져 많은 협력자의 조정 더 공식적인 사양을 만들어 갔다.2007 년 10 월 3 일 , OAuth Core 1.0의 최종 초안이 발표되었다.

2008 년 11 월 미니 애폴리스 에서 열린 제 73 회 IETF 회의에서 OAuth 비공식 회의도 열려 새로운 표준을 위해 IETF에 OAuth 프로토콜을 제안할지 여부를 논의했다. 회의는 성황으로, IETF에서 정식으로 OAUTH 워킹 그룹을 시작하게 폭넓은지지를 얻었다.

보안 편집 ]

2009 년 4 월 23 일 , OAuth 보안 문제가 있음이 밝혀졌다. 이것은 OAuth Core 1.0 Section 6에 OAuth 인증 흐름 (3-legged OAuth)에 영향을 [2] . 앞으로이 문제를 해결 사양이 공개 예정이다.

OAuth 2.0 편집 ]

OAuth 2.0은 차세대 OAuth 프로토콜이며, OAuth 1.0과 하위 호환성을 가지지 않는다. OAuth 2.0은 클라이언트가되는 응용 프로그램 개발자들에게 웹 애플 리케이션, 데스크톱 응용 프로그램, 스마트폰, 거실 장치의 특정 인증 절차에 대한 간단한 액세스를 제공한다. 이 기획은 개발 도상국이다. [3] Eran Hammer-Lahav 에 따르면 IETF OAuth 작업 그룹은 2010 년 말경까지 범위에서 체결을 기대하고있다. [4]

facebook 의 새로운 Graph API 는 OAuth 2.0 만 지원, 진성의 표준으로 최대의 구현이다. [5] 2011 년 현재 Google [6] 와 마이크로 소프트 는 [7] OAuth 2.0의 실험적인 API를 제공하고있다.

각주 편집 ]

  1. For immediate release : OAuth Core 1.0 Specification released at Internet Identity Workshop 공식 블로그에 "OAuth (pronounced"Oh-Auth ")"의 기재있어
  2. Oauth ( 2009 년 4 월 23 일 ) " OAuth Security Advisory : 2009.1 " 2009 년 4 월 23 일 보기.
  3. The OAuth 2.0 Authorization Protocol "( 2011 년 2 월 16 일 ) 2011 년 11 월 28 일 보기.
  4. Eran Hammer-Lavah ( 2010 년 5 월 15 일 ) " Introducing OAuth 2.0 " 2011 년 3 월 14 일 보기.
  5. Authentication - Facebook Developers " developers.facebook.com . 2011 년 11 월 28 일 보기.
  6. Making auth easier : OAuth 2.0 for Google APIs " googlecode.blogspot.com ( 2011 년 3 월 14 일 ) 2011 년 11 월 28 일 보기.
  7. Dare Obasanjo ( 2011 년 5 월 4 일 ) " Announcing Support for OAuth 2.0 " windowsteamblog.com . 2011 년 11 월 28 일 보기.

관련 항목 편집 ]

외부 링크 편집 ]


출처 - wikipedia








'Security > OAuth' 카테고리의 다른 글

OAuth 2.0 구현  (2) 2014.01.01
OAuth 2.0 이해  (0) 2013.12.29
OAuth 1.0a 이해  (0) 2013.12.29
Posted by linuxism
,


tier, tiered, multitier, and multitiered ; 계층, 다중계층, 티어, 멀티티어

일반적으로 tier[티어]란 일련의 비슷한 객체가 나열된 상태에서, 열 또는 계층을 의미한다. 컴퓨터 프로그래밍에서, 프로그램의 일부가 여러 계층에 나뉘어 존재할 수 있으며, 그 계층 또한 네트웍 상의 서로 다른 컴퓨터에 위치할 수 있다. 바로 이러한 프로그램을 두고, "계층화되었다"라고 말한다.

3-tier[쓰리티어] 응용 모델이 네트웍 상에서 프로그램을 구성하는 가장 일반적인 방법일 것이다 .


3-tier application ; 3 계층 애플리케이션

3 계층 애플리케이션이란 3개의 주요 부분으로 구성되어 있는 응용프로그램으로서, 각각은 네트웍 상의 서로 다른 장소에 분산되어 있다. 여기서 3개의 주요부분이란 다음과 같다.

전형적인 3 계층 애플리케이션에서, 프로그램 사용자의 워크스테이션은 GUI를 제공하는 프로그램과, 특정 프로그램에 맞는 입력 양식이나 인터랙티브 윈도우 등을 가지고 있다 (워크스테이션 사용자를 위한 일부 독특한 데이터는 사용자의 하드디스크에도 함께 보관된다).

비즈니스 로직은 근거리통신망 서버 또는 다른 공유된 컴퓨터 상에 위치한다. 비즈니스 로직은 워크스테이션으로부터의 클라이언트 요청에 대해 마치 서버처럼 행동한다. 그것은 차례로 어떤 데이터가 필요한지를 결정하고, 메인프레임 컴퓨터 상에 위치하고 있을 세 번째 계층의 프로그램에 대해서는 마치 클라이언트처럼 행동한다.

세 번째 계층은 데이터베이스와 그것에 액세스해서 읽거나 쓰는 것을 관리하는 프로그램을 포함한다. 애플리케이션의 조직은 이것보다 더욱 복잡해질 수 있지만, 3 계층 관점은 대규모 프로그램에서 일부분에 관해 생각하기에 편리한 방법이다.

3 계층 애플리케이션은 클라이언트/서버 컴퓨팅 모델을 사용한다. 3 계층에서, 각 부분은 각기 다른 팀의 프로그래머들에 의해 각기 다른 언어를 사용하여 동시에 개발될 수 있다. 어떤 한 계층의 프로그램은 다른 계층에 영향을 주지 않고도 변경되거나 위치가 달라질 수 있기 때문에, 3 계층 모델은 새로운 요구나 기회가 생길 때마다 애플리케이션을 지속적으로 진화시켜야하는 기업이나 소프트웨어 패키지 개발자들이 이에 쉽게 대처할 수 있게 해준다. 기존의 애플리케이션들은 영구적으로 또는 일시적으로 계속 유지될 수 있으며, 하나의 컴포넌트로서 새로운 계층 내에 캡슐화될 수도 있다.

3 계층 애플리케이션 아키텍처는 분산 객체지향 프로그래밍과 사상이 일치한다.

미국의 버펄로 대학의 한 논문에서 원격처리 프로그램을 클라이언트/서버로 구현하는데 있어 3계층과 2계층 아키텍처를 비교한 자료를 제공합니다.


출처 - terms.co.kr





'Framework & Platform > Common' 카테고리의 다른 글

OSGi(Open Service Gateway initiative)  (0) 2012.03.25
모델1과 모델2의 차이점  (0) 2012.03.21
log4j.properties  (0) 2012.03.19
디자인 패턴  (0) 2012.03.18
Refactoring  (0) 2012.03.18
Posted by linuxism
,