[localStorage]검색결과, 2건
크로스 브라우저 스토로지 (크로스 브라우저 쿠키)
HTML5 에 새로 추가된 Web Storage 는 쿠키와 유사하지만 조금 더 진보된 형태의 클라이언트 저장소를 지원한다. Web Storage 는 영구데이터를 위한 localStorage 와 세션 범위의 SessionStorage 로 나뉘어진다. 자세한 내용은 다음의 글을 참고 바란다
=> [HTML5] Web Storage
localStorage 에 관련한 다음의 질문에 답해 보기 바란다
'크롬 브라우저에서 저장한 localStorage의 값을 사파리 브라우저에서 조회할 수 있는가?'
금방 답 할 수 있으면 일단 다행(?)이다. 그럼 이 질문은 어떤가?
'IE 브라우저에서 저장한 쿠키(Cookie)를 크롬 브라우저에서 조회할 수 있는가?'
이 두 질문은 동일한 이슈를 다루고 있다. 즉 '크로스브라우저(Cross Browser)' 이슈이다
크로스 브라우저는 각기 다른 브라우저 환경을 말하며, '크로스 브라우저 가능' 이라는 말은 브라우저가 달라도 기술의 구현이나 사용은 동일(일관)하다는 의미로 해석된다
다시 질문으로 돌아가 보자
HTML5의 localStorage 까지 갈 것도 없이, 쿠키(Cookie)의 크로스 브라우저 문제를 생각해 보자.
'각기 다른 브라우저(크롬,사파리,파이어폭스,오페라 등)에서 쿠키의 공유가 가능한가?' 하는 문제이다
좀 더 현실적인 예로 다시 풀어 보면,
'쿠키로 사용자 인증 처리를 하는 사이트의 경우 IE에서 로그인한 사용자가 크롬에서 해당 사이트에 접근했을 때 로그인이 유지되는가?' 하는 문제이다
이전에 한번이라도 이와 유사한 이슈를 경험해 본 사람은 쉽게 답할 수 있을 것이다
그러나 모르긴 몰라도 꽤 많은 사람이 헷갈려 하지 않나 싶다(이 글을 쓰는 나 역시 헷갈렸다 ㅡ.ㅡ)
크로스브라우저 쿠키의 착각, IE 의존성이 가져온 결과?
고민(?)의 발단은 이러했다
HTML5의 localStorage 를 위한 저장소는 각 브라우저별로 서로 다른, 즉 자신만의 위치에 데이터를 저장하기 때문에 '크로스 브라우저 스토로지'가 지원되지 않는다는 자연스러운(?) 결론에 이르게 되었다
그러나 한편 생각해 보면 여러 브라우저를 사용하는 사람에게는 꽤 문제가 될 수 있지 않나 싶었다
기껏 유용한(또는 주요한) 정보를 localStorage 에 저장해 뒀는데 다른 브라우저로 접근하면 사용할 수 없다는 것은 사이트 개발자는 물론 사용자의 불편을 야기시킬 수 있기 때문이다
이즈음 든 생각은, '그럼 쿠키는?' 이었다
여기서 나의 착각이 시작되었다. 순간 당연히 쿠키는 크로스 브라우저가 된다고 생각한 것이다
'쿠키는 크로스브라우저가 가능한데 쿠키의 개선 버전이라는 localStroage 가 안되다니?'
'이건 뭐 제약사항이 하나 더 늘었구만!!' 하는 어처구니 없는 착각 ^^;
하지만 웹 실무를 벗어난지 꽤 오랜 시간 되었고 이건 착각일 수도 있겠다라는 의문이 들어 테스트를 해 보기로 했다.
테스트 결과, 당연히 될 줄로만 알았던 '크로스 브라우저 쿠키'가 안되는 것이었다
음.. 이건 뭥미? 하며 잠시 멍 때린 후, 생각을 정리하기로 했다
'그래, 쿠키가 표준이지 쿠키 저장소가 표준은 아니다' 라는 것이다
즉 웹을 위한 클라이언트 측 데이터 저장소로써 쿠키라는 개념이 통용되지만 그 저장 위치는 정해져 있지 않다는 것이다. 곰곰히 생각해 보면 저장 위치를 딱 한 곳으로 표준화 할 수도 없다는 것이다
이러한 나의 착각은 어디에서 비롯되었을까? 하고 생각해 봤더니, 'IE 의존적인 개발로 인한 착각' 이라는 생각이 들었다.(물론 제대로 알지 못한 나 자신이 1차 문제인건 안다 ㅡ.ㅡ)
내가 한참 웹 개발 실무를 디테일하게 수행했던 시기는 2000년대 초반이었으며 그 당시에는 지금보다 훨씬 더 IE 의존적인 환경이었다. 웹 2.0 이라는 트랜드도 낯설었거니와 몇몇 독특한 사람을 제외하고는 거의 대부분의 사람이 IE를 사용하고 있었으며 웹 표준이라는 개념 역시 지금처럼 일반화되지 않는 시기였다. 따라서 대부분의 웹 개발은 IE 를 기준으로 작성되었으며 크로스브라우저 테스트는 거의 해 보지 않았다는 것이다. (간혹 여러개의 브라우저를 띄워서 데이터 공유가 되는가.. 하는 등의 테스트는 해 보았지만, 이것 역시 IE를 여러개 띄운 테스트가 대부분이었다)
결국 IE 의존적인 개발은, IE 에 한정된 테스트 환경에 그쳤으며 IE 적 개념이 점차 정립된 것이다
'크로스브라우저 쿠키의 착각'도 이러한 IE 의존성에서 비롯되었다라고 해도 과언은 아닐 듯 싶다
(물론 제대로 된 조직 및 개인은 그 당시에도 크로스 브라우저 테스트및 개념이 있었겠죠?
이 글은 저의 경우, 저의 착각에 한해 예기 하는 것이니 오해 사절 입니다)
지금에야 아이폰을 필두로 한 모바일 웹의 급 부상, 이미 오래된 웹 2.0 트랜드, 웹 표준 이슈, HTML5 등장, 과거와는 다른 브라우저간 경쟁 및 발전으로 IE 의존성이 점차 해소되는 분위기이며 특히 개발자들은 더욱 다양한 브라우저를 체험하고 있다.
사실 나 역시 모바일 웹, HTML5에 관심을 두기 전에는 거의 IE만 사용했었다
근래 들어 크롬, 사파리, 파이어폭스, 오페라와 같은 브라우저를 동시에 사용하고 있다.
이 글 역시 여러 브라우저를 동시에 사용했기에 든 의문이며 그렇지 않다면 꽤 오랜시간 착각과 망각속에 살지 않았겠나.. 싶다
크로스 브라우저 쿠키, 크로스 브라우저 스토로지, 가능한 시나리오는 없는가?
브라우저를 넘나드는 클라이언트 데이터 저장소의 실현을 고민해 보자
크로스 환경이 필요한가를 먼저 따지자
우선 원론적인 질문을 해 보자. '브라우저 경계를 넘어서는 데이터 공유가 필요한가?' 이다
다시 말해 IE에서 저장한 데이터를 크롬에서 불어와야 되는가? 하는 것이다
예를 들어 IE에서 로그인한 사용자가 크롬에서도 여전히 로그인이 되어 있어야 하는가? 이다
매우 크리티컬한 이슈가 아니라면 적당히 양보(?)할 수도 있을 것이다
크로스 브라우저가 정말로 필요한지? 서버측 데이터 공유로 풀어도 되지 않는지? 하는 원론적인 고민을 해 보고 반드시 그럴 필요가 없다면 굳이 크로스 환경을 지원하지 않아도 된다는 말이다
그러나 반드시 크로스 환경이 보장되어야 한다면 다음 글로 넘어가자
브라우저마다 각각 저장하자
불편하기는 하지만 가장 심플한 해결책이다
매번 브라우저에서 쿠키가 존재하는지 검사하고 없다면 쿠키를 기록하는 것이다
예를 들어 IE에서 쿠키를 저장하고 크롬에서 쿠키를 읽어 올때 존재하지 않는다면 다시 쿠키를 기록하도록 하는 것이다. 다른 브라우저도 마찬가지로.
사용자 인증 시나리오에서 이 기법이 적용된다면 사용자는 브라우저를 교체할 때 로그인을 다시 해야 하는 불편은 감수해야 한다. 그러나 용납할 만한 수준이지 않는가
(이 시나리오는 HTML5 localStorage에도 그대로 적용된다)
플래시의 Shared Object 를 이용하라
플래시에는 클라이언트 측 데이터 저장과 공유를 위한 Shared Object 라는것이 존재한다
플래시 런타임은 브라우저와는 별도의 플러그인 환경이기 때문에 브라우저가 달라진다고 해서 문제될 것이 없다. 다만 플래시 런타임이 브라우저에 설치되어 있어야 한다는 문제가 있다
웹 표준, 특히 아이폰과 같은 모바일 환경에서는 무리수 일 수 있다는 것이다
PersistJS 라이브러리를 이용하라
Paul Duncan 이라는 사람이 만든 라이브러리이다. 클라이언트 측 자바스크립트 영구 저장소를 구현한 것이다. 플래시 플레이어와 같은 별도의 플러그인이 필요 없으며 크로스 브라우저를 지원하는 API가 제공된다. 이 라이브러리를 직접 이용해 보진 않았지만 아마 locaStroage나 Shared Object 와 같은 기존 스토로지 솔루션에 기반하여 데이터를 저장하며 크로스 브라우저를 위한 자동화된 처리가 포함된 듯 하다. 관심 있는 자 테스트 해 보기 바란다. 아래 주소에서 라이브러리 다운로드 및 확인이 가능하다.
http://pablotron.org/?cid=1557
'모바일 > HTML5' 카테고리의 다른 글
MS의 고뇌?, 실버라이트와 HTML5 (8) | 2010.09.16 |
---|---|
[HTML5실습]드래그앤드롭:외부파일을 웹페이지로 끌어다 놓기 (9) | 2010.09.15 |
[CSS3] Animation (18) | 2010.09.13 |
[CSS3] Transform (10) | 2010.09.10 |
[CSS3] Transition (10) | 2010.09.09 |
클라이언트에 데이터를 저장하다
HTML 5 에는 웹 사이트의 데이터를 클라이언트에 저장할 수 있는 새로운 자료구조인
Web Storage(웹 스토로지) 스펙이 포함되었다
Web Storage 의 개념은 심플하다
'키/ 값' 쌍으로 데이터를 저장하고 키를 기반으로 데이터를 조회하는 패턴이다
그리고 영구저장소(localStorage) 와 임시저장소(sessionStorage)를 따로 두어
데이터의 지속성을 구분할 수 있어 응용 환경에 맞는 선택이 가능하다
Web Storage 는 기존 웹 환경의 쿠키(Cookie)와 매우 유사한 개념이다
사실 거의 차이가 없어 보이기도 하다. 다만 몇 가지 쿠키의 단점를 극복하는 개선점이 도입되었다
그럼 쿠키(Cookie)는?
쿠키는 여전히 유효하고 꽤 적절한 클라이언트 저장도구 이다
HTML 5 에서 Web Storage 스펙을 새로 추가했지만 쿠키를 배제하는 것은 아니다
HTML 5 환경에서도 여전히 쿠키를 이용할 수 있다
다만 어떤 것을 사용할 지는 사용자 선택의 몫이라 하겠다
Web Storage 차이점 (쿠키의 단점?)
- 쿠키는 매번 서버로 전송 된다
웹 사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송된다
Web Storage 는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어지지 않는다
이것은 네트워크 트래픽 비용을 줄여 준다는 주요한 장점이 되겠다
- 단순 문자열을 넘어 (스크립트) 객체정보를 저장할 수 있다
문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있다는 것은 개발 편의성을
제공해 주는 주요한 장점이 된다. 브라우저의 지원 여부를 확인해 봐야 하는 항목이다
- 용량의 제한이 없다
쿠키는 개수와 용량에 있어 제한을 걸어 두고 있다
하나의 사이트에서 저장할 수 있는 최대 쿠키 수는 20 개이다. 그리고 하나의 사이트에서 저장할 수 있는 최대 쿠키 크기는 4KB 로 제한되어 있다. Web Storage 는 이러한 제한이 없다
(그러나 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수 있다.
그리고 대부분의 시나리오에서 쿠키의 제한으로 까지 데이터를 저장할 일이 없다)
- 영구 데이터 저장이 가능하다
쿠키는 만료일자를 지정하게 되어 있어 언젠가 제거된다.
만료일자로 지정된 날짜에 쿠키는 제거되는 것이다.(만료일자를 지정하지 않으면 세션 쿠키가 된다)
만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결하기도 하였다
(그러나 과연 수 년이 지나도록 쿠키가 유지되어야 할 필요가 있을까?)
WebStorage 는 만료기간의 설정이 없다. 즉 한번 저장한 데이터는 영구적으로 존재하는 것이다
이것이 특별히 장점이 되는지는 잘 모르겠지만 쿠키와의 차이점이라는 것은 분명하다
-----
쿠키와 WebStorage 의 차이점과 개선사항에 대해 알아 보았는데 개인적으로,
Web Storage 가 쿠키보다 훨씬 좋은 이유는 없다고 본다.
다만 한가지 매번 서버로 전송되지 않는다는 특징은 꽤나 유용해 보인다
(특히 경량 환경인 모바일에서는 더욱 더)
그리고 쿠키는 더 상세한 설정이 가능해 어떤 환경에서는 더 적합해 보이기 까지 한다
쿠키에 대한 자세한 내용은 다음의 글을 참고하도록 하자
=> Cookie 제대로 알고 사용하자
로컬 스토로지(localStorage)와 세션 스토로지(SessionStorage)
Web Storgae 는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다
우선 기본적으로 Web Storage 는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다
다시말해, A 도메인에서 저장한 데이터는 B 도메인에서 조회할 수 없다는 것이다
이것은 데이터의 보안적 측면에서 당연한 원칙이라 하겠다
- 로컬 스토로지
로컬 스토로지 저장한 데이터를 (명시적으로) 지우지 않는 이상 영구적으로 보관한다
앞서 말한대로, 도메인마다 별도로 로컬 스토로지가 생성된다
windows 전역 객체의 localStorage 라는 컬렉션을 통해 저장/조회가 이루어진다
- 세션 스토로지
세션스토로지는 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다
세션스토로지는 windows 전역 객체의 sessionStorage 라는 컬렉션을 통해 저장/조회가 이루어진다
데이터 유지 측면:
세션 스토로지는 데이터가 지속적으로 보관되지 않는다
이는 마치 브라우저 기반 세션 쿠키와 그 성질이 비슷한데, 현재 페이지가 브라우징 되고 있는
브라우저 컨텍스트 내에서만 데이터가 유지된다
로컬 스토로지는 브라우저를 종료해도 데이터는 보관되어 다음번 접속에도 그 데이터를
사용할 수 있는 반면, 세션 스토로지는 브라우저가 종료되면 데이터도 같이 지워진다.
즉 브라우저가 종료되면 세션 스토로지도 삭제된다는 것이다
데이터 범위 측면:
세션 스토로지 역시 Web Storage 의 기본 보안 처럼 도메인별로 별도로 생성된다
여기에 더불어 세션 스토로지는 같은 사이트의 같은 도메인이라 할지라도 브라우저가 다르면
서로 다른 영역이 된다(즉 브라우저 컨텍스트가 다르다)
탭 브라우징이나 브라우저를 하나 더 실행해서 같은 페이지를 실행했을 때,
이 두 페이지의 세션 스토로지는 각각 별개의 영역으로 서로 침범하지 못한다는 의미이다
(도메인만 같으면 전역적으로 공유 가능한 로컬스토로지와 구분되는 특징이라 하겠다)
브라우저 지원 현황
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Web Storage 지원 표이다
(데스크탑 용 브라우저 기준이다)
대부분의 브라우저에서 Web Storage 를 지원하고 있다
특이한 것은 MS의 IE 의 경우 8.0 까지는 대부분의 HTML5 신기능이 지원되지 않는 반면
Web Storage 는 IE 8.0 에서도 지원하는 것으로 나와있다
그리고 아이폰의 사파리에서 테스트를 해 보니 정상적으로 동작하는 것을 확인하였다
다음의 코드로 브라우저 지원 여부를 체크해 볼 수 있다
alert("현재 브라우저는 WebStorage를 지원합니다")
}
else{
alert("현재 브라우저는 WebStorage를 지원하지 않습니다")
}
Web Storage 데모 만들어 보기
로컬스토로지와 세션스토로지를 이용하는 간단한 데모를 만들어 보자
<html>
<head>
<script type="text/javascript">
//로컬스토로지에 저장
function setLocalStorage(){
var textBox = document.querySelector('#textBox1');
window.localStorage['key1'] = textBox.value;
}
//로컬스토로지 조회
function getLocalStorage(){
var textBox = document.querySelector('#textBox2');
textBox.value = window.localStorage['key1'];
}
//세션스토로지에 저장
function setSessionStorage(){
var textBox = document.querySelector('#textBox3');
window.sessionStorage['key1'] = textBox.value;
}
//세션스토로지 조회
function getSessionStorage(){
var textBox = document.querySelector('#textBox4');
textBox.value = window.sessionStorage['key1'];
}
</script>
</head>
<body>
<input type="text" id="textBox1">
<button onclick="setLocalStorage()">로컬스토로지 저장</button>
<br>
<input type="text" id="textBox2">
<button onclick="getLocalStorage()">로컬스토로지 조회</button>
<hr>
<input type="text" id="textBox3">
<button onclick="setSessionStorage()">세션스토로지 저장</button>
<br>
<input type="text" id="textBox4">
<button onclick="getSessionStorage()">세션스토로지 조회</button>
</body>
</html>
아래는 실행화면인데 로컬스토로지와 세션스토로지의 저장소가 각각 분리되어 있는 것을 알 수 있다
그리고 각 스토로지에 Local Files 라고 되어 있는 것은 현재 데모 실행 환경이
로컬 파일 기반인 file//..... 로 되어 있기 때문이다
만일 특정 도메인에서 실행한다면 Local Files 대신 도메인 명이 나타날 것이다
그리고 새로운 탭을 열어서 같은 페이지를 실행 해 보면,
이전 탭 페이지에서 실행한 로컬스토로지 값은 여전히 유효한 반면
세션스토로지는 서로 공유되지 않고 별도의 저장소를 따로 가진다는 것을 알 수 있다
세션 스토로지와 새창(window.open)
앞서 세션 스토로지는 탭 브라우징이나 새로 실행한 브라우저끼리는 별도의 저장 영역이라 하였다
그렇다면 페이지에서 window.open으로 생성한 새로운 창과 기존 창과의 세션 스토로지 공유는 어떨까?
실제로 어떤 페이지에서 프로그램 논리에 의해 open 하는 창은 물리적으로는 새창이지만,
논리적으로 전혀 별개의 창이라 볼 수 없다.
즉 세션 스토로지 데이터가 이 둘간의 공유가 이루어지는 것이 더 합당해 보인다는 말이다
HTML5 Web Storage 은 이러한 경우 조금 중간적 적인 입장을 취하고 있는 듯 하다
즉 windows.open 으로 띄운 새 창은 새로운 브라우저 컨텍스트로 인식하여
세션스토로지가 따로 생성,관리되지만 최초 데이터는 복사되어 진다는 것이다
다시말해 A 페이지에서 저장한 세션스토로지 값이 새창을 띄울 때 복사되어 전달되고
이후부터는 이 둘의 영역은 전혀 별개의 영역이 된다는 것이다
결국 세션 스토로지는 각각의 브라우저(윈도우, 창, 실제로는 브라우저 컨텍스트)는 서로 독립된
각각의 세션 스토로지를 가진다는 특징이 있는 것이다
클라이언트에서는 값을 얼마든지 수정할 수 있다
Web Storage 의 보안은 서로 다른 도메인의 데이터 침범을 막고는 있지만 클라이언트,
즉 사용자를 막고 있지는 않다. 클라이언트는 얼마든지 저장된 값을 (임의로) 수정할 수 있다
이것은 이전 쿠키와 완전 동일한 개념이다
아래 그림은 구글 크롬 브라우저에서 개발자 도구를 실행한 모습인데,
Wb Storage 에 저장된 값을 수정하거나 삭제 할 수 있는 것을 알 수 있다
클라이언트가 저장된 값을 임의로 변경 할 수 있다는 것은 쿠키와 동일한 개념으로 별다른 보안 취약점을 더 가진 것은 아니다. 따라서 웹 사이트 개발자는 사용자에 의한 이러한 임의 변경에 항상 예의 주시하고 방어 코드의 작성을 잊지 말아야 하겠다
다음의 사이트에서 추가 내용과 데모를 확인해 보기 바란다
http://www.ibm.com/developerworks/kr/library/x-html5mobile2/
http://html5demos.com/storage
'모바일 > HTML5' 카테고리의 다른 글
[HTML5] Web SQL Database (5) | 2010.08.17 |
---|---|
[HTML5] 오프라인 웹 어플리케이션 (5) | 2010.08.12 |
[HTML5] 드래그 앤 드롭 (Drag & Drop) (7) | 2010.08.10 |
[HTML5] Geolocation (5) | 2010.08.09 |
[HTML5] Web Workers (웹 워커) (5) | 2010.08.05 |