'2008/01/21'에 해당되는 글 3건

SPUser를 등록하는 방법은 사실 간단하다.

SPWeb.SiteUsers.Add("계정ID", "이메일주소", "보여줄 이름", "기타 메모")

위의 방법으로 사용하게 되면, 사용자 목록에 등록이 된다. 그러나 이렇게 등록하는 것으로는 해당 사용자가 사이트 내에서 제대로 활용할 수 없을 뿐더러 로그인 해봐야, 액세스 거부 창이나 팍팍 뜬다.

그러면 그 즈음 되서 권한 부분을 체크해 보게 된다.

게임은 지금 부터다.
그렇다면 이 권한 등록하는 방법들이 어떻게 있을까?

하나는 MOSS 2007에서 제공되는 그룹에 추가하는 방법이 있고, 다른 하나는 한사람 자체에 따로 권한을 주는 방식이다.

1. MOSS 2007에서 제공되는 그룹에 추가하는 방법
보통 그룹은 기본적으로 "사이트이름"+" 구성원", "사이트이름" + " 관리자" 형식으로 생성되어 진다.
그래서 보통 아래와 같은 형태로 짜기도 한다.

    SPGroup group = web.Groups["Members"];
    SPUser user = web.SiteUsers["KNOIE\\neohind"];
    group.AddUser(user);

그런데 그 그룹 이름이라는게 로컬라이즈 된 이름이라서 만일 "테스트 사이트" 라는 이름의 사이트에는 "테스트 사이트 구성원" 이런 식의 이름이 그룹이름이 된다. 객관적으로 좀 너무한 이름이지 않을까 싶다. 예제와 같은 이름이라면 위의 코드가 아래처럼 되어야 할 것이다.

   SPGroup group = web.Groups["테스트 사이트 구성원"];
   SPUser user = web.SiteUsers["KNOIE\\neohind"];
   group.AddUser(user);

좀... 너무 하지 않을까? 왠지 하드 코딩하는 기분을 지울 수 없고, 만일 어디에 포팅된다면.. 왠지 대박이지 않을까?
(저 같이 유지보수나 남아서 X 치우다 보면, 우울해집니다.)

그렇다면 어떻게 하면 좋을까?
이를 위해서 SPWeb에는 아래와 같이 관련 그룹에 대한 개체를 바로 꺼내 쓸 수 있는 부분이 있다

SPWeb.AssociatedOwnderGroup // ( 관리자 )

SPWeb.AssociatedMemberGroup  // ( 구성원 )

SPWeb.AssociatedVistorGroup // ( 방문자 )

즉 위의 예를 기준으로 변경해 보면 아래와 같은 코드가 된다.

  SPGroup group = web.AssociatedMemberGroup;
  SPUser user = web.SiteUsers["KNOIE\\neohind"];
  group.AddUser(user);

그 외 그룹(디자이너, 계층 구조 관리자)들은 알아서....

여튼 저 그룹에 Users 항목에 SPUser 형태로 더해 주면 된다. 그러면 자동으로 해당 권한을 할당해 줄 수 있다.

2. 개별 계정별 개별로 권한 매기기.

여기서 부터는 조금 복잡하게 돌아간다. 아마도 SPGroup에 특정 권한 쎄우려고 할 떄 사용하곤하는데, 이 또한 개별적으로 처리할 수 있다.

SPUser user = web.SiteUsers["KNOIE\\neohind"];
// 만일 관리자, 구성원, 방문자 단위가 아닌 기능별로 Roledefinition을 만드는 방법을 별도로 더 파악해야 함.
// 범위를 넘어가므로 여기서는 Contributor 즉, 구성원으로 권한을 설정.
SPRoleDefinition defContribute = web.RoleDefinitions.GetByType(SPRoleType.Contributor);
SPRoleAssignment roleContribute = new SPRoleAssignment(user as SPPrincipal);
roleContribute.RoleDefinitionBinding.Add(defContribute);
Web.RoleAssignments.Add(roleContribute);

위의  순서대로 보면 먼저 SPRoleDefinition을 생성 한다.
그리고 난 뒤 SPRoleAssignment를 생성한다. 여기서 생성할 때는 권한을 설정하려는 대상(보통 SPUser나 SPGroup)을 넣는다.
그리고 SPRoleAssgignment 내에 RoleDefinitionBinding에 앞서 만든 SPRoleDefinition을 추가한다.
맨 마지막으로 만들어진 SPRoleAssignment를 실제 권한을 설정하려는 Web, List, ListItem에 추가한다.

대부분의 MOSS 2007 개발자들은 이 사이트와 웹 간의 차이를 명확히 모르거나 어렴풋이 알아도 그게 그거가 아닌가 라는 어조로 표현하곤 한다.
하지만 개념적으로 명확히 틀린 구조이며 그 차이는 명확히 틀리다.

다음 그림을 보면 대략적으로 왜 사이트와 웹이 틀린지 알 수 있다.

즉 사이트 여기서는 SPSite인데, 최상위의 일종의 거대한 상자라고 보면 될 것이다. 이 안에 무수한 SPWeb을 붙여서 하나의 사이트를 만드는 것이다. 즉 사용자들은 SPWeb을 보는 것이지 SPSite를 보는 것은 아니다. 실제 사용자가 보기 위한 페이지, 리스트들의 모든 정보들은 바로 저 SPWeb에서 나오고, 그 외에 전체 검색이나, 차이점 분석 결과 등 전체 사이트에 대한 설정, 구성, 정보들은 SPSite에서 다루게 된다.
우리가 보통 새끼까기 하듯이 사이트 아래에 사이트를 만든다고 하는데, 그건 SPSite를 만든 것이 아니고 바로 저 SPWeb을 만드는 작업이라고 보면 된다.

보통 개발자들이 혼돈을 느끼는 부분이 바로 여긴데, MOSS 관리자 페이지에 가면 사이트 만드는 부분의 명칭이 "사이트 모음 만들기" 라고 적혀 있고, 해당 사이트의 페이지에 가서 사이트 관리 도구에 들어가면 하위 사이트 만들기 라고 적혀 있으니, 사이트 모음 = SPSiteCollection, 사이트 = SPSite 라고 생각하는 우리의 입장에서는 이 또한 무슨 망발이냐!!! 라는 의문을 바로 제기할 수 있다. 

그.러.나. SDK를 보면 우리를 또 한번 더 햇갈리게 한다. 양키 말을 들어보면 Web, Site 구분없이 막지껄이고 떠든다. 뭐가 Web이냐, Site냐.. 최소한 난 이것 때문에 상당한 혼란을 일으켰다. 그러면 저 SPSite와 SPWeb은 1:1로 하나씩 묶여서 구성된 건가... 했다.

그러나 진실은 SPSite는 무조건 한개, 그 하위의 모든 사이트들은 SPWeb이다. 그를 증명하는 부분은 바로 컨텐츠 DB. 만일 사이트 모음을 한개 만들어 놓고, 그 안에 새끼 까듯이 계속 사이트들을 만들어 99개를 만들었다고 하자. 그 때 컨텐츠 DB안에 사이트는 몇개 일까?
    1개다.
궁금하신 분은 테스트 해보시면 알 수 있다.
즉 사이트 모음은 SPSite를 의미하기 때문에, 그 SPSite 갯수인 1개가 들어가고 그 이후에는 어차피 SPSite 내에 포함된 하위 SPWeb들이기 때문에, 컨텐츠 DB 입장에서는 사이트 갯수에 포함 안되고, 단지 1개의 SPSite가 좀 커졌구나... 정도로 인식할 뿐이다.
(즉 늘어나는건 컨텐츠 DB의 사이즈 뿐이다.)

이런 개체들의 관계를 따라, 각 개체를 참조 할 때는 아래와 같이 찾아 들어가면 된다.

Microsoft.SharePoint.Administrator.SPWebApplication 로 가는 방법

  [SPSite 개체].WebApplication

Microsoft.SharePoint.SPWeb로 가는 방법

  [SPSite 개체].OpenWeb("url")

그리고 만일 위의 그림에서 1번 사이트를 연 뒤 (new SPSite("1번 사이트 URL")) 한 뒤, 저 OpenWeb을 써서 2번 사이트 아래의 웹을 찾으려면 당연하게 오류를 뿜는다. 저렇게 그림으로 보면 당연하거 아녀? 라고 되묻겠지만, 간혹 어떤 분들이 1번 사이트 열어놓고, 2번 사이트 내의 웹이 안 열린다고 투덜 댄다. MOSS 2007 버그니 뭐니.. 하는데... 한번 즈음 소스 검사 해보심이 ...

그리고 만일 특정 SPSite 및의 모든 하위 사이트(절대 SPSite가 아니다, SPWeb 이다.)에 대해 세팅을 동일하게 적용한다고 했을 때는 해당 SPSite를 열고 RootWeb을 연 뒤, 그 RootWeb에서 Webs를 이용하여 트리 탐색하듯이 찾아 들어가야 한다. 1번 사이트를 보면 그 아래의 SPWeb 아래 SPWeb들을 뒤져야 된다.
그 검색로직은 트리를 찾는 방법대로 진행되어야 할 것이다.

아침을 좀 빠르게 일어나 앉았다.
사실 MP3 찾는 거라든가, 어제밤에 챙겨 놓지 않은 노트북등 정리안된 부분을아침으로 미루었기에 당연히 일찍 일어나야 하는데, 문제는 내가 보통 때 그 시간에 잘 일어나지 못한다는게 핵심이다. 어쨌던 일찍 일어난 아침 덕에, 그간 찾지 못해 못들었던 모차르트 K183 알레그로 콘 브리오를 다시 듣기 위해 뒤적였고, 못챙겼던 출근 가방 챙겼다. 그리고 여유 있는 아침과 함께 너무 일찍 일어나 생긴 현기증을 동시에 느끼면서 따듯한 방바닥을 바로 비비며 미묘한 유혹에 져볼까 말까 하는 아슬아슬한 도전도 즐겼다.

그리고 옷 챙겨 입고 나서는 순간 온 세상은 잿빛 속 흰색으로 가득찼다.
우중충한 하늘에서 무수하게 떨어지는 눈은 한가득 내려 우리집 앞쪽의 모든 지붕들을 감싸버렸다.
길가에는 덩어리 진 흰 눈덩이들이 나돌아 다니고, 사람들은 우산 챙겨 들고 이리저리 바쁘게 지나가고 했다.
나도 그 속에 파묻혀 회사로 향하다, 문득 이른 아침의 시간을 보고 사진기를 꺼내들었다.

집 앞쪽에 위치한 공원도 아닌 조그만한 휴식처에 소복히 쌓인 눈이 이뻐보였다고나 할까.
가끔은 이런 여유도 즐겨 볼만 한 것 같다.