http://misako.co.kr/articles/HttpVSHttps.aspx

에서 참조

 

HTTP 대 HTTPS : 뭐가 다른가?

신정훈

  웹 브라우저의 주소창을 자세히 보면 http://나 https://로 시작한다. 사실 http://는 하도 흔해서 생략하고 주소를 쳐도, 웹 브라우저가 알아서 http://를 넣어 준다. 어제 인터넷에서 GMail 옵션 중에 항상 https를 사용하도록 하는 옵션이 있다고 그걸 쓰라는 글을 보았다. 거기 달린 답글 중에 두 개가 뭐가 다른지 모르겠다고 하는 글이 있었다. 그럼 이 두 개의 차이는 뭘까? 이름도 비슷한데. html하고 http는 다른 건가? 나도 예전에는 헛갈렸었다. 그럼 이들에 대해서 내가 아는 범위 내에서 간단히 설명을 하겠다.

HTML이란

   우리가 보는 웹 페이지의 대부분은 확장자가 html이다. htm인 것도 있는데, 그것은 예전 도스 기준으로 확장자가 3자밖에 되지 않기 때문에 어쩔 수 없이 끝을 자른 것으로 요즘은 잘 없다. 기타 php, aspx, jsp 등도 있다. 이들은 각각 웹 서버의 처리 엔진에 따른 결과물인데, 사실 확장자는 중요한 게 아니다. 어차피 확장자가 php,aspx,jsp인 것도 다들 html이다. 웹 브라우저는 확장자를 보고 이게 html인 줄 아는 게 아니라, 헤더에 있는 타입을 보고 아는 것이다. 우리가 보기에 확장자가 php라도, 헤더에는 txt/html로 타입이 규정되어 있고, 웹 브라우저는 그래서 이게 html인 줄 안다. 웹 페이지는 메모장으로 소스 보기를 하면 보이듯이 <tag>이런 태그로 둘러싸인 텍스트 문서이다. 그림 파일이나 다른 요소는 따로 표시되어 있지 페이지 속에 들어가지 않는다.

HTTP란

  Http는 이런 HTML 같은 문서를 웹 브라우저가 웹 서버에 요청하는 프로토콜이다. 프로토콜이라는 것은 일종의 대화 규칙이다. 우리가 폰뱅킹할 때를 보면 지정된 코드를 누르면 정해진 응답이 온다. 그런 것이다. 이게 없다면 웹 서버는 웹 브라우저가 무슨 페이지를 달라고 하는 건지도 모를 것이고 웹 브라우저도 웹 서버가 무슨 페이지를 보내는 건지 알 수가 없다. Http도 그냥 텍스트 교환일 뿐이다. 복잡한 바이너리 데이터가 아니라 그냥 텍스트 메시지를 주고 받는다. 물론 그 텍스트 메시지 안에 HTML 페이지도 들어 있다. 텍스트이기 때문에 만약 내가 있는 네트워크 안에서 누가 그 신호를 가로채어 본다면 내용이 그대로 보이게 된다. 만약 내가 메일을 읽고 있는데 누가 그 신호를 가로챈다면 메일 내용을 읽을 수 있을 것이다.

HTTPS란

  Https는 http하고 거의 같지만 모든 통신 내용을 암호화하는 것이 다르다. 사실 s가 secure socket, 즉 안전한 통신망을 뜻한다. 우리는 파일에 암호를 많이 걸어 봤다. 어떤 키를 설정해서 걸면 나중에 풀 때에도 그걸 입력해 푸는 것이다. 키라는 것은 암호화를 푸는 암호 즉 패스워드같은 것이다. 웹 서버가 키 하나를 정해서 페이지를 암호화해서 사용자의 웹 브라우저로 보내고 웹 브라우저는 그 키를 이용해서 페이지를 복원한다… 이러면 좋겠지만 이렇게 간단하지 않다. 웹 서버는 하나이지만 사용자는 불특정 다수이다. 그런데 키를 사용자들에게 줘 버리면 아무나 암호화를 풀 수 있게 된다. 영희에게 갈 페이지를 철수도 풀어서 볼 수 있게 되는데, 이러면 암호화의 효과가 없다.

 즉, 페이지 암호화 키가 그 페이지를 보는 특정 사용자에게만 알려져야 한다. 어떻게 이렇게 할 수 있을까? 이것이 바로 https 프로토콜이 하는 것이다. 위에서 말한 암호화 방식을 사용하되, 그 키를 다시 공개 키로 암호화하고 인증하는 것이다. 공개 키는 쉽게 말해서 데이터를 암호화하는데 키가 두 개 필요하다는 것이다. 암호화를 푸는 데에는 그 두 개 중 하나의 키만 있으면 된다. (수학적으로 로그 지수를 찾는 것이 어려운 문제에 기초하고 있다. 이렇게 자세한 것까지 알고 싶은 사람은 없겠지만.) 이게 무슨 뜻일까? 옥션 사이트에서는 A,B라는 키를 가지고 있다. 그리고 이 B라는 키만 사용자들에게 알려 준다. 그리고 옥션 사이트에 웹 브라우저가 연결을 시도할 때, 파일 암호화 키를 이 A,B 키로 암호화해서 보내 준다. 그러면 사용자들은 B라는 키로 데이터를 풀어 볼 수 있다. A는 옥션 관리자 말고는 아무도 모르기 때문에, B만 알아서는 옥션과 똑같이 암호화를 할 수 없다. 즉 사용자는 B로 풀어 봐서 풀어지면 이 데이터는 A키를 아는 옥션 관리자가 암호화한 것이라는 걸 알 수 있는 것이다. http 프로토콜의 경우 중간에서 네트워크 데이터를 가로채어서 마치 자기가 옥션 사이트인 것처럼 해서 가짜 페이지를 보낼 수도 있다. 하지만 https의 경우에는 A키를 모르기 때문에 중간에서 누가 그렇게 할 수가 없다. 이렇게 해서 반대편이 옥션이라는 것을 우리는 믿을 수 있다.

   이렇게 믿을 수 있으면 IE같은 브라우저에서는 주소 창의 색을 다르게 해서 안전하다고 알려 준다. 이렇게 해서 웹 서버와 사용자가 교환한 키로 전체 이후로는 HTML을 암호화해서 교환하는 것이다. 이렇게 되면 중간에서 웹 페이지를 누가 가로채어도 내용을 전혀 읽을 수 없다. 사실 시간이 주어진다면 암호화를 풀 수도 있다. 예를 들어 1024비트 암호화를 사용한다면 암호 키가 1024비트, 즉 2의 1024승이라는 것이다. 암호를 계산해서 푸는 방법은 없다 (있다면 그런 암호화는 폐기된다). 키를 모르고 암호화를 푼다는 것은 모든 키를 하나씩 다 대입해서 풀릴 때까지 해 보는 것이다. 그러면 위의 경우 평균적으로 2의 512승 번을 해 봐야 한다. 2의 512승과 2 x 512는 차원이 다르다. 2의 20승만 해도 백 만이 넘는다. 아무리 빠른 컴퓨터로 대입해도 아마 몇 천 년은 해야 할 것이다. 그래서 안전한 것이다.

결론

  그러면 https가 안전한데 다 https를 쓰지 http를 뭐하러 쓰느냐고 할 것이다. https 암호화를 하려면 웹 서버에 부하가 생기고, 위에서 말한 B가 그 서버의 인증서가 되는데, 이것은 Verisign 같은 업체에서 비싼 돈을 주고 사야하므로, 특히 우리 나라 웹 사이트들은 잘 쓰지 않는다. 하지만 외국 금융 사이트에서는 https는 필수이다. 또 http는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있지만 https의 경우에는 소켓 (데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 https 인증을 해야 한다. 그래서 시간이 또 걸린다.

   그래서 아무나 봐도 상관 없는 페이지는 http로, 남에게 보이면 안 되는 금융 정보나 메일 등 중요한 것은 https로 하는 것이다. GMail은 https를 지원한다. 다른 메일을 사용하는 사람은 보안 문제를 좀 더 생각해 보자.

http://misako.co.kr/articles/HttpVSHttps.aspx

에서 참조

 

HTTP 대 HTTPS : 뭐가 다른가?

신정훈

  웹 브라우저의 주소창을 자세히 보면 http://나 https://로 시작한다. 사실 http://는 하도 흔해서 생략하고 주소를 쳐도, 웹 브라우저가 알아서 http://를 넣어 준다. 어제 인터넷에서 GMail 옵션 중에 항상 https를 사용하도록 하는 옵션이 있다고 그걸 쓰라는 글을 보았다. 거기 달린 답글 중에 두 개가 뭐가 다른지 모르겠다고 하는 글이 있었다. 그럼 이 두 개의 차이는 뭘까? 이름도 비슷한데. html하고 http는 다른 건가? 나도 예전에는 헛갈렸었다. 그럼 이들에 대해서 내가 아는 범위 내에서 간단히 설명을 하겠다.

HTML이란

   우리가 보는 웹 페이지의 대부분은 확장자가 html이다. htm인 것도 있는데, 그것은 예전 도스 기준으로 확장자가 3자밖에 되지 않기 때문에 어쩔 수 없이 끝을 자른 것으로 요즘은 잘 없다. 기타 php, aspx, jsp 등도 있다. 이들은 각각 웹 서버의 처리 엔진에 따른 결과물인데, 사실 확장자는 중요한 게 아니다. 어차피 확장자가 php,aspx,jsp인 것도 다들 html이다. 웹 브라우저는 확장자를 보고 이게 html인 줄 아는 게 아니라, 헤더에 있는 타입을 보고 아는 것이다. 우리가 보기에 확장자가 php라도, 헤더에는 txt/html로 타입이 규정되어 있고, 웹 브라우저는 그래서 이게 html인 줄 안다. 웹 페이지는 메모장으로 소스 보기를 하면 보이듯이 <tag>이런 태그로 둘러싸인 텍스트 문서이다. 그림 파일이나 다른 요소는 따로 표시되어 있지 페이지 속에 들어가지 않는다.

HTTP란

  Http는 이런 HTML 같은 문서를 웹 브라우저가 웹 서버에 요청하는 프로토콜이다. 프로토콜이라는 것은 일종의 대화 규칙이다. 우리가 폰뱅킹할 때를 보면 지정된 코드를 누르면 정해진 응답이 온다. 그런 것이다. 이게 없다면 웹 서버는 웹 브라우저가 무슨 페이지를 달라고 하는 건지도 모를 것이고 웹 브라우저도 웹 서버가 무슨 페이지를 보내는 건지 알 수가 없다. Http도 그냥 텍스트 교환일 뿐이다. 복잡한 바이너리 데이터가 아니라 그냥 텍스트 메시지를 주고 받는다. 물론 그 텍스트 메시지 안에 HTML 페이지도 들어 있다. 텍스트이기 때문에 만약 내가 있는 네트워크 안에서 누가 그 신호를 가로채어 본다면 내용이 그대로 보이게 된다. 만약 내가 메일을 읽고 있는데 누가 그 신호를 가로챈다면 메일 내용을 읽을 수 있을 것이다.

HTTPS란

  Https는 http하고 거의 같지만 모든 통신 내용을 암호화하는 것이 다르다. 사실 s가 secure socket, 즉 안전한 통신망을 뜻한다. 우리는 파일에 암호를 많이 걸어 봤다. 어떤 키를 설정해서 걸면 나중에 풀 때에도 그걸 입력해 푸는 것이다. 키라는 것은 암호화를 푸는 암호 즉 패스워드같은 것이다. 웹 서버가 키 하나를 정해서 페이지를 암호화해서 사용자의 웹 브라우저로 보내고 웹 브라우저는 그 키를 이용해서 페이지를 복원한다… 이러면 좋겠지만 이렇게 간단하지 않다. 웹 서버는 하나이지만 사용자는 불특정 다수이다. 그런데 키를 사용자들에게 줘 버리면 아무나 암호화를 풀 수 있게 된다. 영희에게 갈 페이지를 철수도 풀어서 볼 수 있게 되는데, 이러면 암호화의 효과가 없다.

 즉, 페이지 암호화 키가 그 페이지를 보는 특정 사용자에게만 알려져야 한다. 어떻게 이렇게 할 수 있을까? 이것이 바로 https 프로토콜이 하는 것이다. 위에서 말한 암호화 방식을 사용하되, 그 키를 다시 공개 키로 암호화하고 인증하는 것이다. 공개 키는 쉽게 말해서 데이터를 암호화하는데 키가 두 개 필요하다는 것이다. 암호화를 푸는 데에는 그 두 개 중 하나의 키만 있으면 된다. (수학적으로 로그 지수를 찾는 것이 어려운 문제에 기초하고 있다. 이렇게 자세한 것까지 알고 싶은 사람은 없겠지만.) 이게 무슨 뜻일까? 옥션 사이트에서는 A,B라는 키를 가지고 있다. 그리고 이 B라는 키만 사용자들에게 알려 준다. 그리고 옥션 사이트에 웹 브라우저가 연결을 시도할 때, 파일 암호화 키를 이 A,B 키로 암호화해서 보내 준다. 그러면 사용자들은 B라는 키로 데이터를 풀어 볼 수 있다. A는 옥션 관리자 말고는 아무도 모르기 때문에, B만 알아서는 옥션과 똑같이 암호화를 할 수 없다. 즉 사용자는 B로 풀어 봐서 풀어지면 이 데이터는 A키를 아는 옥션 관리자가 암호화한 것이라는 걸 알 수 있는 것이다. http 프로토콜의 경우 중간에서 네트워크 데이터를 가로채어서 마치 자기가 옥션 사이트인 것처럼 해서 가짜 페이지를 보낼 수도 있다. 하지만 https의 경우에는 A키를 모르기 때문에 중간에서 누가 그렇게 할 수가 없다. 이렇게 해서 반대편이 옥션이라는 것을 우리는 믿을 수 있다.

   이렇게 믿을 수 있으면 IE같은 브라우저에서는 주소 창의 색을 다르게 해서 안전하다고 알려 준다. 이렇게 해서 웹 서버와 사용자가 교환한 키로 전체 이후로는 HTML을 암호화해서 교환하는 것이다. 이렇게 되면 중간에서 웹 페이지를 누가 가로채어도 내용을 전혀 읽을 수 없다. 사실 시간이 주어진다면 암호화를 풀 수도 있다. 예를 들어 1024비트 암호화를 사용한다면 암호 키가 1024비트, 즉 2의 1024승이라는 것이다. 암호를 계산해서 푸는 방법은 없다 (있다면 그런 암호화는 폐기된다). 키를 모르고 암호화를 푼다는 것은 모든 키를 하나씩 다 대입해서 풀릴 때까지 해 보는 것이다. 그러면 위의 경우 평균적으로 2의 512승 번을 해 봐야 한다. 2의 512승과 2 x 512는 차원이 다르다. 2의 20승만 해도 백 만이 넘는다. 아무리 빠른 컴퓨터로 대입해도 아마 몇 천 년은 해야 할 것이다. 그래서 안전한 것이다.

결론

  그러면 https가 안전한데 다 https를 쓰지 http를 뭐하러 쓰느냐고 할 것이다. https 암호화를 하려면 웹 서버에 부하가 생기고, 위에서 말한 B가 그 서버의 인증서가 되는데, 이것은 Verisign 같은 업체에서 비싼 돈을 주고 사야하므로, 특히 우리 나라 웹 사이트들은 잘 쓰지 않는다. 하지만 외국 금융 사이트에서는 https는 필수이다. 또 http는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있지만 https의 경우에는 소켓 (데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 https 인증을 해야 한다. 그래서 시간이 또 걸린다.

   그래서 아무나 봐도 상관 없는 페이지는 http로, 남에게 보이면 안 되는 금융 정보나 메일 등 중요한 것은 https로 하는 것이다. GMail은 https를 지원한다. 다른 메일을 사용하는 사람은 보안 문제를 좀 더 생각해 보자.

http://msdn.microsoft.com/en-us/library/ms531424(v=vs.85).aspx

에서 참조

userData Behavior

30 out of 50 rated this helpful Rate this topic

Enables the object to persist data in user data.

Syntax

XML<Prefix: CustomTag ID=sID STYLE="behavior:url('#default#userData')" /> HTML <ELEMENT STYLE="behavior:url('#default#userData')" ID=sID> Scripting object .style.behavior = "url('#default#userData')" object .addBehavior ("#default#userData")

Possible Values

Prefix Prefix that associates the CustomTag with an XML namespace. This prefix is set using the XMLNS attribute of the HTML tag. CustomTag User-defined tag. sIDString that specifies a unique identifier for the object.

Members Table

The following table lists the members exposed by the userData object.

Attributes/Properties
PropertyDescriptionexpires Sets or retrieves the expiration date of data persisted with the userData behavior. XMLDocumentRetrieves a reference to the XML
Methods
MethodDescriptiongetAttribute Retrieves the value of the specified attribute. load Loads an object participating in userData persistence from a UserData store. removeAttribute Removes the specified attribute from the object. save Saves an object participating in userData persistence to a UserData store. setAttributeSets the value of the specified attribute.

Remarks

security note Security Alert  For security reasons, a UserData store is available only in the same directory and with the same protocol used to persist the store.
security note Security Alert  Using this behavior incorrectly can compromise the security of your application. Data in a UserData store is not encrypted and therefore not secure. Any application that has access to the drive where UserData is saved has access to the data. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

The userData behavior persists information across sessions by writing to a UserData store. This provides a data structure that is more dynamic and has a greater capacity than cookies. The capacity of the UserData store depends on the security zone of the domain. The following table shows the maximum amount of UserData storage that is available for an individual document and also the total available for an entire domain, based on the security zone.

Security ZoneDocument Limit (KB)Domain Limit (KB)Local Machine1281024Intranet51210240Trusted Sites1281024Internet1281024Restricted64640

See URLACTION_HTML_USERDATA_SAVE for information on how the userData behavior is regulated. See About URL Security Zones Templates for further information on the default URL policy settings for each of the five security zone templates.

The userData behavior persists data across sessions, using one UserData store for each object. The UserData store is persisted in the cache using the save and load methods. Once the UserData store has been saved, it can be reloaded even if Windows Internet Explorer has been closed and reopened.

Setting the userData behavior class on the html, head, title, or style object causes an error when the save or load method is called.

The required style can be set inline or in the document header, as follows:

Copy
   <STYLE>

      .storeuserData {behavior:url(#default#userData);}

   </STYLE>

An ID is optional for userData, but including one improves performance.

The userData behavior is available as of Microsoft Internet Explorer 5, in the Microsoft Win32 and Unix platforms.

Examples

This example uses the userData behavior to preserve information in a UserData Store.

Copy
<html>



<head>

<style type="text/css">

.storeuserData {

    behavior: url(#default#userData);

}

</style>



function fnSaveInput(){

   var oPersist=oPersistForm.oPersistInput;

   oPersist.setAttribute("sPersist",oPersist.value);

   oPersist.save("oXMLBranch");

}

function fnLoadInput(){

   var oPersist=oPersistForm.oPersistInput;

   oPersist.load("oXMLBranch");

   oPersist.value=oPersist.getAttribute("sPersist");

}



</head>



<body>



<form id="oPersistForm">

    <input class="storeuserData" type="text" id="oPersistInput">

    <input type="button" value="Load" onclick="fnLoadInput()">

    <input type="button" value="Save" onclick="fnSaveInput()">

</form>



</body>



</html>

Code example: http://samples.msdn.microsoft.com/workshop/samples/author/persistence/userData_1.htm

The following example uses the userData behavior in a custom tag to preserve information in a UserData Store.

Copy
<html xmlns:sdk="">



<head>

<style type="text/css">

sdk:cacher {

    behavior: url(#default#userData);

}

</style>



function fnSaveInput(){

   cachetag.setAttribute("sPersist",txt1.value);

   cachetag.save("cache");

}

function fnLoadInput(){

   cachetag.load("cache");

   cachetag.value=cachetag.getAttribute("sPersist");

}



</head>



<body>



<sdk:cacher id="cachetag"></sdk:cacher>

<input type="button" value="Load" onclick="fnLoadInput()">

<input type="button" value="Save" onclick="fnSaveInput()">

<input type="text" id="txt1" value="some value">



</body>



</html>

http://msdn.microsoft.com/en-us/library/ms531424(v=vs.85).aspx

에서 참조

userData Behavior

30 out of 50 rated this helpful Rate this topic

Enables the object to persist data in user data.

Syntax

XML<Prefix: CustomTag ID=sID STYLE="behavior:url('#default#userData')" /> HTML <ELEMENT STYLE="behavior:url('#default#userData')" ID=sID> Scripting object .style.behavior = "url('#default#userData')" object .addBehavior ("#default#userData")

Possible Values

Prefix Prefix that associates the CustomTag with an XML namespace. This prefix is set using the XMLNS attribute of the HTML tag. CustomTag User-defined tag. sIDString that specifies a unique identifier for the object.

Members Table

The following table lists the members exposed by the userData object.

Attributes/Properties
PropertyDescriptionexpires Sets or retrieves the expiration date of data persisted with the userData behavior. XMLDocumentRetrieves a reference to the XML
Methods
MethodDescriptiongetAttribute Retrieves the value of the specified attribute. load Loads an object participating in userData persistence from a UserData store. removeAttribute Removes the specified attribute from the object. save Saves an object participating in userData persistence to a UserData store. setAttributeSets the value of the specified attribute.

Remarks

security note Security Alert  For security reasons, a UserData store is available only in the same directory and with the same protocol used to persist the store.
security note Security Alert  Using this behavior incorrectly can compromise the security of your application. Data in a UserData store is not encrypted and therefore not secure. Any application that has access to the drive where UserData is saved has access to the data. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

The userData behavior persists information across sessions by writing to a UserData store. This provides a data structure that is more dynamic and has a greater capacity than cookies. The capacity of the UserData store depends on the security zone of the domain. The following table shows the maximum amount of UserData storage that is available for an individual document and also the total available for an entire domain, based on the security zone.

Security ZoneDocument Limit (KB)Domain Limit (KB)Local Machine1281024Intranet51210240Trusted Sites1281024Internet1281024Restricted64640

See URLACTION_HTML_USERDATA_SAVE for information on how the userData behavior is regulated. See About URL Security Zones Templates for further information on the default URL policy settings for each of the five security zone templates.

The userData behavior persists data across sessions, using one UserData store for each object. The UserData store is persisted in the cache using the save and load methods. Once the UserData store has been saved, it can be reloaded even if Windows Internet Explorer has been closed and reopened.

Setting the userData behavior class on the html, head, title, or style object causes an error when the save or load method is called.

The required style can be set inline or in the document header, as follows:

Copy
   <STYLE>

      .storeuserData {behavior:url(#default#userData);}

   </STYLE>

An ID is optional for userData, but including one improves performance.

The userData behavior is available as of Microsoft Internet Explorer 5, in the Microsoft Win32 and Unix platforms.

Examples

This example uses the userData behavior to preserve information in a UserData Store.

Copy
<html>



<head>

<style type="text/css">

.storeuserData {

    behavior: url(#default#userData);

}

</style>



function fnSaveInput(){

   var oPersist=oPersistForm.oPersistInput;

   oPersist.setAttribute("sPersist",oPersist.value);

   oPersist.save("oXMLBranch");

}

function fnLoadInput(){

   var oPersist=oPersistForm.oPersistInput;

   oPersist.load("oXMLBranch");

   oPersist.value=oPersist.getAttribute("sPersist");

}



</head>



<body>



<form id="oPersistForm">

    <input class="storeuserData" type="text" id="oPersistInput">

    <input type="button" value="Load" onclick="fnLoadInput()">

    <input type="button" value="Save" onclick="fnSaveInput()">

</form>



</body>



</html>

Code example: http://samples.msdn.microsoft.com/workshop/samples/author/persistence/userData_1.htm

The following example uses the userData behavior in a custom tag to preserve information in a UserData Store.

Copy
<html xmlns:sdk="">



<head>

<style type="text/css">

sdk:cacher {

    behavior: url(#default#userData);

}

</style>



function fnSaveInput(){

   cachetag.setAttribute("sPersist",txt1.value);

   cachetag.save("cache");

}

function fnLoadInput(){

   cachetag.load("cache");

   cachetag.value=cachetag.getAttribute("sPersist");

}



</head>



<body>



<sdk:cacher id="cachetag"></sdk:cacher>

<input type="button" value="Load" onclick="fnLoadInput()">

<input type="button" value="Save" onclick="fnSaveInput()">

<input type="text" id="txt1" value="some value">



</body>



</html>

Introduction to Persistence

13 out of 27 rated this helpful Rate this topic

Note  As of December 2011, this topic has been archived and is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Windows Internet Explorer, see Internet Explorer Developer Center.

Persistence enables authors to specify an object to persist on the client during the current and later sessions using Dynamic HTML (DHTML) behaviors. Persistence allows Microsoft Internet Explorer 5 and later to retain Web page information, styles, variables, and state. For example, a collapsible list of links within a table of contents can remain expanded to the user’s choice upon leaving and later returning to the page. Or, a search engine query form can retain the last-used search string.

Persistence is implemented as a behavior. The new persistence behaviors include:

  • saveFavorite—persists page state and information when the web page is saved as a favorite.
  • saveHistory—persists page state and information within the current session’s memory.
  • saveSnapshot—persists page state and information directly in the page when users save the Web page to their hard disk.
  • userData—persists page state and information within an XML store, a hierarchical data structure.

Persistence creates new opportunities for the author. Information that persists beyond a single page without support from the server, or within the finite scope of cookies, can increase the speed of navigation and content authoring.

These behaviors can be used to preserve information in the browser’s history, in favorites, in an XML store, or directly within a Web page saved to disk. When a user returns to a persisted page, the state of the page can be restored. By allowing information to safely reside on the client, fewer server transactions are required. Custom start pages and Web applications prosper because information can continue to exist without the paternal support of the server, or repeated server queries. A Web page can remain interactive to a degree, after the connection with the host has been severed, by persisting required information on the client.

Benefits

Use of persistence in Internet Explorer 5 breaks away from the tradition of using cookies and session files to store information. The Microsoft model for client/server relationships using persistence and Internet Explorer 5 is pragmatic; it maintains the same-domain security policy associated with cookies while increasing storage and management capabilities.

Server solutions Persistence solutions Start pages Custom start pages often rely on cookies and server-side databases to preserve client-specific information. Storing information such as client capabilities, favorite styles, and favorite content requires additional queries to the server to retrieve the information. This results in increased download time for the client and increased processing demands on the server.Persistence via Dynamic HTML (DHTML) behaviors allows a page author to store information on the client. This reduces the need to query a server database for client-specific information and increases the overall performance of the page. Persistence stores the data hierarchically, making it more accessible.Web appsWeb-based applications have remained tied to the server for the back-end strength and processing power they require. A Web site that includes a basic form to be sent in e-mail uses a server to handle the request, or a script to process any e-mail beyond a conventional note.A persistent Web page can be saved with its form values intact, making it easier to transfer or preserve an entire document. Persistence introduces a new paradigm for Web applications by giving authors the ability to produce complex Web-based applications that take advantage of the client’s processing power.FormsAdvanced search engines and information entry and retrieval forms often rely on session variables and files to preserve information across Web pages. The server must send and store the same information with each new visit to the Web page, taxing the Web server and the Internet line.While there is some information that should remain on the server, the rest can be stored on the client. Client-side scripting within each Web page can perform the necessary validation routines, leaving the server to higher-level security concerns. Since persisted information maintains a similar same-domain security structure as cookies, the client can be assured that rogue Web sites will not glean such information from their computers.

Using Persistence

Persistence behaviors require certain conditions before they can be used. A meta tag directs the browser that the page is persistent. Persistent elements are identified with a CLASS and an ID property. The onsave and onload event handlers can be defined for nondefault handling.

Behavior Description saveFavoritePersists an object across sessions when the page has been saved as a favorite.

The getAttribute and setAttribute methods are used to store information on a persistent object. The onload and onsave event handlers can be used to call the methods.

The saveFavorite behavior is ideal for persisting user-selected styles within a favorite or shortcut. The persisted information is stored within each favorite, allowing multiple favorites with different persisted information to exist.

saveHistoryPersists an object during the current session.

The getAttribute and setAttribute methods can be used to store information on objects participating in persistence. The onload and onsave event handlers can be used to call the methods.

The saveHistory behavior is ideal for storing information only while the browser is open, such as page state for collapsible content, or dynamic styles.

saveSnapshotPersists an object across sessions when a page has been saved as Web Page, HTML Only.

Form elements persist automatically. Script blocks designated to persist can contain only variables. Script objects and comments are removed. Qualifying variables from external sources on persisting script blocks are inserted.

The saveSnapshot behavior is ideal for persisting Web application information to the client’s disk for later retrieval.

userDataPersists an object across sessions in a UserData store (an arbitrary storage facility) when the object has been explicitly saved.

Form elements, styles, and dynamic values can be persisted using the getAttribute and setAttribute methods, and then explicitly saved using the load and save methods.

The userData behavior is ideal for persisting information across sessions and storing information in a hierarchical structure. It provides a good alternative to using cookies. The capacity of the userData store is 64 KB per page, with a limit of 640 KB per domain, for restricted sites. For security reasons, a userData store is available only in the same directory and with the same protocol used to persist the store.

Security Warning:  Using these behavior incorrectly can compromise the security of your application. The saveFavorite, saveSnapshot, and userData behaviors persist data as plain text in a saved Web page. Text is not encrypted and therefore not secure. Any application that has access to the drive where the page is saved also has access to the data and can tamper with it. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

An ID is not required for the saveFavorite and saveHistory behaviors, but is recommended for performance. The style element also can be set inline on a persistent object.

Example Uses of Persistence

The following examples show how to use behaviors to implement persistence.

The following examples shows the saveFavorite behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="favorite">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveFavorite {behavior:url(#default#savefavorite);}
</STYLE>

// Record information to the persistent object as an attribute.
function fnSave(){
   oPersistInput.setAttribute("sPersistAttr",oPersistInput.value);
}
// Retrieve information from a persistent object.
function fnLoad(){
   oPersistInput.value=oPersistInput.getAttribute("sPersistAttr");
}

:
<!-- The CLASS enables the object to persist, the event handlers 
     fire the scripted functions.-->
<INPUT
   TYPE="text"
   CLASS="saveFavorite"
   ID="oPersistInput"
   onload="fnLoad()"
   onsave="fnSave()"
>

Click to view sample.

The following example shows the saveHistory behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="history">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveHistory {behavior:url(#default#savehistory);}
</STYLE>
:
<!-- The default behavior is to persist form elements.
   When the saveHistory behavior is defined, form elements
   will not persist unless they have a class.
-->
This persists:
<INPUT TYPE="text" CLASS="saveHistory" ID="oPersistInput">
This does not persist:
<INPUT TYPE="text">

Click to view sample.

The following example shows the saveSnapshot behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="snapshot">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveSnapshot {behavior:url(#default#savesnapshot);}
</STYLE>
:
<!-- When the page is saved, the information entered in the
     persistent form element will be inserted as the value
     within the HTML file.-->
<INPUT TYPE=text CLASS=saveSnapshot ID=oPersistInput>
:

Click to view sample.

The following example shows the userData behavior.

<!-- Define the class for the persistent object-->
<STYLE>
    .userData {behavior:url(#default#userdata);}
</STYLE>

    function fnSaveInput(){
   
// Persistent information is stored as an attribute
// on the persistent object, and saved within a
// UserData store.
      var oPersist=oPersistForm.oPersistInput;
      oPersist.setAttribute("sPersist",oPersist.value);
      oPersist.save("oXMLBranch");
	  
   }
    function fnLoadInput(){

// Persistent information is loaded from a UserData store
// and the value is restored from the persisted attribute.

      var oPersist=oPersistForm.oPersistInput;
      oPersist.load("oXMLBranch");
      oPersistInput.value=oPersistInput.getAttribute("sPersist");
   }

:
<FORM ID="oPersistForm">
<INPUT class=userData type=text id=oPersistInput>
<INPUT type=button value="Load" onclick="fnLoadInput()">
<INPUT type=button value="Save" onclick="fnSaveInput()">
</FORM>

Click to view sample.

Persisting Content in XML

The XMLDocument property allows the saveFavorite, saveHistory, and userData behaviors to access the XML Document Object Model (DOM). Using the XML DOM, persistent objects have access to the objects, properties, and methods that allow the author to build hierarchical data structures.

var oXMLDocument=oPersistText.XMLDocument;
var oNode=oXMLDocument.createNode("element","MyElement", "");
oNode.nodeValue="The value of MyElement";
oXMLDocument.documentNode.insertNode("MyElement");

In XML, this would yield:

<MyElement>The value of MyElement</MyElement>

Persistence How-Tos

Persistence introduces a broad expanse of possibilities. The following how-to articles cover some of the more interesting, albeit easy-to-employ, uses of persistence.

Related topics

Dynamic HTML (DHTML) Articles Introduction to DHTML Behaviors Client Capabilities Default Behaviors Reference

Send comments about this topic to Microsoft

Build date: 10/26/2012

Introduction to Persistence

13 out of 27 rated this helpful Rate this topic

Note  As of December 2011, this topic has been archived and is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Windows Internet Explorer, see Internet Explorer Developer Center.

Persistence enables authors to specify an object to persist on the client during the current and later sessions using Dynamic HTML (DHTML) behaviors. Persistence allows Microsoft Internet Explorer 5 and later to retain Web page information, styles, variables, and state. For example, a collapsible list of links within a table of contents can remain expanded to the user’s choice upon leaving and later returning to the page. Or, a search engine query form can retain the last-used search string.

Persistence is implemented as a behavior. The new persistence behaviors include:

  • saveFavorite—persists page state and information when the web page is saved as a favorite.
  • saveHistory—persists page state and information within the current session’s memory.
  • saveSnapshot—persists page state and information directly in the page when users save the Web page to their hard disk.
  • userData—persists page state and information within an XML store, a hierarchical data structure.

Persistence creates new opportunities for the author. Information that persists beyond a single page without support from the server, or within the finite scope of cookies, can increase the speed of navigation and content authoring.

These behaviors can be used to preserve information in the browser’s history, in favorites, in an XML store, or directly within a Web page saved to disk. When a user returns to a persisted page, the state of the page can be restored. By allowing information to safely reside on the client, fewer server transactions are required. Custom start pages and Web applications prosper because information can continue to exist without the paternal support of the server, or repeated server queries. A Web page can remain interactive to a degree, after the connection with the host has been severed, by persisting required information on the client.

Benefits

Use of persistence in Internet Explorer 5 breaks away from the tradition of using cookies and session files to store information. The Microsoft model for client/server relationships using persistence and Internet Explorer 5 is pragmatic; it maintains the same-domain security policy associated with cookies while increasing storage and management capabilities.

Server solutions Persistence solutions Start pages Custom start pages often rely on cookies and server-side databases to preserve client-specific information. Storing information such as client capabilities, favorite styles, and favorite content requires additional queries to the server to retrieve the information. This results in increased download time for the client and increased processing demands on the server.Persistence via Dynamic HTML (DHTML) behaviors allows a page author to store information on the client. This reduces the need to query a server database for client-specific information and increases the overall performance of the page. Persistence stores the data hierarchically, making it more accessible.Web appsWeb-based applications have remained tied to the server for the back-end strength and processing power they require. A Web site that includes a basic form to be sent in e-mail uses a server to handle the request, or a script to process any e-mail beyond a conventional note.A persistent Web page can be saved with its form values intact, making it easier to transfer or preserve an entire document. Persistence introduces a new paradigm for Web applications by giving authors the ability to produce complex Web-based applications that take advantage of the client’s processing power.FormsAdvanced search engines and information entry and retrieval forms often rely on session variables and files to preserve information across Web pages. The server must send and store the same information with each new visit to the Web page, taxing the Web server and the Internet line.While there is some information that should remain on the server, the rest can be stored on the client. Client-side scripting within each Web page can perform the necessary validation routines, leaving the server to higher-level security concerns. Since persisted information maintains a similar same-domain security structure as cookies, the client can be assured that rogue Web sites will not glean such information from their computers.

Using Persistence

Persistence behaviors require certain conditions before they can be used. A meta tag directs the browser that the page is persistent. Persistent elements are identified with a CLASS and an ID property. The onsave and onload event handlers can be defined for nondefault handling.

Behavior Description saveFavoritePersists an object across sessions when the page has been saved as a favorite.

The getAttribute and setAttribute methods are used to store information on a persistent object. The onload and onsave event handlers can be used to call the methods.

The saveFavorite behavior is ideal for persisting user-selected styles within a favorite or shortcut. The persisted information is stored within each favorite, allowing multiple favorites with different persisted information to exist.

saveHistoryPersists an object during the current session.

The getAttribute and setAttribute methods can be used to store information on objects participating in persistence. The onload and onsave event handlers can be used to call the methods.

The saveHistory behavior is ideal for storing information only while the browser is open, such as page state for collapsible content, or dynamic styles.

saveSnapshotPersists an object across sessions when a page has been saved as Web Page, HTML Only.

Form elements persist automatically. Script blocks designated to persist can contain only variables. Script objects and comments are removed. Qualifying variables from external sources on persisting script blocks are inserted.

The saveSnapshot behavior is ideal for persisting Web application information to the client’s disk for later retrieval.

userDataPersists an object across sessions in a UserData store (an arbitrary storage facility) when the object has been explicitly saved.

Form elements, styles, and dynamic values can be persisted using the getAttribute and setAttribute methods, and then explicitly saved using the load and save methods.

The userData behavior is ideal for persisting information across sessions and storing information in a hierarchical structure. It provides a good alternative to using cookies. The capacity of the userData store is 64 KB per page, with a limit of 640 KB per domain, for restricted sites. For security reasons, a userData store is available only in the same directory and with the same protocol used to persist the store.

Security Warning:  Using these behavior incorrectly can compromise the security of your application. The saveFavorite, saveSnapshot, and userData behaviors persist data as plain text in a saved Web page. Text is not encrypted and therefore not secure. Any application that has access to the drive where the page is saved also has access to the data and can tamper with it. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

An ID is not required for the saveFavorite and saveHistory behaviors, but is recommended for performance. The style element also can be set inline on a persistent object.

Example Uses of Persistence

The following examples show how to use behaviors to implement persistence.

The following examples shows the saveFavorite behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="favorite">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveFavorite {behavior:url(#default#savefavorite);}
</STYLE>

// Record information to the persistent object as an attribute.
function fnSave(){
   oPersistInput.setAttribute("sPersistAttr",oPersistInput.value);
}
// Retrieve information from a persistent object.
function fnLoad(){
   oPersistInput.value=oPersistInput.getAttribute("sPersistAttr");
}

:
<!-- The CLASS enables the object to persist, the event handlers 
     fire the scripted functions.-->
<INPUT
   TYPE="text"
   CLASS="saveFavorite"
   ID="oPersistInput"
   onload="fnLoad()"
   onsave="fnSave()"
>

Click to view sample.

The following example shows the saveHistory behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="history">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveHistory {behavior:url(#default#savehistory);}
</STYLE>
:
<!-- The default behavior is to persist form elements.
   When the saveHistory behavior is defined, form elements
   will not persist unless they have a class.
-->
This persists:
<INPUT TYPE="text" CLASS="saveHistory" ID="oPersistInput">
This does not persist:
<INPUT TYPE="text">

Click to view sample.

The following example shows the saveSnapshot behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="snapshot">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveSnapshot {behavior:url(#default#savesnapshot);}
</STYLE>
:
<!-- When the page is saved, the information entered in the
     persistent form element will be inserted as the value
     within the HTML file.-->
<INPUT TYPE=text CLASS=saveSnapshot ID=oPersistInput>
:

Click to view sample.

The following example shows the userData behavior.

<!-- Define the class for the persistent object-->
<STYLE>
    .userData {behavior:url(#default#userdata);}
</STYLE>

    function fnSaveInput(){
   
// Persistent information is stored as an attribute
// on the persistent object, and saved within a
// UserData store.
      var oPersist=oPersistForm.oPersistInput;
      oPersist.setAttribute("sPersist",oPersist.value);
      oPersist.save("oXMLBranch");
	  
   }
    function fnLoadInput(){

// Persistent information is loaded from a UserData store
// and the value is restored from the persisted attribute.

      var oPersist=oPersistForm.oPersistInput;
      oPersist.load("oXMLBranch");
      oPersistInput.value=oPersistInput.getAttribute("sPersist");
   }

:
<FORM ID="oPersistForm">
<INPUT class=userData type=text id=oPersistInput>
<INPUT type=button value="Load" onclick="fnLoadInput()">
<INPUT type=button value="Save" onclick="fnSaveInput()">
</FORM>

Click to view sample.

Persisting Content in XML

The XMLDocument property allows the saveFavorite, saveHistory, and userData behaviors to access the XML Document Object Model (DOM). Using the XML DOM, persistent objects have access to the objects, properties, and methods that allow the author to build hierarchical data structures.

var oXMLDocument=oPersistText.XMLDocument;
var oNode=oXMLDocument.createNode("element","MyElement", "");
oNode.nodeValue="The value of MyElement";
oXMLDocument.documentNode.insertNode("MyElement");

In XML, this would yield:

<MyElement>The value of MyElement</MyElement>

Persistence How-Tos

Persistence introduces a broad expanse of possibilities. The following how-to articles cover some of the more interesting, albeit easy-to-employ, uses of persistence.

Related topics

Dynamic HTML (DHTML) Articles Introduction to DHTML Behaviors Client Capabilities Default Behaviors Reference

Send comments about this topic to Microsoft

Build date: 10/26/2012

http://msdn.microsoft.com/en-us/library/ms531421(v=vs.85).aspx

에서 참조

 

saveFavorite Behavior

1 out of 6 rated this helpful Rate this topic

Enables the object to persist data in a favorite Web site.

Syntax

XML<Prefix: CustomTag ID=sID STYLE="behavior:url('#default#saveFavorite')" /> HTML <ELEMENT STYLE="behavior:url('#default#saveFavorite')" ID=sID> Scripting object .style.behavior = "url('#default#saveFavorite')" object .addBehavior ("#default#saveFavorite")

Possible Values

Prefix Prefix that associates the CustomTag with an XML namespace. This prefix is set using the XMLNS attribute of the HTML tag. CustomTag User-defined tag. sIDString that specifies a unique identifier for the object.

Members Table

The following table lists the members exposed by the saveFavorite object.

Attributes/Properties
PropertyDescriptionXMLDocumentRetrieves a reference to the XML
Events
EventDescriptiononload Fires from a persistent element when the page reloads. onsaveFires from a persisted element when the Web page is saved or bookmarked, or when the user navigates away from the page.
Methods
MethodDescriptiongetAttribute Retrieves the value of the specified attribute. removeAttribute Removes the specified attribute from the object. setAttributeSets the value of the specified attribute.

Remarks

The saveFavorite behavior allows the current state of a page to be saved when the user adds the page to the Favorites menu. When the user returns to the page through a shortcut or the Favorites menu, the state of the page is restored.

The saveFavorite behavior persists data across sessions, using one userData store for each object. If two objects try to use the same attribute, both are persisted in the userData store for each element. The saveFavoriteuserData store is persisted in the Favorites .ini file, which includes the URL of the page as well as the userData store. When the page is loaded through a shortcut or the Favorites menu, the data from the userData store is loaded from the .ini file, even if the user closes and reopens Windows Internet Explorer.

For example, a page with several dynamically updated styles can save these updates using the onload and onsave events. The style values can be saved as attributes when onsave fires, and restored when onload fires.

security note Security Alert  Using this behavior incorrectly can compromise the security of your application. This behavior uses a userData store, which is not encrypted and therefore not secure. Any application that has access to the drive where userData is saved has access to the data. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

To persist the state of a page by adding it to the browser Favorites menu, first define a Cascading Style Sheets (CSS) style that applies the saveFavorite behavior. Then use this style in the tags containing content that needs to be persisted. The required style can be set inline or in the document header, as follows:

Copy
   <STYLE>

      .sFavorite {behavior:url(#default#savefavorite);}

   </STYLE>

An ID is optional for saveFavorite, but including one improves performance.

The saveFavorite behavior is available as of Microsoft Internet Explorer 5, in the Microsoft Win32 and Unix platforms.

Example

This example uses the saveFavorite behavior to persist information after the user saves the page as a favorite.

Copy
<HTML>

<HEAD>

<STYLE>

   .sFavorite {behavior:url(#default#savefavorite);}

</STYLE>



   function fnSaveInput(){

      oPersistInput.setAttribute("sPersistValue",oPersistInput.value);

   }

   function fnLoadInput(){

      oPersistInput.value=oPersistInput.getAttribute("sPersistValue");

   }



</HEAD>

<BODY>

<INPUT class=sFavorite onsave="fnSaveInput()" onload="fnLoadInput()" type=text id=oPersistInput>

</BODY>

</HTML>