• 카테고리
    • 전체 글

    • 카테고리1
    • 카테고리2
    • 카테고리3
    • 카테고리4
  • 태그
  • 방명록

'분류 전체보기'에 해당되는 글 1243건

  • 2008.04.24 Javascript, 객체화 하기.
  • 2008.04.20 정규식 표현용 라이브러리.
  • 2008.04.17 SharePoint 다국어 지원에 대한 오해. 2
  • 2008.04.14 ASP.NET Postback에 대한 분석 (2)
  • 2008.04.10 봄 그리고 피로.
  • 2008.04.07 ASP.NET Postback에 대한 분석 (1) 3
  • 2008.04.07 페이지 보안 오류
  • 2008.03.26 스팸 트랙백 없애기! 6

Javascript, 객체화 하기.

기술자료/Web 2008. 4. 24. 20:13
예전에 Javascript 예제 소스를 받기위해 이곳 저곳을 들리다가, Javascript 안에서

  MOA.Service.Open("aaaaa", "12"."55");

식으로 소스를 적어놓은 것을 보았다.
처음에는 무슨 Object를 New 한뒤, 그 안의 메소드가 그렇게 된 줄 알았는데,
Javascript를 구성할 때, Namespace 기반으로 마치 Class 처럼 구현하는 방법으로
만들어 진 것이였다.
지금도 그렇지만 그 당시 나에게 Javascript는 넘지 못할 산이였고, Copy & Paste만 한채
더 이상 분석 없이 그냥 넘어 갔었다.

이번에 AJAX 기반의 WebPart를 만들면서 Javascript를 하나씩 사용하기 시작했는데,
그 때 보아왔던 Class 처럼 구현한 Javascript 의 원형을 보게 되었고, 그 구조를 뜯어보는
기회를 갖게되었다.


Javascript 에서 저런 "." 으로 구분된 형태로 구성하는 이유중에 하나는,
Namespace 때문이다.
예를 들어 함수나 변수 이름들을 넣을 때,  이름이 겹치지 않을까 하는 우려가 발생했다.
예를 들어 addNode 라는 함수를 만들었는데, 이 함수가 다른 Javascript에서도 사용하지
않을까... 라는 우려감이 그대로 드는 것이였다. 그럼 어떻게 해결 할까?

Javascript에서는 var 라는 변수 형에는 뭐든지 들어갈 수 있다는데 착안을 하여 구성한 것 같다.

즉 var AAA = { 'aaa', 'bbbb'  ,'cccc'  } 라는 배열을 넣듯이 그 안에 구성요소들을 때려
넣는 것이다. 이 때 name과 value라는 형태로 넣는데, 굳이 표현하면 아래와 같이 된다.

var AAA = { name : 'aaaa', tel : 'bbbbb' , addr : 'cccc' }

요소 1개는 name : 'aaaa' 이고, 2번째 요소는 tel : 'bbbbb' , 3번째 요소는 addr : 'cccc' 를 의미하게 된다. 만일 'aaaa' 라는 것을 접근하려면, AAA.name 으로 하면 'aaaa' 이 나오게 되는 것이다.

예를 들면 아래와 같이 클래스를 구성하게 된다.

var HelloClass = {
       variableA : null,
       RunIt: function (param) {
            this.variableA = param;
            alert(HelloClass .variableA);
       }
}

HelloClass.HelloMethod('OK!');

위의 자바 스크립트를 실행하면 'OK!' 라는 Alert 창이 뜬다.

잠시 위의 코드를 살펴보자.
보면, 이름과 그 형이나, 값을 ':' 으로 구분하여 구성한다.
보면 변수 부분은 변수이름을 variableA 로, 그 값은 null 로 규정했다.
그리고 함수 부분은 이름을 RunIt로, 그 값은 function(....) {....} 이라고 규정했다.

이렇게 만들면 저 맨위의 이름(예에서는 HelloClass )만 안겹치면 끝이다.

그리고, HelloClass를 접근할 때, HelloClass 자체를 써서 접근할 수 있고,
HelloClass 내부에서 접근할 땐 this라는 지시어를 써도 된다.

뭐 실제 class 처럼 proecteed, private 등의 접근 제어나 생성자 이런 부분이
명확치 않아서 의미가 별로 없긴 하지만, 네임 스페이스에 겹치지 않는 문제를
해결한다는 입장에서 볼때는 획기적인 방법이 아닐 수 없다.





728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

정규식 표현용 라이브러리.

기술자료/Web 2008. 4. 20. 13:21
정규식 표현(Regular Expressions) 작업은 다양한 텍스트 작업에 필수 이지만, 그 문법을 익히기엔 귀찮고 시간도 부족하고 특이한 형태를 뽑아내려면 많은 고민과 테스트를 해야 한다.
그렇다고 Window App로 만들어서 이런저런 테스트하기도 귀찮고..

그런 부분을 아는지 외국 사이트 중 이작업을 보다 수월하게 도와주는 곳이 있었다.

http://regexlib.com 

다행이 유료는 아니였다. 여러 난다 긴다는 분들이 자신만의 Expression들을 등록해 마치 라이브러리 처럼 유지되고 있었다. 일단 훌륭하게 운영되는 곳 같다.

게다가 이 사이트내에는 이 Expression을 테스트할 수 있는 도구도 제공한다.

http://regexlib.com/RETester.aspx

여기에 자신의 예제 텍스트들과 Expression을 넣고 돌리면 그 결과값을 볼 수 있다!!!
쵝오!
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

SharePoint 다국어 지원에 대한 오해.

기술자료/.NET 2008. 4. 17. 09:51
요즘 한국 MS에서 SharePoint를 하나라도 더 많은 곳에 팔기 위해 많은 시도들을 하고 있다. 그래서 이 SharePoint를 많은 업체들에게 소개하고 영업을 하고 있다. 그 소개와 영업하기 위해 이 SharePoint의 많은 특/장점을 제시하는데,그 중 하나가 다국어 지원이다.

우리나라의 대부분 업체들이 말하고 있는 다국어 사이트라는 개념과 SharePoint와 외국인의 입장에서 보는 다국어 사이트라는 개념에는 상당한 차이가 있다.
특히 인트라넷 시스템을 기준으로 볼 때, 확연하게 틀리다.

우리나라의 대부분의 업체들이 말하는 다국어 시스템이라는 것은, 사이트내에 담긴 내용과는 별개로 각종 메뉴나 외부 틀에 보이는 모든 형태가 언어별로 다르게 표시되는 시스템을 원한다. 즉 게시판을 예를 들면 게시판의 내용은 한국어가 되었던 영어가 되었던, 러시아어가 되었던 외부의 틀만은 언어 중립적으로 표시되어야 한다는 것이다. ( 유니코드가 나오기 전에는 어떻게 되었는지 궁금할 따름이다. )

외국 입장(SharePoint와 외국인들)에서는 사이트의 내용에 따라 틀도 달라진다는 의미로 해석하면 된다. 만일 영어 사이트라면 틀도, 내용도 영어로만 적혀 있어야 한다. 한국어 사이트면 틀도, 내용도 모두 한국어로 나와야 된다는 의미이다. 즉 언어별로 별개의 사이트로 구성되서 진행되는 것이다.

다국어에 대한  이 차이점은 고객과 SharePoint를 적용하는데 있어 큰 걸림돌이 되고도 남는 부분이 된다. 그냥 다국어라고 MS에서는 이야기 하기 때문에, 고객입장에서는 당연히 언어 설정을 하면 그에 맞게 모든 사이트의 형태가 휘리릭 바뀌기리라 생각하고, SharePoint에서는 다른 언어인 경우 별도 사이트를 구축하여 제공하는 것이다.

어느 쪽 생각이 옳은지는 전혀 모르겠지만, 최소한 국내 IT 업계에서 일하는 만큼 전자를 따르는 것이 옳을지 모르겠다.
하지만, 이런 국내 고객들의 입맛에 맞게 SharePoint로 다국어 지원 사이트를 만든다는건, SharePoint의 기본 기능은 안 쓰고 대거 손을 대버리겠다는 의미와 동일하다.( 결국, 개발자만 죽어나거나, 안하니만 못한 시스템이 구축된다. )

과연 이 사실을 몇몇이나 알지 모르겠다.
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

ASP.NET Postback에 대한 분석 (2)

기술자료/.NET 2008. 4. 14. 20:23

여기서는  실제적인 Callback 구현에 필요한 각 부품들에 대한 소개와 그 조립 방법들을 전달한다.

일단 Callback을 수행하기 위한 Javascript를 구성하도록 한다.
Callback을 구현할 때 서버 내에서 동작하는 코드와 클라이언트 내에서 동작하는 코드로 나누어 구성한다. 물론 실제 구현 할 때는 대부분 서버 내에서 추가할 수 있지만, 실제 동작은 각기 나뉘어 동작하게 된다.
Callback의 시작과 종료 모두 Javascript를 이용하게 되기 때문에, 어느정도 Javascript에 대한 이해가 필요하다. (물론 고 난이도까지는 아니지만...)
자세한 내용은 아래의 more..를 클릭한다.

먼저 ASPX 페이지 내에서 Callback이 되려면, ICallbackEventHandler 라는 인터페이스가 페이지 내에 구현되어야 한다. ( 만일 WebPart 라면 WebPart 클래스 내에 구현한다.)
먼저 class 설정에서 ICallbackEventHandler 를 상속 받는다.
이 인터페이스가 속한 네임스페이스는 System.Web.UI 이다.

using System.Web.UI;

public partial class FrmCreateTeamSite : Page, ICallbackEventHandler
{
     .........
}

위와 같이 포함 시키면 된다. 그런데, 중요한건 ICallbackEventHandler 는 인터페이스 이기 때문에, 클래스 내부에 구현코드를 넣어야 한다. 구현되어야 하는 Method는 두개 인데, 그 두개는 ICallbackEventHandler.RaiseCallbackEvent 와 ICallbackEventHandler.GetCallbackResult이다.

ICallbackEventHandler.RaiseCallbackEvent
이 RaiseCallbackEvent 는 클라이언트(브라우저)에서 서버로 호출할 때 수행되는 로직이다.
보통 웹 페이지 호출의 순서는 브라우저내 URL 입력 -> URL에 해당하는 자원을 서버에서 처리 -> 서버에서 내려주는 그림(HTML, GIF, ActiveX 등등)을 표시 이다. 이 Callback이 실행되는 시점은 위의 작업이 다 끝난 뒤 Javascript 상에서 실행을 시작한다. 즉 그림 그릴 것 다 그리고 Javascript로 서버에 호출하게 되는 것이다. 이 때 서버에서 그 호출을 처리하는 부분이 바로 이 RaiseCallbackEvent 이며, 실제 Callback으로 인해 실행되어야 하는 로직은 여기에 넣도록 한다.

ICallbackEventHandler.GetCallbackResult
서버에서 Callback 처리 한 뒤 특정 결과 값을 클라이언트(브라우저)에 내려 보내야 할 때, 여기서 처리하게 된다. 이 함수를 구현하면 자동으로 string 값으로 돌려주도록 되어 있다는 것을 확인할 수 있다.


string ICallbackEventHandler.GetCallbackResult()
{
        return string.Empty;  
}

간혹 이 함수 내에서 클라이언트에 값을 돌려주므로 여기에 실제 Callback 연산 때 필요한 값을 넣으면 되지 않을까 생각하시는 분이 있을지도 모른다. 그런데, 개인적인 경험의 결과로 보면, GetCallbackResult 에서는 단순히 return 처리를 하는 로직만 넣는 것을 권장한다. 복잡한 로직이나, 여러 단계로 실행되어 실행 시간이 소요되는 로직이 들어가는 경우 Callback 실행이 중지되어 버린다. 그래서 가급적 RaiseCallbackEvent 에서 모든 서버 처리를 수행한 뒤, GetCallbackResult 에서는 return 처리만 할 수 있도록 구성한다.

using System.Web.UI;

public partial class FrmCreateTeamSite : Page, ICallbackEventHandler
{
   string sResult = string.Empty; 
   void ICallbackEventHandler.RaiseCallbackEvent(string eventArg)
   {  
       sResult = SomethingRun();
   }

   string ICallbackEventHandler.GetCallbackResult()
   {
        return sResult;  
   }
  
   string SomethingRun()
   {
        // Callback으로 무언가 실행
        // 결과를 돌려줌
       return "OK";   
   }
}

지금까지 구성내용은 서버에서 동작되어야 되는 코드들을 넣어 보았다. 아래에서는 클라이언트(브라우저)에서 동작될 코드들에 대해서 정리해 보도록 하겠다.

클라이언트에서 동작하기 위해서는 Callback을 실행시켜 줄 Javascript 문장과, 서버에서 돌려주는 결과값을 받을 문장으로 구분되어 진다. 먼저 Callback을 발생시키는 Javascript 문장은 아래와 같다.

javascript:WebForm_DoCallback('[서버컨트롤ID]', [인수값변수이름], [CALLBACK결과를 받을 함수이름],[실행컨텍스트구분용 변수이름], [에러처리용 함수이름], [비동기 처리?])

위의 각 한글 이름들에 각각의 값들을 넣으면 된다.
예를 들어 Callback이 발생되는 서버 컨트롤이 Page 이고, 클라이언트에서 서버로 건네줄 때 쓰는 변수가 arg이고, 실행 완료시 실행되는 Javascript 함수 이름이 JobDone 이며, 실행 컨텍스트 구분용 변수 이름이 context이고, 오류 처리용 스크립트 함수는 없으며 비동기로 실행되어야 되는 경우 아래와 같이 넣으면 된다.

javascript:WebForm_DoCallback('__Page',arg,JobDone,context,null,true)

자 그럼 각 파라미터에 대한 설명은 아래와 같다.

서버 컨트롤 ID : Callback이 실행되는 주체가 되는 서버 컨트롤 개체 ID를 넣으면 된다. 만일 Callback이 ASPX 페이지 자체에서 발생되는 것이면 해당 Page의 ID가 들어가면 되고, 만일 Button 인 경우에는 해당 Button의 컨트롤 ID가 들어가면 된다.

인수 값 변수 이름 : 클라이언트에서 서버로 값을 넘겨 줄 때 사용되는 인수 값을 의미한다. 이 때 넘겨 받을 때 문자열로 받기 때문에, 대부분의 영숫자 뿐만 아니라, 특수문자까지 넘겨 줄 수 있다. 그러나 많은 양의 데이터는 전달할 수 없으며, 간단한 신호적인 의미를 담는게 보통이다.

CALLBACK 결과를 받을 함수 이름 : 앞서 설명한 함수 에서 GetCallbackResult 문자열을 받을 때 사용되는 함수. 이 함수는 Javascript로 구현되어 있어야 하며, 최소한 value를 받아주는 파라미터가 있어야 한다. 만일 실행 컨텍스트 까지 정의되어 있으면 Context라는 파라미터도 있어야 한다. 위의 예제를 근거로 만든다면 아래와 같은 코드로 작성된 함수가 있어야 한다.

function JobDone(val, context)
{ 
    // 서버에서 받는 값은 val 임. val 값을 가지고 처리해야 되는 javascript를 구현
    document.getElementById('TextBox1').value = val;
    return;
}

실행 컨텍스트 구분용 변수 이름 : 만일 실행 결과의 유형이 여러가지 인 경우 그 구분을 위해 넣는 변수. 보통은 서버 -> 클라이언트 결과 값으로 대충 해결 할 수도 있지만, arg 값은 서버에 전달 되면 끝이기 때문에, 서버 -> 클라이언트로 넘겨지는 값에 일일히 명시 해주어야 한다. 이를 보다 편하게 할 수 있도록 클라이언트 -> 서버  -> 클라이언트 동작 중에 변하지 않는 값이 바로 이 값으로 이 값을 응용 하면, CALLBACK 결과를 받는 함수 하나로 여러가지의 처리가 가능하다. 그 예제가 아래와 같으 코드이다. 보면 context라는 변수가 있는데, 오로지 그 변수 값에 각 Step에 해당하는 값을 넣어 3단계에 걸친 처리를 수행할 수 있다. 

function DoJob(arg, context)
{
    WebForm_DoCallback('__Page',arg,JobDone,context,null,true)
}

function JobDone(val, context)
{  
    var step;
    if(context == 'FirstStep')
    {               
        // 1단계               
        setTimeout("JobStart('somevalue', 'SecondStep')",5);
        return;
    }
    if(context == 'SecondStep')
    {
        // 2단계
        setTimeout("JobStart('somevalue', 'LastStep')",5);
        return;
    }
    if(context == 'LastStep')
    {
        // 3단계
        return;
    }   
}
setTimeout("JobStart('somevalue', 'FirstStep')",1);

에러처리용 함수이름 : Callback 실행도중 에러가 발생했을 때 그 처리를 수행할 때 이용하는 스크립트 함수 이름이다. Callback이 클라이언트 단에서 에러가 나는 경우에는 바로 사용자가 보여지도록 Javascript에서 처리할 수 있지만, 서버에서 실행이 오류가 나는 경우 그에 해당하는 처리가 쉽지는 않다. 이 경우 처리해 줄 때 사용한다. 이 에러처리용 함수는 인터페이스 중 RaiseCallbackEvent Method에서 Exception이 발생하는 경우 불려지게 되는데, 이에 적당한 처리를 하는 Javascript를 구현한다. 만일 RaiseCallbackEvent 인터페이스에서 try ~ catch로 모든 Exception을 처리한다면 이 부분이 영원히 불릴일은 없을 것이다.

비동기 여부 : Callback 처리가 순차적으로 동작해야 되는지 여부를 결정하는 부분이다. 만일 이곳이 false인 경우 이 Callback이 처리될 때 까지 클라이언트 쪽 화면은 그대로 얼어 있게 된다. 트랜젝션상 성공/실패가 명확한 처리가 있는 경우에는 이 부분을 false로 하고, 아니면 true로 변경한다.



일단 Callback에서 가장 제일 중요하다고 생각되는 부분만을 정리해서 담아 보았다. 다음 3편에서는 실전에서 어떻게 쓰이는지 어떻게 활용할 수 있는지를 다시 둘러보는 시간을 갖도록 한다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

봄 그리고 피로.

잡글 2008. 4. 10. 14:35

어느새 3월 지나 4월.
집 근처의 여러 그루의 벚나무에서는 어느새 한아름 가득 벚꽃을 만발하고 있다.
차가웠던 바람은 시원해지고, 눈만 부시던 햇살은 벌써 따스하게 내린다.
작게 만들어진 그늘 밑에서 한숨을 자면 인생 낙원의 기분을 절로 느낄 수 있을것 같다.
만물 소생 따위야 그다지 관심 없으니 관계는 없다만, 이런 동적인 기분을 제공하는 날씨는 좋은것 같다.

하지만, 정신적인 피폐는 계속 되고 육체적인 피로감이 쉽게 안풀리기에
생각보다는 그리 즐겁지도 않고, 무언가를 이루고 싶은 의욕도 그다지 안든다.
사실 어지간한 선거들은 안빠지고 늘 했던거 같은데, 이번 만은 그런 생각조차 들지 않았다.
될대로 되라는 식의 생각과 귀찮다는 느낌이 강하게 들었다.

이 미묘하게 모순되는 환경과 나의 차이로 인해 점점 지치기만 한다.
기분 전환이 필요한 걸까...

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

ASP.NET Postback에 대한 분석 (1)

기술자료/.NET 2008. 4. 7. 20:16

ASP.NET에서 사용되는 각종 서버 기반의 Control ( Button, TextBox 등등 )이 동작하는 방법을 가만히 살펴보면, 일부 컨트롤에서는 화면 리프레쉬 없이 동작하곤 한다. 또, AJAX 기분을 내기 위해 특정 영역 부분의 데이터만 업데이트 할 때가 있다. 보통 이런 경우 ASP.NET에서 제공하는 Postback이라는 기능을 알게 모르게 사용하게 된다.

왜 이런 기묘한 구성요소를 만들었을까?
일단 왜 이런 것이 필요한지에 대해 살펴보면서 진행하도록 한다. 과거 ASP나 PHP로 웹 응용 프로그램을 짜게 되면, 이른바 Ghost 페이지라는 것을 만들어 사용한다. 화면에 사용자의 입력을 받는 Form을 만들고, 그 Form의 Action 부분에 Ghost 페이지의 URL을 적어 동작하게 한다. 그래서 사용자가 입력 후 Submit 이라는 Form 동작을 하면 자동으로  이 Ghost 페이지를 호출하게 한다.
호출 되는 이 Ghost 페이지는 앞서 있던 Form에 있는 사용자 입력 값들을 GET이든 POST으로든 값을 받아, 이 값을 이용하여 서버에서 처리해야 되는 작업( 데이터베이스 입/출력 또는 비지니스 로직 등등)을 수행하게 된다.
이에 반해 ASP.NET에서는 Ghost 페이지 역할을 없애고 대신 이 Postback이라는 기능으로 대처하게 되었다. 즉 Form에서 Submit을 할 때, 예전 처럼 Ghost 페이지를 부르는 것이 아닌 자기 자신의 페이지를 부르는 것이다. 만일 default.aspx 페이지에 사용자 입력용 Form이 있다면, 그 Form에서 Submit을 하면 default.aspx를 다시 부른다는 것이다. 그래서 사용자의 입력값들을 모두 default.aspx 페이지 내에서 처리해 줄 수 있게 되는 것이다. 한개의 페이지 내에서 다양한 사용자의 액션도 처리할 수 있고, 보다 서버와 유기적으로 동작할 수 있다는 것이다. 페이지 리다이렉트 로 인해 발생되는 보안적인 오류( 이 Ghost 페이지에 별도 추가 설정을 하지 않는 경우 몰래 이 Ghost 페이지만 접속하여 해킹을 할 수 있다. )도 해결할 수 있고, 구현 작업을 위한 각종 소스가 별도 페이지로 쪼개지지 않아 유지보수에도 우수하다. 그외에도 이런 저런 장점이 있지만, 자세한 내용은 ASP.NET 관련 책자나, 사이트를 참조하도록 한다.

이제 이 Postback의 동작 원리를 살펴보도록 하겠다.
이 Postback의 동작을 따라가기 위해서는 먼저 ASP.NET으로 된 Page의 Life cycle 파악이 필요하다. 영어로 Life Cycle이라고 적어 뭔가 고상해 보일지는 모르겠다. 간단히 말해서 서버 상에서 이 ASP.NET 페이지가 언제 메모리에 올라갔다가, 언제 내려가는지를 살펴 보는 것이다.
ASP.NET으로 만든 페이지 자체가 HTML을 의미하는 것이 아니기 때문에, 웹서버에서는 이 ASP.NET 페이지를 메모리에 올려 각종 로직들을 처리하고 그 결과 값에 해당하는 HTML을 생성해서 뿌려주는 것이다. 즉 이런 전체 흐름을 보고 바로 Life Cycle이라 표현 한 것 뿐이다.

즉 Postback이 동작할 때 저 Life Cycle 중 언제 동작하는지를 명확히 알기 위해서는 바로 이 ASP.NET 페이지의 Life Cycle에 대한 이해가 필요하기에 먼저 그 부분을 짚고 넘어가도록 한다.

맨처음 ASPX 페이지를 Web Browser를 이용하여 Load 하게 되면 바로 ASP.NET 페이지의 Life Cycle이 시작된다. 아래의 그림을 보면 Page Load, CreateChildControl, OnPreRender, SaveViewState, Render 이런 순으로 나열 되어 있는데, 이 나열들의 하나하나들은 System.Web.UI.Page 에 만들어져 있는 각각의 메소드들을 의미한다.
보통 ASPX 페이지를 만들게 되면 System.Web.UI.Page를 상속 받아 구성하게 되는데, 상속 받게 되면 그 안의 메소드들이 자동으로 ASPX 페이지에 있는 것 처럼 된다. 물론 자신의 ASPX 페이지 내에 아래와 같은 메소드가 없어도 되는 것 같다고 말씀하시는 분이 계실지 모르겠는데, 만일 ASPX 페이지내에 해당 메소드를 구현 하지 않았다면, System.Web.UI.Page 클래스 자체에 있는 각각의 메소드를 대신 호출 하게 된다. 사실 ASP.NET 페이지를 가지고 여러가지 작업을 하게 되면 보통 아래의 순서들에 제신된 메소드들을 override 해서 대부분 쓰게 된다.

다시 원점으로 돌아와서, ASPX 페이지가 맨처음 불리게 되면 웹서버의 메모리에 올라가게 된다. 그 시점에 실행되는 부분이 바로 Page Load 부분이다. 이 부분은 대개 초기화에 관련된 사항들을 많이 넣게 된다. 그리고 난 뒤 CreateChildControl 이다. 완전 처음 부터 ASP나 PHP 등의 순수 웹 응용프로그램 언어 부터 출발하신 분들 께서는 이 부분이 명확하지 않은들 싶은데, 이 개념은 어떻게 되면 Windows 응용 프로그램 개발 프로세스에서 돌출된 사항으로 생각된다.
즉 ASP.NET에서는 System.Web.UI.Page 라는 큰 틀 안에 Control들을 붙인다는 생각에서 출발한 것이다. 예전에는 사용자 입력하는 값들이나 보여주는 부분을 대부분 HTML 페이지 내에 Form을 만들어 구성했었다. 그렇게 되면 사실 서버와는 완전히 분리되어 Form에서 Submit을 할 때까지는 서버와의 데이터 통신이 불가능하다. 그래서 ASP.NET 에서는 Server Control 이라는 개념을 만들었다. 그래서 그 컨트롤들을 System.Web.UI.Page 내에 붙여서 마치 Window Form 프로그램에서 처럼 넓다란 Form 위에 컨트롤들을 얹어 얹어 만드는 것처럼 구성한 것이다.
보통 해당 객체 내에 있는 Controls 라는 콜랙션 내에 더해주는 것으로 처리하게 된다.
(예 : Button btnOK = new Button; this.Controls.Add(btnOK); )
이런 유형의 소스 구현을 바로 CreateChildControl에서 수행한다.
다음은 OnPreRender. 이를 설명하려면 Render라는 것을 먼저 언급해야 할 것 같다. Render라는 것은 현재 Page 클래스내에 있는 Control들을 모두 합쳐 만든 HTML을 생성해주는 부분이다. 즉 실제 그리기 부분으로 이 부분에 직접 HTML을 뿌려주게 할 수 도 있고, CreateChildControl 에서 Controls.Add(xxxxx)를 통해 조립한 뒤 그 조립한 그대로를 자동으로 HTML화 시켜주기도 한다. 그런데, 이렇게 Render 하기에 앞서, UI에 관련된 일부분의 데이터 조작이나 수정작업을 할 때, 여기서 처리하게 된다. 대개는 PageLoad나 CreateChildControl에서 해주기는 하지만, 가끔Control이 생성되고 Add 되고 난 뒤, 별도 조작을 해야 하는 경우 바로 이 OnPreRender에서 그 뒷처리를 하곤 한다. 그리고 SaveViewState. 페이지가 새로 고침을 하는 경우 보통 HTML로 만든 경우 Input 내에 있는 각종 값들은 날라가게 된다. 그에 반해 ASP.NET을 이용해 만든 TextBox의 경우에는 새로 고침을 해도 값이 안전하게 담겨 있는 경우가 있는데, 그게 바로 이 SaveViewStatus 단계 때, 어떤 값들을 어떤 순서로 저장되는지를 정의하는 부분이다. 사용자가 Button을 누르게 되면 화면이 자동으로 새로 고침하게 되는데, 이 경우 ASP.NET의 Life Cycle이 Redner를 실행한 뒤, 모든 데이터가 사라지게 된다. 즉 C#으로 Behind Code로 클래스를 만들었을 때, 클래스 내의 맴버 변수들의 값들도 모두 사라지게 된다. 이 값들을 임시라도 저장을 할 때 이 부분에 구현하게 된다. 값을 실제 저장하는 방법들은 ASP.NET에 관한 다른 책들이나 자료를 참고하도록 한다. 마지막으로 Render.드디어 각종 처리를 수행한 뒤, 실제 HTML을 찍는 부분이다. 여기서는 HttpTextWriter 라는 개체를 제공하는데, 그 안에 원하는 HTML을 쓰거나, 아니면 base.Render()를 실행해서 해당 Page에 딸린 각종 서버 기반 Control들을 HTML화하여 자동으로 써지게 하는 것이다.

자 위의 Render 까지 하게 되면 실제 웹서버 상에서 해당 페이지 HTML을 클라이언트에게 제공하고, Page 및 그에 딸린 Behind Code들은 메모리 밖으로 퇴출된다. 즉, 모든 데이터들이 사라지게 되는 것이다. ( 물론 SaveVIewState에 저장해 놓을  수 있다. )

위는 ASP.NET 페이지의 Life Cycle이였다면, 과연 이 Postback은 언제 동작하는 것일까?.
일단 위의 모든 Life Cycle이 끝나야 한다. 실제 Postback 처리는 사용자가 실제 수행하는 동작을 대처하기 위한 부분이기 때문에, 무엇보다 선결되야 하는 것인 사용자의 웹브라우저에 HTML로 그림이 확실히 그려져 있어야 한다는 것이다. 그러기에 위의 단계가 완전히 끝나야, 실제적인 Postback이 실행 될 수 있는 조건이 된다.

Postback을 부르기 위해서는 대부분 Javascript를 사용하게 된다. 만일 Button 이라는 서버 기반의 컨트롤이 있다면, C#에서는 Button btnOK = new Button(); btnOK.Text = "OK!"; this.Controls.Add(btnOK);와 같은 단 세줄의 코드로 끝내져도, 실제 HTML로 찍히게 되면, 실제 Javascript를 이용하여 실행될 수 있도록 한다. 즉 ASP.NET의 서버 컨트롤이 진짜 서버에서 실행 동작된다고 보면 안되고, 실제로는 서버 컨트롤의 HTML + Javscript가 바로 그 서버 컨트롤이 된다.
Button .... 이라는 소스는 <input type="button" ..... >이 되고, 저 <input 태그 내에 Javacript로 서버를 다시 부르게 끔 하는 것이다.

아래의 그림을 보면 Callback이라고 적힌 부분이 있는데, Postback으로 이해를 하도록 한다.
자 아래의 Run Callback이라는 부분이 있다. Button에 해당하는 HTML 소스를 끄집어 내 보면 그 안에 click="webform.doPostback(......."  뭐 대충 이런 느낌의 메소드가 들어 있다.
바로 그 부분이 javascript 부분이고, 그 자바 스크립트에서는 각종 필요한 정보를 서버에 보내기 쉽게 구성하는 것이다.

자 이 Postback이 실행되면 어떻게 동작하는 것일까?
아래의 그림을 보시면 대략적인 Postback이 동작하는 그 순서를 볼 수 있을 겁니다.

맨 위의 Run Callback 이라는 부분이 있는데, 그 부분이 바로 Javascript로 된 서버 호출 로직을 담고 있는 부분이다. 이 부분이 기본 ASP.NET 컨트롤이라면 저 Run Callback이 Form의 Submit 으로 동작하는 부분일 것이고, 별도 PostBack 기반의 Callback Interface를 만들어 구성한 경우라면 Javascript로 실행하게 될 것이다. 여기서는 Javascript로 구성한 사용자 정의 Postback을 기준으로 나열할 것이므로 위의 그림이 나오는 것이다.

자 그림을 보면 Postback을 실행하는 경우 LoadViewState를 한뒤 CreateChildControl을 하고 Page를 Load 한다. 그리고 난 뒤 실제 Callback을 실행한다.
아까 맨처음에 떳던 그림과는 순서가 조금 다르지 않은가?

일단 제일 큰 차이점은 바로 Render 부분이 없다는 것이다.
Postback이 발생하였을 때, 실제 페이지에 대한 그림 그리는 부분은 없고, 단지 서버 상에서 ViewState를 복구하고 서버 컨트롤들을 구성한 뒤, Page Load 부분을 수행한다. 그리고 난뒤 Callback에 대한 실제적인 처리를 시작하게 된다. 그림 없이 데이터만 복구 하고 데이터만 돌려주는 구조라는 것이다.

위의 Page LifeCycle을 보면서 Callback에서 처리해야 하는 데이터에 대해 어떻게 보존할 것인지, 그리고 어떻게 처리할 것인지를 판단하면서, 맞추는 것이 관건이다.
초기 ASPX 페이지가 Load되서 Render된 후 Page Unload 되는 순간 모든 데이터는 파괴된다. ( 특히 aspx.cs 파일 내에 정의한 각종 member 변수들 ) 만일 이런 값들을 Callback에서 사용을 한다면 반드시 SaveViewState에서 저장해 놓도록 한다.

그리고 실제 Callback이 처리되어야 하는 로직에서는 RaiseCallbackEvent 에서 처리하도록 한다.

각 상세 코드는 2편에서 계속하도록 한다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

페이지 보안 오류

기술자료/.NET 2008. 4. 7. 14:58

MOSS 관련 도구를 ASPX로 만들때 종종 아래와 같은 SPException에 빠져 작업을 할 수 없는 경우가 있다.

"이 페이지에 대한 보안 유효성 검사가 잘못되었습니다. 웹 브라우저에서 [뒤로] 단추를 클릭하고 페이지를 새로 고친 다음 작업을 다시 시도하십시오." [ The security validation for this page is invalid. Click Back in your Web browser ]

초기에는 해당 페이지의 보안 유효성의 문제에 대한 정확한 정의를 알지 못해 오로지 짐작으로만 대략 파악하고 있어, 이에 대한 대처 방안이 전혀 없었다.
혼자 만의 짐작으로는 한개의 ASPX 내에서 너무 다양한 일을 수행하여 Page 자체의 Time-Out 이 걸렸거나, 아니면 SPList를 수정하는 도중 SPListItem의 설정을 동시에 수정하려 하거나 해서 발생하는 것이라 판단했었다.

그러나 어느것 하나 명확치 않았고, 더욱이 해결 방법이 너무 모호해서 알수 없었다.
이 중 헤딩 끝에 간신히 나름 '이거다!' 라고 판단 된 부분만을 언급하도록 하겠다.

1. 위치가 다른 자원을 접근 시도 할 때.
보통 관리용 ASPX 페이지를 작성 한 뒤, 이 페이지를 접근할 때 http://hostname/_layouts/xxxxx.aspx 이런 식으로 하게 된다. 그런데, 만일 저 xxxxx.aspx 페이지 내에 다른 사이트의 SPSite를 열어서 그 안의 값을 수정하는 경우에 바로 페이지 보안 오류가 발생한다.

다시 정리하자면, http://hostname/_layouts/xxxxx.aspx 를 띄운 뒤,
내부 코드에서 SPSite site = new SPSite("http://hostname/sites/childsite") 라는 코드가 들어 있고, 저 site 라는 변수를 통해 web을 얻고(site.RootWeb) 그 web의 Title을 수정하는 경우다.

즉 xxxx.aspx 페이지는 hostname 이라는 Site에서 띄운 것인데, xxxx.aspx 페이지안에서 처리하는 사이트는 hostname/sites/childsite 인 것이다. MOSS 입장에서는 hostname에 소속된 xxxx.aspx 페이지 주제에 다른 site의 자원을 접근하여 처리하는 것을 용납하지 못한다는 의미로 판단하면 된다.

이 경우, 여러 사이트의 자원을 일괄적으로 변경할 필요가 있다면, 별도 Windows Application으로 만들거나, STSADM에 명령어를 추가 구성해서 STSADM을 이용하여 변경하도록 한다.
만일 굳이 ASPX로 하고 싶다면, 저 ASPX에서 해당 사이트로 Redirect 하여, xxxx.aspx를 다시 띄우도록 한다.
즉 this.Response.Redirect("http://hostname/sites/childsite/_layouts/xxxxx.aspx") 라고 해서 xxxx.aspx를 다시 실행하는 것이다.

 

2. 페이지에 대한 401에러 대처 기능 부재.
아마도 대부분이 이 경우에서 걸리는 경우로 들 수 있다.
보통 application.master나 default.master와 같은 MOSS 내에서 제공되는 Master 페이지를 이용하여 구성하는 경우 이 에러가 발생하지 않는데, 유독 독자적인 ASPX 페이지를 만드는 경우 발생하게 된다. 즉 빈 ASPX 페이지를 만든 뒤, 그 안에 자신이 만든 각종 코드를 넣어 실행하면 바로 페이지 보안 오류가 발생하게 된다.
그렇다고 default.master나 application.master 를 쓰자니 디자인 커스터마이징 할 때는 쥐약인 것이다.

그럼 왜 default.master와 application.master를 끼면 괜찮고, 빈 ASPX 페이지로 구성하면 이런 문제가 발생하는 것일까? 그 이유는 바로 401 에러를 의도적으로 내는 MOSS의 문제로 판단된다.

HttpWatcher 라는 HTTP 프로토콜 송수신 패킷을 확인해 보면, MOSS에서는 항상 ASPX 페이지를 띄울 때 의도적으로 401 에러를 유발하게 되는데, 애석하게도 이 경우 페이지 내 코드에서는 모든 경우에 SPException으로 떨어지게 된다.
그렇다면 우리가 만들 ASPX 페이지에서는 이 에러를 피해 갈 수 없을까?

의외로 간단하게 해결 될 수 있다.
일단 우리가 만드는 ASPX 페이지내에 <form runat="server" /> 가 필요하다. ASPX 페이지를 만들었다면 당연히 들어 있겠지만, 혹시나 해서 언급한다. 일단 Server 컨트롤 로써 동작하는 <form>을 만들어 주고, 그 안에 

  <SharePoint:FormDigest runat=server/>

를 넣어주도록 한다. 그러면 최소한 401 에러가 떨어지는 부분에 대해서는 페이지 처리 없이 넘어가고 그 뒤에 실제 코드를 실행해 주게 된다.

몇가지 더 확인해보고 검토해봐야 겠지만, 위의 2가지 경우가 현재로는 대부분 발생되는 문제로 생각되며, 그 이후에 추가적으로 발견되면 리포트 하도록 할 예정이다.

Technorati 태그: MOSS,페이지 보안 오류
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

스팸 트랙백 없애기!

잡글 2008. 3. 26. 14:04
이 Blog라는 시스템은 다 좋은데, 문제가 트랙백이다.

사실 이 트랙백을 잘 쓰는 사람은 잘 쓰겠지만, 나 같은 무뇌한 같은 경우에는 잘 쓰지도 않는다.
그런데, 외국에서 이상한 사람들이 와서 영어로, 중국어로 된 미묘한 스팸성 트랙백을
잔뜩 걸어놓고 튄다.

한, 두개면 애교로 심심할 때 접속해서 모조리 지워라도 주겠는데,
이건 맨날 하루에 10~30건씩 등록해서, 어느날 들어와보면, 몇 페이지의 트랙백이 걸리곤 한다.
이건... 지대로 짜증이였다.

그래서 이런 저런 방법들을 찾다가 찾다가 겨우 발견한 사이트에서 그 방법을 발견했다.

http://blog.bagesoft.com/691

일단 트랙백 디비를 모조리 날리고, 다음에 각 글들에 딸린 트랙백 갯수를 초기화 한뒤,
기본적으로 올라오는 글들에 대해 트랙백 걸기를 Off 시켜주는 기능이였다.
사실 이거 Config 상에 있었으면 하지만.....
뭐 급한대로 저렇게 적용해야 겠다.

그런데, 지금 파견나온 곳에서는 telnet이 안되는 모냥;;;;;

현재까지 내 사이트에 등록된 불량 감자들!!!! ( 아래의 more... 클릭하믄 나옴 )

118.173.240.199 
12.172.207.3 
12.198.95.126 
12.201.131.66 
121.171.194.212 
122.162.42.88 
122.163.192.189 
122.163.47.112 
122.2.189.254 
122.53.107.148 
122.53.36.138 
123.195.96.225 
124.105.49.50 
124.109.33.248 
124.13.99.44 
124.171.246.229 
124.217.56.33 
124.81.178.123 
125.60.243.91 
134.241.194.28 
145.53.127.242 
158.75.249.211 
161.58.189.91 
164.83.111.254 
165.21.155.68 
167.7.9.163 
168.103.143.188 
168.187.160.146 
189.140.237.51 
189.158.93.171 
189.18.123.185 
189.18.144.227 
189.43.3.2 
189.71.137.147 
189.81.242.79 
190.136.94.209 
190.154.119.185 
190.157.184.163 
190.188.232.92 
190.22.14.1 
190.24.111.27 
190.51.187.15 
190.64.105.52 
190.64.34.143 
190.64.35.165 
190.73.52.95 
190.74.43.252 
190.86.12.206 
193.138.242.130 
194.108.126.35 
194.118.43.1 
194.145.161.21 
194.150.201.44 
194.27.90.141 
194.6.220.70 
194.85.135.245 
194.88.154.12 
195.101.158.220 
195.146.242.16 
195.172.166.226 
195.175.50.198 
195.225.178.29 
195.229.242.154 
195.5.149.89 
195.55.218.93 
195.56.81.143 
195.75.146.229 
196.209.251.3 
196.217.249.190 
198.145.182.32 
198.54.202.250 
199.217.156.114 
200.103.20.249 
200.107.35.34 
200.111.67.2 
200.121.144.240 
200.130.24.47 
200.138.148.154 
200.16.16.13 
200.218.241.34 
200.226.81.204 
200.25.235.90 
200.253.14.78 
200.31.42.3 
200.67.141.89 
200.68.73.193 
200.71.177.2 
201.194.234.254 
201.231.151.105 
201.29.16.153 
201.3.91.13 
201.35.159.224 
201.41.79.32 
201.6.130.225 
201.8.183.50 
201.8.34.106 
202.156.13.2 
202.75.52.93 
202.84.17.42 
203.144.160.250 
205.234.184.87 
206.212.242.138 
206.51.226.198 
206.51.226.243 
206.71.150.45 
207.44.147.170 
207.74.27.2 
208.109.254.156 
208.110.218.138 
208.113.170.9 
208.53.131.178 
208.53.138.54 
208.53.157.13 
208.53.170.146 
208.79.200.172 
209.17.190.78 
209.172.35.41 
209.200.16.180 
209.249.65.142 
209.250.226.82 
209.64.30.18 
210.187.27.194 
212.108.224.162 
212.122.206.52 
212.122.214.3 
212.15.182.79 
212.170.106.133 
212.183.65.187 
212.43.13.1 
213.131.75.140 
213.133.102.67 
213.148.16.237 
213.157.239.82 
213.158.196.105 
213.200.102.248 
213.229.62.177 
216.104.33.114 
216.130.161.111 
216.17.26.137 
216.246.29.104 
216.40.236.82 
216.85.19.10 
217.126.94.244 
217.160.142.111 
217.169.36.162 
217.18.135.36 
217.194.157.13 
217.197.113.46 
217.20.113.117 
217.98.12.2 
218.230.223.29 
219.147.217.91 
219.254.35.168 
220.236.82.18 
221.163.8.155 
222.127.223.71 
222.127.228.22 
222.127.228.5 
222.127.228.6 
24.184.94.239 
24.26.69.91 
24.36.95.49 
38.113.5.161 
41.250.211.28 
58.165.60.190 
59.182.247.38 
59.183.161.254 
59.52.254.223 
59.92.129.110 
60.191.220.45 
61.133.87.226 
61.247.18.7 
62.133.137.135 
62.143.142.153 
62.173.36.140 
62.21.80.24 
62.238.33.114 
62.244.71.214 
62.51.15.120 
63.249.103.120 
64.111.122.29 
64.129.209.226 
64.13.226.26 
64.131.67.150 
64.191.125.228 
64.191.71.149 
64.191.93.101 
64.20.53.18 
64.202.161.130 
64.231.238.114 
64.73.138.77 
64.79.208.243 
64.85.161.254 
65.255.133.156 
65.71.66.26 
65.98.120.201 
65.99.221.31 
66.11.229.146 
66.179.166.198 
66.197.220.230 
66.197.221.187 
66.202.56.11 
66.212.16.194 
66.212.23.141 
66.212.28.34 
66.226.79.116 
66.232.107.104 
66.232.113.128 
66.246.246.50 
66.41.135.212 
66.42.222.208 
66.6.122.148 
66.7.204.111 
66.79.163.86 
66.79.165.156 
66.79.167.222 
66.79.168.140 
66.79.171.94 
66.90.103.134 
66.90.104.149 
66.90.104.187 
66.90.118.87 
66.90.73.227 
66.90.77.2 
66.92.67.98 
67.159.41.87 
67.159.41.88 
67.159.44.136 
67.159.44.206 
67.159.44.55 
67.159.44.98 
67.159.45.22 
67.159.45.50 
67.189.192.99 
67.207.77.70 
67.66.188.91 
67.67.16.232 
67.93.33.130 
68.153.118.44 
68.162.176.39 
68.178.224.222 
68.178.28.38 
68.225.212.4 
68.30.170.114 
68.33.160.237 
68.96.129.134 
69.109.183.99 
69.158.55.18 
69.159.124.95 
69.159.193.21 
69.245.10.113 
69.49.75.63 
69.64.71.62 
69.64.76.82 
69.64.87.252 
69.65.126.37 
69.65.85.69 
69.72.153.218 
69.9.42.210 
70.114.52.245 
70.119.152.89 
70.154.87.223 
70.173.213.178 
70.247.37.246 
70.55.231.199 
70.86.151.66 
71.84.113.250 
71.85.9.43 
72.141.138.57 
72.147.245.81 
72.167.36.135 
72.167.36.70 
72.22.81.253 
72.220.139.132 
72.232.138.34 
72.249.44.148 
72.36.149.82 
72.46.130.106 
72.46.130.23 
72.46.157.18 
72.55.174.24 
72.65.104.218 
72.9.152.150 
72.9.153.233 
74.168.237.254 
74.182.128.19 
74.205.126.241 
74.208.16.140 
74.208.16.19 
74.208.16.26 
74.220.207.141 
74.52.104.116 
74.52.159.98 
74.53.109.226 
74.62.153.11 
74.62.153.19 
74.62.153.44 
74.9.32.178 
75.117.178.114 
75.82.29.91 
75.89.1.217 
76.114.178.135 
76.24.249.236 
76.254.249.97 
76.69.255.19 
76.76.13.95 
77.114.96.6 
77.130.181.30 
77.160.26.212 
77.188.126.106 
77.243.100.171 
77.61.20.41 
77.74.198.212 
77.81.22.143 
77.94.118.38 
78.102.77.2 
78.106.1.136 
78.106.236.145 
78.106.39.168 
78.150.159.7 
78.154.16.1 
78.163.99.132 
78.164.154.241 
78.179.135.27 
78.179.186.243 
78.179.33.125 
78.179.62.159 
78.3.105.235 
78.56.57.85 
79.112.101.108 
79.112.89.237 
79.116.204.43 
79.116.53.169 
79.120.55.250 
79.146.45.240 
79.163.85.45 
79.175.2.248 
79.184.35.43 
79.186.232.158 
79.211.227.105 
80.144.230.197 
80.217.149.96 
80.227.1.100 
80.227.1.101 
80.39.175.238 
80.48.73.214 
80.61.200.86 
80.78.109.217 
80.80.111.129 
80.80.140.15 
80.99.203.213 
81.137.90.113 
81.154.100.236 
81.169.239.129 
81.190.87.164 
81.213.90.81 
81.214.62.122 
81.215.241.205 
81.215.248.210 
81.240.165.229 
81.37.94.116 
81.88.49.21 
81.9.164.164 
81.9.164.193 
82.13.104.129 
82.137.255.221 
82.146.225.130 
82.162.13.58 
82.171.216.78 
82.177.175.18 
82.195.26.2 
82.202.90.4 
82.74.234.48 
82.79.248.213 
82.79.96.78 
82.83.113.58 
82.83.202.39 
83.10.12.183 
83.10.22.144 
83.11.153.243 
83.11.187.155 
83.11.208.57 
83.11.62.47 
83.12.192.202 
83.12.62.171 
83.12.80.194 
83.13.81.251 
83.145.186.153 
83.15.25.238 
83.167.100.101 
83.167.116.186 
83.167.116.188 
83.17.235.14 
83.19.196.3 
83.191.39.17 
83.2.97.197 
83.21.105.103 
83.21.252.19 
83.21.66.125 
83.22.33.247 
83.22.90.32 
83.228.37.120 
83.237.230.197 
83.238.240.24 
83.24.194.207 
83.25.0.41 
83.25.101.23 
83.26.139.5 
83.27.248.15 
83.28.219.86 
83.29.195.41 
83.3.189.211 
83.30.254.76 
83.32.142.211 
83.4.254.99 
83.6.112.48 
83.77.188.123 
83.8.215.153 
83.9.241.154 
84.1.245.36 
84.145.239.185 
84.168.109.106 
84.203.168.134 
84.238.206.102 
84.245.193.243 
84.3.156.178 
84.60.79.38 
84.66.182.246 
85.103.64.7 
85.140.105.61 
85.172.16.78 
85.172.60.22 
85.178.46.48 
85.179.101.214 
85.196.20.131 
85.198.214.182 
85.244.92.47 
85.68.226.215 
85.72.131.157 
85.89.162.137 
85.90.197.51 
85.98.39.137 
86.0.104.231 
86.101.34.236 
86.127.25.239 
86.164.249.56 
86.31.97.240 
86.72.125.61 
86.96.226.13 
87.101.244.6 
87.105.49.49 
87.156.79.194 
87.187.223.244 
87.188.253.115 
87.189.90.46 
87.207.163.63 
87.218.251.53 
87.65.6.166 
87.98.222.138 
88.101.232.244 
88.108.101.40 
88.156.168.216 
88.201.128.162 
88.205.133.232 
88.217.67.200 
88.226.204.126 
88.227.71.23 
88.228.85.185 
88.234.176.160 
88.244.236.215 
88.249.14.104 
88.254.36.50 
88.65.211.125 
88.7.188.103 
88.84.200.21 
89.110.9.237 
89.114.192.150 
89.123.139.10 
89.123.175.153 
89.133.116.140 
89.142.251.136 
89.15.88.63 
89.163.145.92 
89.171.106.130 
89.178.41.124 
89.229.218.199 
89.230.6.236 
89.249.117.246 
89.252.213.192 
89.58.4.155 
90.13.107.9 
90.9.76.59 
91.122.120.242 
91.186.11.213 
91.186.21.51 
91.76.3.140 
91.77.72.253 
92.36.43.34 
92.37.209.244 
92.80.138.149 
92.80.169.141 
92.81.228.202 
92.81.67.145 
92.83.117.174 
92.83.13.8 
96.232.233.37 
96.3.130.109 
98.206.53.4 
98.212.133.81 
98.26.203.118 
99.139.239.235 
99.161.121.192 
99.230.41.72 
99.238.40.191

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

  • «
  • 1
  • ···
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • ···
  • 156
  • »
250x250

블로그 내에 소스 코드 삽입 이사온 기념 스킨도... RSS 전문 기능 비활성화 관련. 스킨 바꾸어 보았습니다. 서버 파일 정리 좀 했습니다.

«   2025/05   »
일 월 화 수 목 금 토
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

인터파크 Visual Studio Tutorial 친구 SharePoint Google Apps Engine 2010 e-book 협업 오류 것 지름신 블로그 me2sms 매뉴얼 불만 MOSS 2007 Azure twi2me 수 moss 좀 me2dayzm 비스킷 WSS java 개발환경 me2photo windows Buscuit

  • Total :
  • Today :
  • Yesterday :

Copyright © 2015-2025 Socialdev. All Rights Reserved.

Copyright © 2015-2025 Socialdev. All Rights Reserved.

티스토리툴바