It's Myself

MOSS 2007을 사용하다 보면, 종종 재 설치해야 하는 경우가 발생합니다.

여기서 말하는 재설치가, 오류로 인해서 일부 프로그램을 다시 설치하는 등의 레벨이 아닌, 진짜, 완전히 밀고, 다시 설치해야 되는 경우를 말합니다.
예를 들어 프로젝트를 하나 뛰었는데, 한번 뛰고 난 결과 자신이 가진 MOSS가 완전히 걸래(?)가 되어 뭐 하나 하면 바로 오류 뜨고, 뭐 하나 하면 다운되는 그런 상태를 말하죠.  보통의 경우에는 새 술은 새 부대에 담는다는 마음으로 운영체제를 밀기도 합니다.

그러나, 세상살이가 쉽지만은 않을 때도 있죠. MOSS 지운다고, 운영체제 다시 설치해야 되는 경우라면... 참 우울하지 않을까요?

일단, 설치야, 개인기로 설치한다고 하고, 재 설치를 위하여 깨끗하게 언인스톨하는 방법을 일러드리겠습니다.

1. MOSS 2007 관련 추가 사항들 언인스톨.

  - 오해의 소지가 있을듯 한데요.
    만일 MOSS 솔루션들(WSP 파일들)은 상관 없습니다.   
    Feature나, 어셈블리 DLL, 이런것들은 사실 하시나 안하시나 상관은 없습니다.
    단지, msi나 exe로 설치한 것들을 말씀드리는 것입니다.
    대표적인 것이 바로 언어팩인데요. 이런 것들은 깨끗하게 날려주세요.
    프로그램 추가/삭제로 해결 하실 수 있습니다.

3. 서비스 종료

  - MOSS 2007 언인스톨 하면 설치 프로그램 자체가 수행하기는 하지만
    확실하게 하시려면 이 서비스들을 STOP 시켜 주시기 바랍니다.
    이미 STOP되어 있는 거면 그냥 두세요.

    * IIS Admin Service - IISADMIN
    * Office SharePoint Server Search - OSearch
    * Office Document Conversions Launcher Service - DCLauncher
    * Office Document Conversions Load Balancer Service - DCLoadBalancer
    * Windows SharePoint Services Adminitration - SPAdmin
    * Windows SharePoint Services Search - SPSearch
    * Windows SharePoint Services Timer - SPTimerV3
    * Windows SharePoint Services Tracing - SPTrace
    * Windows SharePoint Services VSS Writer - SPWriter
    * World Wide Web Publishing Service - W3SVC

     시작 -> 제어판 -> 관리도구 -> 서비스을 이용해서 하실 수 있으며,
     명령줄을 이용하신다면 NET STOP [서비스명] 을 해서 멈추게 할 수 있습니다.
     위의 목록에서 "-" 뒤에 붙인 내용이 바로 서비스 명 들입니다.

3. MOSS 2007 언인스톨

  - 1번 사항들이 완료되면 이 2번을 수행하게 됩니다.
    간혹, 이 2번 단계가 진행이 안되시는 분들이 있는데, 그 정도로 망가지신 거면,
    GG 입니다. 언인스톨이 안되거나, 문제가 생겨 프로그램 추가/삭제에 끝까지
    MOSS 2007이 남아 있다면 GG를 하시고, 운영체제를 다시 설치하실 각오를 하세요.
    만일 레지스트리 수정의 마법사 라시면, MOSS 2007을 강제로 레지스트리 상에서
    언인스톨 해버리시고 다음 단계를 밟으세요.
    조금이라도 자신이 없으시면 걍 운영체제 다시 설치하세요. -_-;;;

4. 윈도우즈의 구성요소 중 IIS 삭제.

  - Windows 2003이라면 서버 구성 마법사라는 프로그램을 실행할 수 있는데요,
    그 마법사를 사용하시던가, 프로그램 추가/삭제에 있는
    Windows  구성요소 추가/삭제에 들어가셔서 응용 프로그램 서버에 체크되어 있는
   것을 빼세요. 그리고 다음을 클릭해주세요.

4. 폴더 삭제.

  - 언인스톨 되도, 꼭 남게 되는 폴더 들이 있습니다. 그 폴더들을 날려주세요.
    1%의 커스터마이징도 없었다고 해도 아래의 폴더들은 살아 있곤 하거든요.
    설치시에 기본적으로 했다면 아마 아래와 같은 폴더들이 있을 겁니다.
    그 폴더들 이하로 모조리 날려주시면 됩니다.

    * C:\Program Files\Microsoft Office Servers
    * C:\Program Files\Common Files\Microsoft Shared\web server extensions\12
    * C:\Inetpub\wwwroot\wss

5. 윈도우즈의 구성요소 중 IIS 추가
   - 4단계의 작업을 역으로 해주세요.

6. ASP.NET 2.0 모듈 설치
   - IIS에 ASP.NET을 추가하는 작업을 해야 합니다. 이 작업은 .NET Framework 폴더내에 있으며 시작 -> 실행에서 하시거나, 혹은 명령줄 창에서 실행하시면 됩니다.
   -  x86 이라면 아래의 명령줄의 경로를 x64면 x64에 맞게 경로를 수정하세요.
   C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -iru

7. IIS 상에서 ASP.NET 2.0 모듈 활성화
   - 인터넷 정보 서비스 관리자를 실행합니다.(inetmgr)
   - 왼편의 Tree에서 웹 확장 서비스를 선택한 뒤, 오른편 목록에서 ASP.NET v2.0.50727을 선택한 뒤, 왼쪽의 허용 버튼을 클릭합니다.

8. MOSS 2007 설치.
   - 늘 설치하던 대로 설치하시면 됩니다.

21세기 초, MS 운영체제에서 대거 수많은 보안 문제들이 대두되었다.
특히 MS Windows 2000. 과거 불안하게 동작되었던 운영체제의 기반을 싹다 갈아 엎고 만들어서 인지, 안정적으로 돌아가는 운영체제라는 희대의 찬사와 함께, MS를 운영체제 회사로 자리매기게 해주었다. 그러나, 보안 문제가 심각하게 대두되면서 보다 강력하게 보안문제를 해결하기 위해 Windows 2003에서는 그에 따른 철저한 계정 정책을 만들었다.

초기에는 모든 서비스들은 Local System이라는 계정으로 동작해서, 모든 자원을 주무르도록 하였으나, Windows 2003에서는 Local Service와 Network Service라는 계정을 제공하여, 제한적인 권한을 주어 제한 내에서 동작할 경우 ( 특정 폴더나, NIC 등의 단순한 자원 접근 시 ) 가급적 이 제한 계정에서 동작하도록 강력하게 권장한다.

그런데, AD에 Join되어 있는 MOSS Farm에서 이런 제한적인 Local 계정으로 접속하였을 때 문제가 없을까 라는 의문이 생겼다. 금일 고객사에 방문하여 고객사가 안고 있는 문제를 분석하는 도중에 발견하게 되었는데, 그 쪽에서는 MS Exchagne의 Federation 기능 - 인증 대리자 역할. 즉 Exchange에 접속할 때 사용되는 Credention(아이디와 패스워드로 인증된 결과물)의 생성이 필요 없이, MOSS로그인 사용자와 Exchange 사용자가 같다라고 표현 해줄 수 있는 일종의 대리자 - 을 활성화 하기 위해 MOSS의 웹 응용 프로그램 실행 계정을 Network Service계정으로 했다고 한다.
그런데, Network Service라는 것은 로컬 계정이기 때문에( http://msdn.microsoft.com/en-us/library/ms684272(VS.85).aspx) IIS를 통해 AD에서 자원을 가져올 수 없다. 그런데 이 설정 방법은 MOSS에 대한 기술 지원을 한 MS의 한 엔지니어가 권장한 방법이라고 말씀하셨다. 도무지 이해가 안되서 되묻기도 했지만....일단 현재 파악해야 하는 문제와는 별개라고 판단되어 대충 얼버무리고 함구하고 나오긴 했으나, 의문감이 배가 되고 있다.

금일 테스트 결과에 따라서 나오겠지만, 현재로는 아마도... 이상하다고 생각된다.

과연 어느쪽이 옳은 걸까?

* Update : 2008 / 05 / 14
SSP ( 공유 서비스 제공자 : Shared Service Provider )를 만들려면 NetworkService 계정으로 만들어진 웹 응용 프로그램은 안된다. 반드시 AD에 접근 가능한 계정이여야 만들어진다.

근래 MS에서 제시한 서버 제품 군 중 나름대로 이슈가 된 제품으로 MOSS 2007이라고 있다. MOSS 란, Microsoft Office Server System의 약자로 Office 제품군을 엮어주는 서버 제품군의 총칭을 의미한다.  DOC, XLS, PPT 등등 다양한 오피스 파일들에서 부터 공유 서비스를 제공하는 Grove 까지 그 영역은 한도 없이 넓다.

그런데, 현재 대부분이 드라이브 걸고 있는 MOSS의 영역은 포털 솔루션으로써 다루어지는게 현실이다. 한국 MS에서도 대부분의 고객들에게 포털의 성격을 강조하고 있고, 또한 고객들도 그렇게 받아들이고 있다. 그러다 보니, 점점 고객들은 Naver를 기대하고 기대한 만큼 설치 운영 후 그대로 실망을 갖게 된다. 포털이 갖는 각종 자료의 수집이나 정리, 그 외에도 수많은 기능들, 아름다운 화면 어느것 하나 제대로 부합되는 건 없다. ( 있어도, 기능이 약하거나, 많은 수정 작업을 수행해야 할지 모른다. )

그런데, 눈을 돌려서 포털로써의 MOSS가 아닌 문서 관리 및 협업용 솔루션 MOSS로 포커스를 맞추어 보면, 이것 처럼 정확한 시점으로 제작된 것은 없다고 생각된다.

일예로, 만일 사무실 내에 각종 MS Office 제품군들을 이용한 파일들이 난무한다고 하자.
그  중 회계 업무를 수행하는데, 엑셀 파일을 관리부 직원과 회계부 직원 그리고 회계부 과장이 동시에 쓴다고 가정하자. 물론 이 훌륭한 엑셀에서는 파일 공유 사용기능이 있어, 네트워크 공유로 동시에 열어 쓸 수 있다.

여기서 관리부 직원이 실수로 회계부 직원이 작업 중이던 워크시트를 날렸다고 하자.
이랬을 때 취하는 행동. 회계부 과장이 "뭔가 작업할 때 꼭 백업해서 다른 이름으로 저장해 놓으라고 했지!!!!!" 막 뭐라 할 것이다. 그러나 이미 엎질러진 물. 돌아가기엔 먼길을 가버린 후다.

이를 MOSS 에서 저장을 하고, 버전 관리를 켜게 되면, 해당 파일을 편집할 때 마다, 저장 할 때  마다 해당 파일에 대한 버전을 계속 업을 해주어 자동 버전 백업을 해주게 된다. 그렇다면, 저장된 시점을 찾아 해당 파일을 복구해주면 위의 사태를 해결할 수 있을 것이다.

또 하나, 만일 회계부 직원, 관리부 직원 여러명이 회계 사무실에 보내야 할 중요한 엑셀 파일을 작성한다고 할 때, 그 문서를 작성하기 위한 일정이나, 작업들을 계획 할 때, 이리저리 사람들이 왔다 갔다 하면서 구두로 해결하거나, 회의실 하나 차지해서 함께 모여 합숙 분위기로 작성을 한다.

이를 MOSS에서 사용할 때 해당 문서에 대한 작업 사이트를 만들면, 그 안에 해당 문서를 중심으로한 팀 사이트가 만들어지면서, 일정이나, 작업 목록등을 사용할 수 있고, 또한 이 사이트 내에 접근할 사용자들을 정의해서 외부 사람은 접근하지 못하게 만들 수 도 있다. 최종적으로 모든 작성이 완료되면, 실제 원본 위치에 다시 게시해주게 된다.

사실 들춰보면 MOSS의 숨겨진 기능이나 장점들이 무척 많다.
그러나 문제는 고객의 생각은 언제는 기존 웹 시스템으로 굳어져 버려, 간단하게 해결되길 원한다. 그렇게 굳어진 생각을 다양한 사례를 들어 조금 다른 길로 가더라도, 더욱 편리하고 효율적으로 갈 수 있다면 조금은 마음을 열어주지 않을까?

답답한 마음에 한번 끄적여본다.

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

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

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

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

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

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

과연 이 사실을 몇몇이나 알지 모르겠다.

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

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

more..

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

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편에서 계속하도록 한다.

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가지 경우가 현재로는 대부분 발생되는 문제로 생각되며, 그 이후에 추가적으로 발견되면 리포트 하도록 할 예정이다.

보통 일반적인 게시판에서는 올린 글에 대해서는 누구든지 보게 된다.
또한 특정 글의 수정 작업은 자신이 작성한 항목에 대해서만 수행할 수 있게 된다.

그런데, 혹시 아래와 같은 기능이 필요할 수 있다.
1. 하나의 게시판을 여러사람이서 공유하지만, 마치 자신만의 글만 보이도록 하고 싶다.
2. 어떠한 글이든, 권한만 있으면 편집이 가능하다.
3. 모든 사용자가 아이템 자체를 편집 못하게 한다. ( 마감 처리 )

사실 1번과 같은 사항은 대개 View를 수정해서 자신이 작성한 글만 보이게 처리할 수 있다.
하지만, 만일 View를 바꿔 보게 되면 전체가 다 보이므로 1번의 조건에 합당하게 처리되지 않는다.  2번 같은 경우에는 글이나 문서가 공유되는 것이라서 팀 사이트 의 경우 팀 구성원이 원하는데로 수정가능한 경우를 의미한다.
3번의 경우는 해당 게시판의 만료적인 의미로 두면 되며, 더 이상 누구도

이 처리를 위한 방법은 SPList의 속성 중 아래의 2개의 프로퍼티가 이런 기능을 제공하게 된다.

 속성 내에 넣는 값
 1 - 모든 사용자가 모든 아이템을 읽을 수 있다.
 2 - 자신이 생성한 아이템에 대해서만 읽을 수 있다.

 속성 내에 넣는 값
 1 - 모든 사용자가 모든 아이템을 권한만 있으면 편집 가능하다.
 2 - 사용자가 생성한 아이템만 편집 가능하다.
 4 - 누구도 아이템에 대해 편집이 불가능하다. ( 사이트 관리자만 가능 )


위의 속성만 세팅하게 되면, 각각의 기능을 수행할 수 있게 된다.

기본 값으로 ReadSecuriry는 1이, WriteSecuriy는 1로 설정되어 있다.

만일 위의 3가지 요구사항중 1번을 처리하려면,
ReadSecurity를 1, WriteSecurty는 1또는 3을 넣으면 된다.

2번을 처리하려면,
ReadSecurity를 1, WriteSecurty는 1로 넣으면 된다.

3번을 처리하려면,
ReadSecurty를 1, WriteSecurty를 4로 넣으면 된다.