2010년 7월 30일, 미투데이

Posted at 2010.07.30 20:17 // in SNS // by MOOVA 무바㏇
  • 잊을 때쯤 되면 전화를 해 줘서 다시한번 삶의 열정을 깨우치게 하는 친구들이 있다. 그들에게 정말 고맙다는 말을 하고 싶다. 아마 그들은 80이 되서 외로울 때 멀리서 순대하나 싸 가지고 오는 그런..그냥 친구들이다. 계산하는 친구보다 그냥 걱정해주는 친구가있어서좋다.

 

  • SS나 대기업들이 하는 관리방법중에 하나는 사람들끼리 서로 경쟁을 붙여서 프로젝트내 성과를 최대로 올리자는 것을 종종 보게 되는데, 이러한 관리방법을 간파한 개발자들에겐 이러한 방법이 쓰잘대기 없는 구정물과 같다. 시야가 넓어진 개발자들을 관리하는 방법은 그들의 말을 들어주는것이다. [경쟁구도보다는 협력구도]


  • 가끔씩 프로세스가 형편없는 프로젝트안에서는 대부분의 사람들이 프로세스가 필요없다는 것을 강조한다. 바뻐죽겠는데 무슨 프로세스를 도입하냐..하지만. 그건 프로세스가 단순히 족쇄라는 착각때문이다. 프로세스 정립은 족쇄를 트는게 아니라 당사자들간에 자유를 만끽하게 해준다.

 

  • 5(ruby,python,groovy,perl,javafx)개 스크립트 언어 중 가장 쉬운 언어는?? 개인적으론 python이 가장 쉽고,다음 쉬운건 groovy, 다음은 ruby~. 스크립트 언어 하나 알아두면 다른 스크립트 류는 다 거기서 거기란거~~**( . )

 

  • 세상은 참~~ 넓고도 좁다. 미국에서 살고 있는 군대 후배 스타크래프트2에서 만났음.ㅋㅋ

 

 

신고

'SNS' 카테고리의 다른 글

2010년 8월 2일, 미투데이  (1) 2010.08.03
2010년 8월 1일, 미투데이  (3) 2010.08.02
2010년 7월 30일, 미투데이  (2) 2010.07.30
2010년 7월 29일, 미투데이  (4) 2010.07.29
2010년 7월 27일, 미투데이  (4) 2010.07.28
2010년 7월 25일, 미투데이  (4) 2010.07.25
블로그코리아에 블UP하기
2fb
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.31 09:46 신고 [수정/삭제] [답글]

    음.. 클로저가 정확히 어떤건가요?
    파이썬 외에는 다뤄본적이 없지만 파이썬 확실히 매력이 넘치는 언어인거 같아요

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.07.31 14:44 신고 [수정/삭제]

      클로저는 루비나 파이썬 프로그래머들에게 공기와 같은 존재라고 해도 과언이 아닙니다. 사실 클로저만해도 이야기 할 것이 엄청 많습니다. 사상적 배경이라던지, 다른 언어에서 쓰고 있는 클로저의 형태라던지, 앞으로 자바에 제안된 클로저의 이야기라던지.. 총체적으로 볼때 한마디로 이야기하면 클로저는 '코드블락'입니다. 아직 자바에선 제대로 돌아가는 클로저는 없구요, 앞으로 추가될 예정이랍니다. javascript의 객체지향 프로그래밍에서도 종종 응용할 수 있는게 클로저니까요 잘 만 사용하면 프로그래밍을 업할 수 있는 도구입니다.

댓글을 남겨주세요.

2010년 7월 29일, 미투데이

Posted at 2010.07.29 01:30 // in SNS // by MOOVA 무바㏇
  • 정치가 나쁘다라고 말하는것은 정치 그 자체를 의미하는게 아니고, 권력을 오용할 때 정치가 부패되었다고 말한다. 권력오용의 시작은 정리되지 못한 문화속에 편법이 자연스럽게 스며들어 권력으로 탈 바꿈할때부터다.이쯤되면 그게 진짜 권력인지 오용된 권력인지 판가름하기 힘들다. 2010-07-29 00:22:07
  • 화타. 세계최초로 환자몸을 마취산으로 마비시켜 외과수술을 한 신의. 삼국지에서는 조조때문에 죽임을 당했다고 하죠. 관우도 치료해줬다고 알고 있습니다. 만약 그의 저서가 지금까지 전해내려오고 있다면 아마 현대 의학은 많이 바뀌었을 겁니다. 화타는 실화랍니다. 2010-07-29 00:23:09
  • 스타2와 facebook의 연동. 별걸 다해놨구먼 *.*( me2photo) 2010-07-29 00:37:30

    me2photo

이 글은 moova님의 2010년 7월 29일의 미투데이 내용입니다.

신고

'SNS' 카테고리의 다른 글

2010년 8월 1일, 미투데이  (3) 2010.08.02
2010년 7월 30일, 미투데이  (2) 2010.07.30
2010년 7월 29일, 미투데이  (4) 2010.07.29
2010년 7월 27일, 미투데이  (4) 2010.07.28
2010년 7월 25일, 미투데이  (4) 2010.07.25
2010년 7월 23일, 미투데이  (0) 2010.07.23
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.29 18:19 신고 [수정/삭제] [답글]

    음.. Facebook을 학교 선배들의 초대편지로 인해 시작했는데 정이 안가더라구요.
    그런데 몇몇계정에서 전부 검색해서 막 초대하고 이런건 막강해서 놀라우면서도
    두려움이 앞서게 되더라구요. (아.. 구차니란 나쁜 어른이 ㅠ.ㅠ)

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.07.30 17:35 신고 [수정/삭제]

      저도 아직까지는 facebook에 익숙하지 않아서 말이예요 ㅎㅎ, 친구 초청할 때 사용했던 메신저나 게임에서 facebook사용자들을 긁어 오는 방법은 기발하더라구요.

  2. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

    2010.07.30 15:41 신고 [수정/삭제] [답글]

    스타2의 페이스북 연동 보고 깜놀.
    해외에서는 페이스북 사용률이 장난 아닌가봐요.

댓글을 남겨주세요.

2010년 7월 27일, 미투데이

Posted at 2010.07.28 07:36 // in SNS // by MOOVA 무바㏇
  • 강된장찌게 맛있다. 입맛을 돋구게 하고, 면역력 증진에 좋고, 머리를 맑게 해주고. 이 처럼 웰빙음식이 어디 있을까?(된장찌게 me2photo) 2010-07-27 08:33:14

    me2photo

  • 네이트온 사용자 정보 수집하고 비공개하는거 일반적이더군요. 예전 싸이월드 음악플레이어 인스톨할때도 프로그램 심어놓던데. 사용자 동의하에 해야할텐데..저런건 음냐..
    네이트온, MAC 주소랑 컴퓨터 이름은 왜 수집하는거냐? 이건 뭐… 일방적인데? by 위너 에 남긴 글 2010-07-27 08:36:22
  • 헉~ 다음 메일을 3년간 방치해 놨더니. 메일 쌓인거 봐라. ㅎ. 뭔 뉴스레터들이 이렇게나 많은지.(me2photo me2photo) 2010-07-27 16:13:00

    me2photo

  • 오아~. 예스24 플레티넘 회원으로 승격~~. 혜택은 : 아이스발레, 무료배송쿠폰,영화할인권, 마니아 쿠폰. 이게 다임?? 설마..( me2photo) 2010-07-27 16:22:40

    me2photo

  • 세상은 참 넓은것 같은데…… 2010-07-27 22:16:01
  • 빠르게 하는 것이 좋을까, 상세하게 하는 것이 좋을까? 답은 없다. 교집합이 될 수도 있고, 차집합이 될 수도 있고. 합집합이 될 수도 있고.…결국은 환경(사람,시국,이해관계)에 좌우될 수 밖에 없는 노릇.~** 2010-07-27 22:39:34
  • 점점 개시키들이 많아지고 있다., 저것들의 뇌는 어떤 재료로 되어 있길래, 그렇게 반인륜적인 짓들을 할까. 콱 !! 에혀~ 2010-07-27 22:45:05
  • 항암을 하게 되면 다음 항암까지 14~20일의 텀이 있다. 항암 후 일주일은 정말 힘들고,보통 8일째 되어서야 내 컨디션을 되 찾는것 같다. 컨디션을 찾을 때 되면 다시 다음 항암이 기다리고 있다. 이렇게 반복되니 따분하기도 하고 지겹기도 하고.. 그래도 버텨야지안카나 2010-07-27 23:28:42

이 글은 moova님의 2010년 7월 27일의 미투데이 내용입니다.

신고

'SNS' 카테고리의 다른 글

2010년 7월 30일, 미투데이  (2) 2010.07.30
2010년 7월 29일, 미투데이  (4) 2010.07.29
2010년 7월 27일, 미투데이  (4) 2010.07.28
2010년 7월 25일, 미투데이  (4) 2010.07.25
2010년 7월 23일, 미투데이  (0) 2010.07.23
2010년 7월 16일, 미투데이  (0) 2010.07.17
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.29 00:58 신고 [수정/삭제] [답글]

    전 요즘에 쌈 사먹는다고 쌈장으로 먹는데 고추장이 맛없게 느껴져요 ㅠ.ㅠ

  2. 2010.07.29 05:09 [수정/삭제] [답글]

    비밀댓글입니다

댓글을 남겨주세요.

2010년 7월 26일, 미투데이

Posted at 2010.07.27 05:31 // by MOOVA 무바㏇

보호되어 있는 글 입니다.
내용을 보시려면 비밀번호를 입력하세요.

2010년 7월 25일, 미투데이

Posted at 2010.07.25 21:44 // in SNS // by MOOVA 무바㏇
  • 병신, 바보, 쪼다리 박사. 이런 애칭들이 가끔은 사람을 인간미 있게 만들더라구요. 단 써야 할 사람에게만 연사를 해야함 ㅋ1시간전
  • EBS 강사 장희민 망언 - 세상엔 참 개념 없는 무뇌들이 종종 나타난다. 누군 군대를 가고 싶어서 갔나~! 응? 1시간전
  • 요즘엔 Onjava.com와 javaworld.com 에 글이 올라오지 않고 있다. 꽤 유익한 Article이 많이 올라오는 곳인데, 어찌된겨?? 2010-07-25 20:43:17
  • 이북 외서를 사려면 Amazone.com보다 packtpub를 추천합니다.~ 2010-07-25 20:46:13
  • 항암 4차 후 일주일이 지났다. 매우 힘든 기간이었지만, 버티는것도 적응이 되니 내 안에 약한 마음도 일장 재칠 수 있게 된다. 3~4차가 가장힘든 시기라던데, 그럭저럭 잘 버텨내고 있다.~** 2010-07-25 20:48:11
  • 오늘 큐티는 포켓 워치만 니 전집으로( me2photo) 2010-07-25 20:51:42

    me2photo

  • 카톨릭과 개신교, 왜 그리 적대관계를 가지고 있는지 모르겠다.카톨릭은 개신교를 인정하는 반면 개신교는 카톨릭을 절대 인정하지 못한다고 한다. 종교적 탄생배경이나 역사적 형국이 그렇게 만들었겠지만 이제는 고만해야 할 때 아닌가. 사실 개신교 파벌은 심각하게 너무 많다. 2010-07-25 20:53:52
  • 요즘 볼만한 영화들이 쏟아져 나온다. 예전 같았으면 친구나 여친꼬셔서 무조건 영화관으로 달려갔겠지만, 지금 형국이 이러니 우짜쓸까~ 아아 인셉션보고시파, 이끼보고시파~~ 당분간은 집에서 감상해야함.ㅠㅠ 2010-07-25 20:56:30
    Mastering Spring MVC 3 , See the showcase live in this 8 minute screencast:, mvc-showcase, 출처 Spring MVC 3 showCase 말 그대로 Spring MVC를 마스터링
    • TDD,BDD,DDD - behaviour-driven과 관련된 내용이 잘 나와 있는 곳.

이 글은 moova님의 2010년 7월 25일의 미투데이 내용입니다.

신고

'SNS' 카테고리의 다른 글

2010년 7월 29일, 미투데이  (4) 2010.07.29
2010년 7월 27일, 미투데이  (4) 2010.07.28
2010년 7월 25일, 미투데이  (4) 2010.07.25
2010년 7월 23일, 미투데이  (0) 2010.07.23
2010년 7월 16일, 미투데이  (0) 2010.07.17
2010년 7월 16일, 미투데이  (4) 2010.07.16
블로그코리아에 블UP하기
  1. Favicon of http://gkyu.co.kr BlogIcon G-Kyu

    2010.07.25 23:21 신고 [수정/삭제] [답글]

    인셉션...개인적으로 추천 드립니다~ 기발한 상상력과 CG의 영화였습니다 ^^

  2. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

    2010.07.26 09:27 신고 [수정/삭제] [답글]

    저번주에 저도 인셉션 보고 왔는데...
    와 정말 대박이예요. 감독의 기발한 상상력이 대단하더군요.

댓글을 남겨주세요.

웹플레이어의 향수와 푸념

Posted at 2010.07.23 18:44 // in Language/PHP // by MOOVA 무바㏇
.
2010:07:23 17:24:50

한창 프로그래밍에 취해 있었던 어린 시절 벅스뮤직의 웹플레이어를 보다가, 한번 만들어 보면 어떨까 해서 답습한 자작 웹플레이어다. 해당 커뮤니티에 등록한 날짜를 보니 2004-04-08일 이라고 되어있다. 6년전이라 별로 오래되진 않은 것 같은데, 그 때 밤을 새며 Wnidows Media 6.0 API보며 밤을 지새웠던 열정이 되살아난다. 당시엔 웹플레이어가 한창 뜨고 있던 추세였던 터라 winamp같은 desktop용 플레이어에서 벅스뮤직과 같은 웹플레이어로 사람들이 갈아타고 있는 분위기였다. 당시 개발자들은 취미가 있거나 관심있는 사람들만 이런 번외 분석을 하고 있어서 소통할 수 있는 공간은 오로지 커뮤니티밖에 없었다.

이것을 공개하면서 여러업체들이 웹플레이어 시장을 공략해보자는 제의가 빗발쳤지만, 딱 잘라 말했던 기억이 난다.
"오픈소스니 파는게 아니오~" 라고 말이다. 왜 그랬을까?? 참 배부른 소리했다...


더보기



저때만든 코드를 보니 얼굴이 붉어진다. 코드 하나하나에 주석을 달아 두었다.;;;; 함수네이밍이나 코드컨벤션과 같은 이해도 없었을 뿐더러 레이어의 분할같은 사상적인 개념도 없었던 탓에 스파게티 소스를 커뮤니티 사람들에게 설명하느라고 참 고생한 흔적이 역력하다. 하지만 Event Driven의 개발기법은 알게 모르게 습득한 탓에 이벤트 관련된 부분은 따로 재정의를 해둔것을 발견한다.

더보기



 저 때 만약 Object Programming에 대해서 이해도가 있었다면 아마도 객체로 분할해서 코드를 작성했을 것이다. (하지만 php스크립트에 객체지향 개념이 나왔던게 PHP5였지 아마?) 지난 코드를 구하기도 쉽지만은 않다. 하지만 커뮤니티의 온전한 보호속에 이렇게 고스란히 지난 추억을 되살릴 수 있는 시간이 있어서 좋다. 지난코드를 보고 또 한번 상념에 잠기며 객체 프로그래밍으로 다시 꾸며볼 생각을 하니 또 한번 작은 웃음이 나온다.

그리고 다시 한번 포스팅할꺼리가 늘어났다. "프로젝트내 자바스크립트 컴포넌트 제작"이라는 제목으로 글을 올리려고 하는데
귀차니즘때문에 손이 가질 않는다. 큰맘먹고 조만간 올려드려야지..

공유하고 이야기하고 싶은 것들이 너무나 많다. 블로그에 공개하지 못한 부분들까지 같이 공유하고 싶은 공간이 필요하다. 유난스럽지도 않고 대놓고 상대접을 하는 어려운 장소가 아닌 자연스러운 그런곳 말이다. 인터넷은 기록을 지배하는 장소라서 독자들은 사람이 올린글로 사람을 판단하는 실수를 가끔씩 한다. 그것이 전부가 아닌데도 불구하고 그것을 마치 전부인것 처럼 느끼는 것이 바로 그것이다. 다시한번 말하지만 내 블로그는 격식과 절차 없는, 쓰고 싶을 때 쓰는 그런 장소이고, 풍유가 섞인 그런 곳이다. 내 인생의 2%라고 해야함이 맞다. 블로그로 밥을 먹고 광고하면서 사는 그런 부류가 아니란 이야기다.

최근엔 블로그 작성이 예전만큼 자유롭지가 않다. 보는 눈이 많아졌으니 예의를 갖출 필요도 있는 것이다.
자유스럽게 글을 기재할 수 있는 또 다른 공간이 필요한 시점이기도 하다.



PS :
언젠가 YUI와 Prototype.js를 샅샅히 훑어보고 나름대로 분석해둔 문서가 있었는데,
삼성의 개인 피시 포멧 요구때문에 지금은 내 피시에 없다. (물론 api분석이 아니라 구조론에 대한 분석문서였다.)
젠장.. 프리랜서 피시를 그렇게 무자비하게 포멧을 해 버리다늬..
그럴려면 프리랜서를 고용하지 말던가 말이다.;;; 대놓고 프리랜서를 고용했으면서 대놓고 하는 대접이라니.
하는 짓을 보면 차~암 징하다.




저작자 표시 비영리 변경 금지
신고

'Language > PHP' 카테고리의 다른 글

웹플레이어의 향수와 푸념  (2) 2010.07.23
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.23 21:04 신고 [수정/삭제] [답글]

    헐 저 때문에 부랴부랴 찾아서 올리신글 같아요 ㅋ
    한번 시간내서 뜯어봐야겠습니다 +_+!
    좋은자료 감사합니다!!!!

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.07.24 00:23 신고 [수정/삭제]

      오랜만에 자바스크립트를 보니 예전 생각이 나서요.ㅎㅎ
      아..정말 공유할 수 있는 개념들이 많은데.. 블로그에 그냥 올리는 것도 그렇고 말이예요. 시간상 다 올릴수도 없고.. 언제한번 스터디나 해볼까요? ㅎㅎ

댓글을 남겨주세요.

2010년 7월 23일, 미투데이

Posted at 2010.07.23 18:30 // in SNS // by MOOVA 무바㏇

이 글은 moova님의 2010년 7월 23일의 미투데이 내용입니다.

신고

'SNS' 카테고리의 다른 글

2010년 7월 27일, 미투데이  (4) 2010.07.28
2010년 7월 25일, 미투데이  (4) 2010.07.25
2010년 7월 23일, 미투데이  (0) 2010.07.23
2010년 7월 16일, 미투데이  (0) 2010.07.17
2010년 7월 16일, 미투데이  (4) 2010.07.16
2010년 6월 29일, 미투데이  (4) 2010.06.29
블로그코리아에 블UP하기

댓글을 남겨주세요.

Spring Security - OID, SID, ACL 2

Posted at 2010.07.23 09:39 // in Principle // by MOOVA 무바㏇

Spring Security의 Domain ACL[각주:1]에선 개별의 Entity객체에 CRUD권한을 걸어둘 수 있다. Role,URL,Resource등 여러가지 자원에 자물쇠를 걸어두는 것은 일반적인 권한 상식이나 실행중인 클래스에 권한을 걸어두는 것은 지극히 드문일일 것이다.
(Windchill의 ACL 편집기에선 Domain Class기준으로 ACL을 설정할 수 있다. JPA도 그렇고, 기타 시큐리티 오픈 소스도 그렇고 좋은 사상은 언제나 배껴가고 복사하고 따라가게 되어있다. 모방은 창조의 어머니라고 하지 않았나)


그렇다면 구지 왜? 실행중인 클래스에 자물쇠를 걸어놓고 사용자에 따라서 차등을 두어야 하는 것일까? Role과 URL권한, 메소드 권한까지 모자라서 클래스에 왜? 이와같은 번거로운 작업을 해야하는 것일까?

한가지 시나리오를 상상해 보자.

2010:07:23 08:41:59
Figure 3. 성인과 청소년에 대한 도메인 클래스의 인가처리


ROLE_ADMIN과 ROLE_USER는 성인과 청소년으로 구별되어 있다. index.task 자원과 Document.word자원 또한 모두 통과 가능할 것이다. 하지만, 도메인클래스영역을 보자. 성인은 Adult 클래스를 조작 가능 하지만, 청소년은 Adult 클래스를 조작하지 못하도록 해야한다.
만약에 청소년이 Adult클래스를 조작가능하다면 이 시스템에 접속하는 대부분의 유저들이 나이를 불문하고 성인물을 감상할 수 있을테니까 말이다. 결과적으로 Domain Class에 권한에 따른 설정을 해 두면 별도의 프로그래밍없이 다음과 같은 뷰를 볼 수 있을 것이다.


성인
---------------------------------------------------------------------------------------------------
제목                               분류                        등급                          대여자
---------------------------------------------------------------------------------------------------
구르물섯달버서난..           액션                        일반                         오승택
라스트사무라이                액션                   성인(19)                         오승택
---------------------------------------------------------------------------------------------------


청소년
---------------------------------------------------------------------------------------------------
제목                               분류                        등급                          대여자
---------------------------------------------------------------------------------------------------
구르물섯달버서난..           액션                        일반                         오승택
---------------------------------------------------------------------------------------------------


이처럼 Domain Class에 자물쇠를 걸어두면 세부적인 사항까지 구현할 수 있게 도와줄 뿐만 아니라, 객체분할과 같은 논리적인 영역까지 그 범위를 넓히게 한다. 또한 클래스당 권한을 강제할 수 있기때문에 앞으로 객체지향언어에서 추천되는 인가 방법이라고 할 수 있다.


다음장은 Spring Security의 Domain ACL에 대해서 알아보도록 하자. (언제가 될지 모르겠다.:)

  1. ACL[에이씨엘]은 개개의 사용자들이 디렉토리나 파일과 같은 특정 시스템 개체에 접근할 수 있는 권한을 컴퓨터의 운영체계에 알리기 위해 설정해 놓은 표라고 할 수 있다. 각 개체는 접근제어목록을 식별할 수 있는 보안 속성을 가지며, 그 목록은 접근권한을 가진 각 시스템 사용자들을 위한 엔트리를 가진다. 가장 일반적인 권한은 1개의 파일이나 또는 한 개의 디렉토리 안에 있는 모든 파일들을 읽을 수 있고(Read), 기록할 수 있으며(Write), 그리고 만약 그것이 실행가능한 파일이나 프로그램인 경우라면 실행시킬 수 있는(Execute) 권한 등을 포함한다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.23 21:05 신고 [수정/삭제] [답글]

    음.. 리눅스에도 ACL이 있는데 그걸 웹으로 확장한건가요? 아니면 이름만 같은 별개의 유래를 가진 녀석일려나요?

댓글을 남겨주세요.

Spring Security - OID, SID, ACL

Posted at 2010.07.23 09:37 // in Principle // by MOOVA 무바㏇
2010:07:23 04:04:12
Figure 1은 OODBMS에 포함된 개념에 대해서 열거한 그림이다.


Spring Security의 Domain ACL의 개념은 Security Identity(SID)라고 하는 객체 보안 식별자에 의해서 인가작업을 하기 때문에, SID의 부모격인 OID(Object Identity)가 무엇인지 알아볼 필요가 있다.


OID를 사용하기 시작한것은 OODBMS에 객체를 식별하기 위한 방법으로 종종 사용하곤 했다. 최근엔 ORM Framework에서 종종 볼 수 있는 Object의 Uniq한 식별자라고 말하기도 하는데, Domain Driven Design의 Eric Evans는 Entities를 정의하면서 Object Identity를 다음과 같이 설명한다.


객체 지향 언어의 Object identity조작은, ENTITY의 identity를 정의함에 있어서 다소 미흡한 면이 많다.
데이터베이스로부터 얻은 Object의 id는 java와 같은 랭귀지의 identity와 는 다르다. 데이터베이스로부터 얻은 객체는 영속성이 있는 반면 프로그래밍언어의 identity는 비영속성이라는 점이 다르기 때문이다. 하지만 데이터베이스와 프로그래밍 랭귀지를 굳이 동기화하자면 특별한 key로 랭귀지 객체에 아이디를 부여하는 것이 일반적이다. 그 identity는 불변하며, 변화될 수 없다. ID는 시스템에 의해서 자동으로 작성할 수 있고 다른 Object와 구별할 수 있는 유일한 식별자가 바로 Object Identity이다.


보통 데이터베이스와 프로그래밍 언어의 동기화를 위해 식별자로 사용된 Object Identity는 Evans가 Entities를 설명하기 훨씬 전부터 정의되어 왔고 변화됐다는 것을 다음의 목록에서 확인하자. (1978년도 이전부터 Object Identity라는 용어가 사용되어왔으니, 필자가 태어나기 이전부터 그 가치가 논의되고 있었다는 소리다. 참.. 놀랍고도 위대하다.)


[각주:1]Khashafian, Copeland (1986) - identity는 Object 내부에 있다. 그것의 목적은 독립적인 Object의 특성을 표현하는데 있다.
Atkinson et al. (1990) - 두 Object가 동일한 제 삼의 Object를 참조할 수 있다. 이것은 공유 Object의 개념으로 Object를 업데이트하거나 조작하거나 카피할 때 Object identity로 그 식별을 대신한다.
Kent (1991) - 다양한 관점으로 Object identity에 대해서 논의했다. Object Identity를 비교하는 것이 아니라 그들을 참조하는 Object에 관점을 두었다. 즉 Object의 실제주소값으로 Object Identity를 설명했다.
Beeri (1993) - 그가 논의했던 OID는 현재 사용되고 있는 Object Identity의 원류가 되었다. identity의 경우에는 그것을 검색하는 쿼리에 따라서 식별된다



발전된 MDA를 채택한 벤더 솔루션중 하나인 Windchill이 사용하는 OID를 잠깐 살펴보자. Windchill내부의 ORM 프레임웍으로 새로운 Entity Object를 생성해 데이터베이스에 객체 저장을 했다. ( Windchill의 영속 객체는 JPA나 HIbernate의 생명주기와 비슷한 그것을 가지고 있다. ) 실제 데이터베이스에 접속하여 OID를 추출해 보면 다음과 같은 형태의 Object Identity를 발견할 수 있다.

-----------------------------------------------------------------------------------------------
Oid
-----------------------------------------------------------------------------------------------
com.tistory.moova.Moovie:001
com.tistory.moova.Moovie:002
com.tistory.moova.Moovie:003
com.tistory.moova.Moovie:004
-----------------------------------------------------------------------------------------------


Evans가 논의한 것처럼 데이터베이스의 식별자와 OOP 언어(자바와 같은)의 식별자는 개념상 다르기 때문에, 도메인에 적합한 OID생성규칙을 사용해서 동기화 하고 있다. 실제로 이것은 Object Identity가 아닌 Object identifier라고 하는 직렬화된 식별자이다.

Figure2. ObjectIdentity와 ObjectIdentifier의 관계도

ObjectIdentity도 Object의 일종으로써 실제 구분할 값을 찾기 위해 ObjectIdentifier라는 직렬화된 식별자를 참조의 형태로 포함하고 있다.(OCP원리를 따르면서 SRP원리도 포함하고 있다.). 실제로 "com.tistory.moova.Moovie:004"와 같은 값을 얻기 위해선 다음의 코드가 필요할지 모르겠다.

..
PersistentHelper.store(moovie);
moovie.getObjectIdentifier() : Serializable

JPA는 @Id, @IdClass, @EmbeddedId로 OID를 활용하고 있으며, Windchill은 Persistent를 상속하는 방법으로 OID를 활용하고 있다.

JPA 예
@Entity
public class Inventory implements Serializable {

        @Id[각주:2]
        @GeneratedValue(generator="InvSeq")
        @SequenceGenerator(name="InvSeq",sequenceName="INV_SEQ", allocationSize=5)
        private long id;

Wnidchill 예
public class Inventory extends Persistent {...}

언어와 플렛폼의 차이를 그대로 보여준다. 하지만, 근본적인 사상과 배경은 같다는 것을 알 수 있다.

이 설명으로 Object Identity와 Object Identifier에 대한 개념은 개략적으로 이해할 수 있으리라 본다. Secure Identity(SID)를 설명하기에 앞서 OID를 설명한 이유는 SID와 OID는 바늘과 실과 같은 수족과 같은 관계이기 때문이다.

보안작업을 하려하는 사람을 예로 들어보자.

예를들어 오승택이라는 사람이 주민등록증이 없으면 보안작업을 할 때 필요한 보안인가증도 발급받을 수 없다. 주민등록은 그 사람을 대표하는 ID이기 때문에, 말 그대로 객체 ID가 없으면 보안인가(SID)에서 필요한 신원을 확인할 수 없다.

충분히 이해가 되었으리라 믿는다. 지금까지의 설명은 Spring Security의 Domain ACL을 설명하기 위한 재료물들이다.




참조 문서

In “The Art of the Interpreter or, the Modularity Complex (Parts Zero, One, and Two)” [75] (1978),
• In “Values and Objects in Programming Languages” [56] (1982), Bruce J. MacLennan discusses the distinction between values and objects.
• The paper “Object Identity” [43] (1986) by Setrag N. Khoshafian and George P. Copeland is the most cited one with regard to the topic of object identity, and gives a thorough presentation of the concept and its implementation in programming languages and database systems.
• In “The Object-Oriented Database System Manifesto” [4] (1990), Mal-colm Atkinson et al. list requirements that are to be fulfilled by object-oriented databases. Of course, object identity plays an important role here.
• “A Rigorous Model of Object References, Identity and Existence” [42] (1991) by William Kent describes a model for object identity that, among other things, aims at a facility for merging objects and their identities after the fact.
• Catriel Beeri criticizes a too strong focus on object-oriented features in the context of databases in “Some Thoughts on the Future Evolution of Object-Oriented Database Concepts” [8] (1993), and sketches a re- duction of the concept of object identity to pure value-based properties in relational databases.
• Roel Wieringa and Wiebren de Jonge present a detailed formal model in “Object Identifiers, Keys, and Surrogates – Object Identifiers Re-visited” [85] (1995) that captures the essential properties of object identity and can be interpreted as the common denominator of previ-ous approaches.



 

  1. http://deposit.ddb.de/cgi-bin/dokserv?idn=972868291&dok_var=d1&dok_ext=pdf&filename=972868291.pdf [본문으로]
  2. http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-annotations.html [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

난 모기가 싫다. 그리고 SI

Posted at 2010.07.23 04:40 // in 분류없음 // by MOOVA 무바㏇
과거의 개발자 VS 미래의 개발자 ,
http://moova.tistory.com/entry/인질범이-되고자-하는-모기-심리

다시금 모기에 대해서 이야기해 볼까 한다.
프로젝트 개발 기간 중 자신이 만들어 둔 소프트웨어를 담보로 질질 끌기의 명수가 된 개발자들을 종종 봅니다.

어떻게 하면 조금 일할 수 있나. 어떻게 하면 묻어갈 수 있나 궁리하기 바쁩니다. 이들에겐 책임이라는 것이 없으며 과거에 했던 일을 담보로 앞으로도 인질범으로 묻어갈 것입니다.이러한 인질범이 프로젝트내에서는 미꾸라지가 될 수 있습니다. 미꾸라지가 물을 흐리면 주위 물도 오염되듯이 그런 행동이 시작되면 마치 chain 현상처럼 인질범의 숫자가 높아져 갑니다. 그리고 그 수준이 높아지면 미래에 가치를 둔 개발자들은 바보처럼 변질 됩니다.
(사실을 근거로 한 경험상의 문장입니다.)

위 인용글은 사실을 바탕으로 한 리얼한 문장이다.  저 문장에 몇 가지 양념을 추가한다면 어떻게 될까? 모기도 분류가 가능할까??
자 우리 사랑스런 모기를 분류해 보자.

모기의 분류


2010:07:23 02:54:33

근본모기 : 
근본모기라고 하는 작자이다. 이런 사람들은 뼛속부터 모기다. 남의 피를 이미 주식처럼 먹고 살아나간다. 그러면서 언제 피를 빨았냐는 듯 입을 닦으며 아무렇지 않아 한다. 이미 모기라서 그것에 잘못됐는지 모르고 살아간다. 설상 주변에서 근본모기의 잘못을 지적해도 아랑곳하지 않는다. 왜냐고? 이미 모기기때문에 모기의 행동을 지적한들 그게 잘못이 될까? 보통 이런 모기들은 나일롱모기, 이간질모기, 염탐꾼모기, 시기질모기, 왔다갔다모기가 이에 속한다.


2010:07:23 03:01:06

모기사촌 :
자 다음은 모기사촌이다. 이 사촌들은 근본모기를 모태로 하고 있다. 근본모기가 날라다 주는 맛있는 피를 자신들의 활동없이 그냥 받아만 먹고 사는 이들이 이에 속한다. 그래서 근본모기가 없으면 이 모기사촌도 근절이 된다. 모기사촌의 주특기는 근본모기의 염탐행위를 아무런 생각없이 전달에 전달하는 행위를 하는 책임을 지고 있다. 대게. 무뇌모기, 묻어가기모기, 돼지인데모기,모기등에 업힌 모기,찌질모기가 이에 속한다.

일단 여기까지, 나는 이렇게 여러가지 카테고리로 모기들을 분류해 놓았다.
그러나, 아무리 분류해봤자 생태학적인 관점으로 모기는 역시 모기일 수밖에 없다.
나는 이 태생모기들에 대해서 비판을 하려 하는 게 아니다. 태생모기는 어쩔 수 없이 모기이기 때문에 백날 지적해봤자 모기일뿐이지 않을까?. 하지만 메뚜기에서 모기가 된 사람들은 일말의 가능성은 보인다. 자신은 모기가 아닌데 모기심리가 있어서 모기로 보이는 이들이 그들이다.

모기심리를 갖기 시작하면 평생 모기로밖에 살 수 없다.


이외수님이 쓴 글을 다시한번 들춰볼까?

사대육신이 멀쩡한 사람이 징검다리 없는 개울을 건너면서 발끝에 물 한방울 적시지 않을 생각이라면, 결국 남의 어깨에 업혀가겠다는 속셈인데, 현실적으로 이런 사람들이 점차로 늘어가고 있는 추세다. 죽으면 아마도 기생충으로 다시 태어나지 않을까.

일을 대충 하고 넘어가는 사람들이 있다. 자칫 성격이 쿨해 보일수도 있다. 하지만 쿨은 무슨 뿔 달린 개 민트껌 씹는 소리냐. 결국 마무리나 뒷처리는 남들이 다시 해주어야 하는데. 그는 민트껌때문에 초지일관 남의 고통 따위는 헤아리지 않는 것이다.

걷는 사람도 넘어질때가 있고 뛰는 사람도 넘어질때가 있다. 걷다가 넘어졌든 뛰다가 넘어졌든 넘어졌다고 낙오자는 아니며, 낙오자는 넘어지는 것을 염려해서 한자리에 가만히 앉아 있는 사람이다.

이 세상에 목숨으로 오기 위해서 얼마나 많은 시간을 기다려애 했던가. 그런데 고작 남의 피나 빨면서 살아가는 모기라니, 아무리 많이 죽여도 죄책감을 느낄 수가 없어. 짝!

아.. 정말 내가 하고 싶은 말을 그대로 말해준다. 문장 하나 하나 마다 리얼리티한 만족감을 느낀다.

어느 순간 난 이런 모기 때문에 SI를 떠나겠다고 다짐했었다.  이해해 달라고?? 남이 어떻게 사는지, 또는 어떻게 생활하는지, 또는 어떻게 진행하는지 관심만 있는 이 모기를 어떻게 이해를 해야할까?

그런 모기들의 눈에는 진짜 책임감있는 사람도 한 낮 모기일밖에 보이지 않는 법이다. 그게 보이지 않으면 입을 닫아야 하는데 그게 전부라고 생각하니 입도 못 닥치고 앉아 있는것이다.
남을 깍으려고 작정을 하면 어떤 수를 써서라도 깍으려고 하는 모기..

하지만 똥이 더러워서 피하지 무서워서 피하겠는가? SI를 접고 말고를 떠나서 근본적인 모기의 멸균이 우선 아닐까?
책임감이 강한 사람과 이런 모기와의 간극에는 항상 심리적 충돌이 일어나게 마련이다. 하지만...하지만...

내가 봤을때는 말이지... 비교 자체가 안된다.


그리고 그런 모기의 발언을 듣고 따라가는 모기사촌들. 당장은 편할지 모르겠다. 하지만...결국 말로가 심각하지 않을까?

프로젝트에서 그런 모기들을 제외하고 알게모르게 도와줬던 후배들, 그리고 동료애를 발휘해줬던 사람들에게 감사함을 표한다. 자기 살을 깎아내고 도와줬던 이들이다. 모기와는 근본 자체가 다른 삶을 사는 이들이기도 하다.
난 세상이 이런 사람들로 가득하길 원하고 기원한다. 하지만, 그럴수 없다는 것을 나는 잘 알고 있다.
그래도 기대만큼은 하자. 세상은 신념에 가득찬 사람들로 붐벼간다는 것을..

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://sfamily.tistory.com BlogIcon mcsong

    2010.07.23 10:14 신고 [수정/삭제] [답글]

    너무 공감이 가네요..
    아래에서 책임을 지겠다는데, 위에서는 안된다고 하는 깝깝한 비 SI의 환경도 잇네요.. ㅋㅋ

    • Favicon of http://moova.tistory.com BlogIcon moova

      2010.07.23 15:46 신고 [수정/삭제]

      공감이 가신다니 다행입니다. 다소 혈기가 들어있는 글이라서여 ㅋㅋ
      SI하다보면 깝깝할때가 많은것 같습니다. 이러지도 저러지도 못하는 상황도 종종 찾아오죠. 꼭 기술적뿐만이 아니더라도 정치적으로 더 신경을 곤두세워야 할 때가 많았을 겁니다.. 사람이 중요하고 사람을 콘트롤해야 하다보니 신경쓸게 이만저만이 아니죠. 위에선 전체 부서의 일을 시켰는데 따라오는 사람들이 나 몰라라 하고 앉아 있으면 참.. 한심할때가 많았습니다. 책임감 있는 사람들은 별로 찾아 볼 수 없었구요. 덧글을 보니 책임감이 강하신분 같습니다.^^

  2. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.23 21:30 신고 [수정/삭제] [답글]

    모기는.. 충남 모기가 무섭고..(청바지도 뚫고 물더라구요 ㄱ-)
    아디다스 모기는 전설적으로 무섭죠 ^^;


    머.. 저런분(<=새끼)들에게 흡혈귀라고 하기에는 흡혈귀가 너무 고귀해 보이고
    모기xx라고 하는게 딱 적절해 보이긴해요.

  3. Favicon of http://giznote.tistory.com BlogIcon 사라뽀

    2010.07.24 14:42 신고 [수정/삭제] [답글]

    큭.. 전 '액체형 모기향'을 피우세요!! 라고 말씀드리려고 왔는데-
    액체형 모기향으로는 씨도 안먹힐.. 얘기였네요..
    저도 공감하고 갑니다.. ^^

    (저런 님들 잡는 모기향도. 있음 좋을 것 같죠?ㅋ)

댓글을 남겨주세요.

삑삑이와 해킹 보안

Posted at 2010.07.21 14:49 // in 분류없음 // by MOOVA 무바㏇
해킹할것인가해킹당할것인가(S/W포함)
카테고리 컴퓨터/IT > 대학교재
지은이 유영일 (삼각형프레스, 2000년)
상세보기

해킹과방어완전실무(CD-ROM1장포함)
카테고리 컴퓨터/IT > 네트워크/보안 > 보안/인증/해킹
지은이 조기준 외 (구민사, 2001년)
상세보기

LG CYON | KU9100 | Normal program | Unknown | 2010:07:21 08:35:33

빛바랜 책장에 수년동안 묵묵히 제자리를 차지하고 앉아 있는 케케묵은 이놈들을 발견했다. 책장을 펴보니 더덕 진 물기에 종지들이 녹아, 바스락 바스락 소리가 귀를 즐겁게 만든다.

언제 참고했던 것인가... 기억을 더듬어 본다. 2000년~2001년 사이, 군부대 마크가 찍혀 있는 것을 확인했다. 군시절 보안업무에 참고하고자 사제로 사 둔 책이었는데, 군대 출입허가 관련 때문에 보안 도장이 찍혀 있는 것이다. 군 시절 대부분의 책자는 제대할 때 모두 군대에 놓고 나왔는데 이놈들 만큼만은 집에 고스란히 자리를 차지하고 있었다. ( 휴가때..들고 나왔던가...;;;;

당시 전군은 초소 경계병을 감시할 목적으로 한 가지 전형적인 시스템을 개발했다.

군부대 총기탈환 사건이 발생한지 얼마지나지 않았고 대대적인 국가의 보안 투자였다고 생각한다. 대부분 이때 군생활을 했던 장군들은 단 하나의 편법이라도 용서가 될 수 없었을 만큼 말 그대로 FM시절을 보내야 했고 GOP의 밀어내기식 근무로 말미암아 군생활 대부분은 경계근무를 서야하는 철통과 같은 시절을 보내야 했다. 그때 나온것이 아마도..일명 삑삑이 시스템. 핸디(?)에 의탁한 초소경계병 감사 시스템이다. ( 이 때 군부대 전산 업무는 대부분은 핸디에 의해 점령당하고? 있었다. )
삑삑이 시스템이란 병사와 소대장들이 야간 경계근무를 서기 위해 경계근무를 나갈 때, 일명 "삑삑이"을 들고 초소까지 진입하면, 삑삑이에 몇 초에 몇 시 몇 분.. 이런 식의 이력을 남기어 나중에 전살실에서 통계/집계할 수 있는 휴대용 시스템이었다. 이것만 있으면 제시간에 경계근무를 서는지, 아니면 농땡이를 피우는지 알 수 있다는 윗 선의 노력이었다. 

총기탈환 사건이 터지면서 경계근무 태만의 심각성을 뒤늦게나마 일깨워 이런 불편한 시스템까지 도입해야 한 것이다.


삑삑이 시스템을 3개월간 도입한 후, 별 탈 없이 운용하고 있던 기간中, 어떤 통신병에 의해서 삑삑이 시스템의 비밀이 풀어진다.
시스템의 보안 허점을 이용하여 의도적으로 삑삑이 이력을 수정/보완할 수 있는 편법이 생긴 것이다.
이는 한 통신병의 쾌거였다. 이 발견은 의도와는 반대로 6개월간 편법으로 작용되어 윗선에 가짜보고서를 만들어 내는 악재로 이용당한다.. 그가 원했던 것은 이런 편법 문화가 아니었다. 취약한 점을 발견하고 보완하고 방어하자는 의도였는데 오히려 군간부들은 더 윗선의 눈을 피하기 위하여 그 방법을 오히려 역이용한 것이다. 몇 개월 후 행정병들의 소원수리에 의해서 그 해킹방법은 공개되었다. 물론 통신병과 행정병들의 고백에 의해서 말이다. 그리고 보안에 취약한 그 삑삑이 시스템은 대대적인 패치를 하기에 이르렀다. 이때 전군에 들어간 비용만해도 만만치 않았을 것이다.
(통신병의 하루, 하루는 정말 피곤하다. 새벽엔 매번 대기상태에 있어야 한다. 중대본부의 통신병과는 달리 중대 통신병은 100명중 1명이 발탁 대상이 된다. 1초~22초 통신선로 개편, 작전업무 투입, 상황근무, 경계근무, 혹한기, 유격, 작업,보안,무선통신등... 체력도 체력이거니와 새벽 혼자서 산을 다녀야 하는 담력까지 있어야 한다. 그래서 그리 쉽지만은 않았던 군생활이었다고 생각한다.)


2010:07:21 14:43:26
삑삑이 시스템과 가장 비슷한 편의점의 인식기. 이와 달리 인식기를 들고 초소까지 나가야 한다.


보안업무는 기업이나 국가에 정말 중요한 자산이며, 보안을 소홀히 하면 편법이 되고, 생활화하면 득이 된다라는 진리를 깨우친다.


우리가 사용하고 있는 기업내 보안은 대부분 군부대 보안 업무에서 그 원류를 가지고 있다. 인증,인가,제어목록,권한등.. 로그인이 포함되어 있는 시스템은 알게 모르게 군대보안업무를 따라가고 있는 것이다. 대게 Security System을 군사보안에 비교하는 것도 바로 이와 같은 이유 때문이다.

 

군사업무에서 활용하고 있는 보안업무중에 인증(Authentication), 인가(Authorization) 프로세스가 있다.
비취장에 입장하기 위해선 비밀취급인가증을 인증담당자에게 제시를 해야 한다. 인증담당자는 해당 정작과에 출입요청을 비취자의 신원조사를 한 뒤 출입허용 여부를 확인했고, 비취자의 출입을 허용한다.

비밂문서를 취급하기 위해 인증을 받은 비취자는 다시 한번 인가프로세스를 거쳐야 한다. 비밀문서중에서는 ( 대외비, 군사 보안 1~3 ) 의 분류가 있는데, 각각의 비밀자료를 취급할 수 있는 각각의 인가증서를 필요로 한다. 여기서 인가증서란 비취인가증 특급~3급까지 다양하다. 이 비취인가증의 급수에 따라 레벨에 상이한 비밀취급문서를 다룰 수 있는 권한이 주어진다.



2010:07:21 09:41:37

대부분의 보안 시스템은 군사보안업무에 원류를 두고 있다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. 2010.07.21 18:54 [수정/삭제] [답글]

    비밀댓글입니다

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.07.22 18:09 신고 [수정/삭제]

      헛! 겨울군번이군요. 전 빵빵년 11월 군번 ㅎ
      군대를 조금 늦게 갔었죠. ( 이등병때 제대했던 병장들이
      나랑 나이가 같았으니 ㅋ)
      겨울군번만 보면 동지애를 느낍니다. 들어가자마자 혹한기훈련받죠 아마.:)

  2. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.23 21:30 신고 [수정/삭제] [답글]

    아.. 갑자기 저번에 dog 고생한 바코드 리더의 악몽이 떠오르고 있어요 ㅋ

댓글을 남겨주세요.

[아불류 시불류] 이외수.

Posted at 2010.07.18 13:53 // in Books // by MOOVA 무바㏇
아불류시불류이외수의비상법
카테고리 시/에세이 > 나라별 에세이 > 한국에세이
지은이 이외수 (해냄출판사, 2010년)
상세보기

이외수 작가의 신작 에세이입니다. 병원 도서관에서 빌려봤는데 약 1시간이면 다 읽을 수 있으리라 봅니다.
한 문장에 한 장을 할애했으니 그럴 만도 하겠죠.~~ㅎ

그렇지만 한 문장, 한 문장마다 독특한 공감을 자아내게 해주는 이건 뭥미??

사대육신이 멀쩡한 사람이 징검다리 없는 개울을 건너면서 발끝에 물 한방울 적시지 않을 생각이라면, 결국 남의 어깨에 업혀가겠다는 속셈인데, 현실적으로 이런 사람들이 점차로 늘어가고 있는 추세다. 죽으면 아마도 기생충으로 다시 태어나지 않을까.

일을 대충 하고 넘어가는 사람들이 있다. 자칫 성격이 쿨해 보일수도 있다. 하지만 쿨은 무슨 뿔 달린 개 민트껌 씹는 소리냐. 결국 마무리나 뒷처리는 남들이 다시 해주어야 하는데. 그는 민트껌때문에 초지일관 남의 고통 따위는 헤아리지 않는 것이다.

걷는 사람도 넘어질때가 있고 뛰는 사람도 넘어질때가 있다. 걷다가 넘어졌든 뛰다가 넘어졌든 넘어졌다고 낙오자는 아니며, 낙오자는 넘어지는 것을 염려해서 한자리에 가만히 앉아 있는 사람이다.

이 세상에 목숨으로 오기 위해서 얼마나 많은 시간을 기다려애 했던가. 그런데 고작 남의 피나 빨면서 살아가는 모기라니, 아무리 많이 죽여도 죄책감을 느낄 수가 없어. 짝!


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://love-114.tistory.com BlogIcon 좋은인연(^^*)

    2010.07.20 12:45 신고 [수정/삭제] [답글]

    날씨가 무덥네요(^^*)
    무더위 음식도 조심하시고 강한 햇볕은 더더욱 조심하시고
    건강한 여름 나세요.

댓글을 남겨주세요.

Spring Security - URL 권한을 DB로 관리하기 2.

Posted at 2010.07.18 10:10 // in OpenSource // by MOOVA 무바㏇
필자는 그동안 경험했던 정보나 팁들, 또는 지식을 언제부터인가 온라인보다 오프라인으로 공유하는 것을 즐겨했습니다.
상당수가 프로젝트 보안이 걸려있는 문제이기도 하겠지요, 그 모든 부분을 온라인에 공유할 수 없는 심정, 이루 말할 수 없겠죠?
오픈소스와 관련된 사항도 프로젝트와 연관이 있으면 보안이라는 타이틀이 걸려있습니다. 하지만 공개할 것은 공개하자라는 근본 원칙은 항상 마음속에 간직하고 있습니다.
"버려야 새로운 것을 얻는다." 바로 이 정신. 참 아릅답습니다.~~


그림1. 커스터마이징 할 filterSecurityInterceptor의 인터페이스와 클래스 사용도입니다.


그림2. FilterSecurityInterceptor가 의존하는 두개의 매니저 클래스 ( Authentication Manager, AccessDecision Manager )

FilterSecurityInterceptor는 Spring Security의 중요 필터중 하나입니다. FilterSecurityInterceptor는 AuthenticationManager를 의존하며 User와 관련된 (인증 Authentication) 프로세스를 수행하고, 동시에 수행될 자원에 인가여부를 따지는 AccessDecisionManager를 의존하여 투표를 실시합니다.

<beans:bean id="filterSecurityInterceptor"
class="org.springframework.security.intercept.web.FilterSecurityInterceptor"
autowire="byType">
<custom-filter before="FILTER_SECURITY_INTERCEPTOR" />
<beans:property name="authenticationManager" ref="authenticationManager"></beans:property>
<beans:property name="accessDecisionManager" ref="accessDecisionManager" />
<beans:property name="objectDefinitionSource" >
                    <security:intercept-url pattern="/secure/super/**" access="ROLE_WE_DONT_HAVE"/>
                    <security:intercept-url pattern="/secure/**" access="ROLE_SUPERVISOR,ROLE_TELLER"/>
             </beans:property>
</beans:bean>

FilterSecurityInterceptor의 objectDefinitionSource필드를 커스터마이징 해야합니다. 바로 이 부분이 앞에서 모델링한 테이블과 연동을 해야 할 부분입니다. 위의 objectDefinitionSource를 다음과 같이 바꾸어 줍니다.

<beans:property name="objectDefinitionSource"  ref="coolInvocationDefinitionSource"/>

objectDefinitionsource에 reference될 bean을 등록해야합니다.

<beans:bean id="coolInvocationDefinitionSource"
class="com.moova.secure.filterInvocation.CoolObjectDefinitionSourceFactoryBean">
<beans:property name="dataSource" ref="springSecurityDataSource" />
<beans:property name="resourceQuery"
value="
                                 SELECT URL.URL_SPRING, R.NAME
FROM ROLE ROLE JOIN URL_ROLE UR ON ROLE.ID = UR.ROLE_ID JOIN PROGRAM ON PROGRAM.ID = UR.PROGRAM_ID JOIN URL_REPOSITORY REPO ON PROGRAM.ID = REPO.ID
        " />
</beans:bean>

FilterSecurityInterceptor의 objectDefinitionSource의 API를 살펴보면 다음과 같이 setter injection으로 되어 있는 것을 볼 수 있습니다.

Spring Security 2.0

Spring Security 3.0
 SecurityMetadataSource obtainSecurityMetadataSource() 
           
 void setObjectDefinitionSource(FilterInvocationSecurityMetadataSource newSource) 
          Deprecated. use setSecurityMetadataSource instead
 void setObserveOncePerRequest(boolean observeOncePerRequest) 
           
 void setSecurityMetadataSource(FilterInvocationSecurityMetadataSource newSource) 

Spring Security 2.0 과 3.0 API를 살펴보면 크게 변화된 부분이 바로 이 objectDefinitionSource입니다. 3.0에선 objectDefinitionSource가 deplecated되었습니다. 이것이 securitymetadataSource로 변경이 되어 있네요. 2.0의 objectDefinitionSource의 Type은 FilterInvocationDefinitionSource 이고 3.0의 objectDefinitionSource의 Type은 FilterInvocationSecurityMetadataSourcen 인터페이스입니다.

이를 확인하고 각 버전에 따라 작성해야하는 클래스가 다를 수 있다는 것에 주목해 주십시오. 여기선 그대로 objectDefinitionSource를 사용합니다.

새로 제작할 CoolObjectDefinitionSourceFactoryBean는 FactoryBean을 implements합니다. FactoryBean을 implements 하면 어떤 객체라도 Spring lifecycle안에서 DI할 수 있게 해줍니다. 이는 단순 객체가 아닌 Factory 클래스로써 getObject()와 getObjectType()를 구현해 주기만 하면 새롭게 사용할 클래스를 반환시켜줍니다. 추가로 데이터베이스와 연계가 필요하니  "org.springframework.jdbc.core.support.JdbcDaoSupport"를 상속합니다.

사용할 구조

public class CoolObjectDefinitionSourceFactoryBean extends JdbcDaoSupport implements FactoryBean {
private String resourceQuery;

public boolean isSingleton() {
return true;
}

public Class getObjectType() {
return FilterInvocationDefinitionSource.class;
}

public Object getObject() {
return new DefaultFilterInvocationDefinitionSource(
this.getUrlMatcher(), this.buildRequestMap());
}
}

데이터베이스 연계부분은 MappingSqlQuery을 사용합니다. MappingSqlQuery 사용법은 여기를 참조해 주세요.

private class UrlRepository {
private String url;
private String role;

public UrlRepository(String url, String role) {
this.url = url;
this.role = role;
}

public String getUrl() {
return url;
}

public String getRole() {
return role;
}
}

private class UrlRepositoryMapping extends MappingSqlQuery {
protected UrlRepositoryMapping(DataSource dataSource, String resourceQuery) {
super(dataSource, resourceQuery);
compile();
}

protected Object mapRow(ResultSet rs, int rownum) throws SQLException {
String url = rs.getString(1);
String role = rs.getString(2);
UrlRepository resource = new UrlRepository(url, role);

return resource;
}
}

"com.moova.secure.filterInvocation.CoolFilterInvocationDefinitionSourceFactoryBean"의 원본 파일

더보기




executeResourceMap()메소드에서 URL과 ROLE 관련된 매핑부분을 key와 Value로 조합해야 합니다. 
DefaultFilterInvocationDefinitionSource의 두 번째 인자는 LinkedHashMap입니다. 
당연히 HampMap값을 넘겨주어야 하기 때문에 buildRequestMap에서는 LinkedHashMap를 new해서 반환해 주고 있습니다. 
DefaultFilterInvocationDefinitionSource의 첫 번째 인자는 AntUrlPathMatcher를 new해서 주입하고 있습니다.

스키마를 새로 개정하거나 생성해서 사용해도 무방합니다.
하지만 URL과 Role에 대한 모델링 연관은 그다지 바뀔게 없다고 봅니다.


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

Spring Security - URL 권한을 DB로 관리하기 1.

Posted at 2010.07.18 10:08 // in OpenSource // by MOOVA 무바㏇
필자는 오픈소스나 자/타 제품을 접할 때 먼저 해당 제품의 생명주기(LifeCycle)을 먼저 파악합니다. 서로 연결된 인터페이스나 외부에 공개된 컴포넌트의 연관관계를 파악하고, 자주 사용하는 기능이나 중요하다고 생각되는 기능이 생명주기에 의존되어 있는지를 파악합니다. 전체 생명주기나 구조적 관점을 늘 중요시 하다보면, 치명적인 이슈를 제외한 세부적인 기술이슈까지도  그때 그때 처리할 수 있으리라 봅니다.
<http auto-config='true'>
    <intercept-url pattern="/login.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY" /> 
    <intercept-url pattern="/admin.jsp" access="ROLE_ADMIN" />
    <intercept-url pattern="/**" access="ROLE_USER" />
    <form-login/>
    <logout logout-success-url="/pages/logout-redirect.jsp"
invalidate-session="true" />
    <remember-me key="moovaSecureRMKey" user-service-ref="userDetailsService" />
</http>


Spring Security에서 url path에 대한 권한 부여는 보통 위와 같이 설정을 해야합니다. (굵게 표기한 부분)
( 권한을 가지고 있는 사용자가 요청한 url 패턴을 기준으로, 해당 자원을 접속할 수 있는지를 따지게 하여 주는 설정입니다. ) 하지만 안타깝게도 보통 실무에서는, url path나 문서 조회권한에 관련된 설정 파일은 따로 관리하지 않습니다. 

User,Member,Group등 중요 인증 및 인가에 관련된 테이블을 데이터베이스로 관리한다면 URL 권한도 데이터베이스로 관리되어야 차 후 유지보수나 확장에도 이점을 얻을 수 있습니다. Spring Security에선 위의 intercept-url설정이 기본기능으로 구성되어 있습니다만, 이것을 데이터베이스로의 관리방법으로 변경해 보도록 할까 합니다.

하고자 하는것은 매우 단순합니다. Spring Security의 중요 Filter중 하나인 FilterSecurityInterceptor의 objectDefinitionSource를 커스터마이징 할 objectDefinitionSource로 바꿔치기하는 것입니다.



1. 테이블 구축


그림1. 실제 실무에서 사용된 인증/인가와 관련된 테이블 ( 축소공개형 ) 



실제 Magpie 오픈소스로 구축중인 테이블 스키마의 축소 일부입니다. 
User와 Role N:N관계, Role과 Program도 N:N관계, Program과 Url_Repository는 1:1관계로 되어 있습니다.
Role과 Url_Repository를 N:N관계로 모델링 해도 무방하지만 보통 URL은 동적인 속성이 강한 부분이니 카테고리로 분류할 수 있는 Program이란 Entity를 따로 생성하여 url port같은 기능을 하도록 설정해 두었습니다.

사용해둘 데이터를 미리 뽑아 보고, 기존 설정에서 사용했던 포멧으로 데이터가 축출 가능한지 확인합니다.


그림 2. 기존 Spring Definition 설정 위치와 비교한 데이터의 위치.

2. 데이터 확인 및 데이터 추출
SELECT URL.URL_SPRING, R.NAME FROM ROLE ROLE JOIN URL_ROLE UR ON ROLE.ID = UR.ROLE_ID JOIN PROGRAM ON PROGRAM.ID = UR.PROGRAM_ID JOIN URL_REPOSITORY REPO ON PROGRAM.ID = REPO.ID RESULT : ROLE_USER | /** ROLE_ANONYMOUSLY | /** ROLE_ADMIN | /admin.jsp ROLE_USER | /login.jsp ROLE_ANONYMOUSLY | /login.jsp ROLE_MANAGER | /manager/index.jsp
"Spring Security URL 권한을 DB로 관리하기"에서 사전 준비해야 할 재료는 모두 준비된 상태입니다. 이제 Spring Security의 일부분을 커스터마이징해야 합니다. ( "org.springframework.security.intercept.web.FilterSecurityInterceptor" )

참고 문서 :  
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/springsecurity.pdf

저작자 표시 비영리 변경 금지
신고

'OpenSource' 카테고리의 다른 글

근무환경  (2) 2010.08.10
Spring Security - URL 권한을 DB로 관리하기 2.  (0) 2010.07.18
Spring Security - URL 권한을 DB로 관리하기 1.  (0) 2010.07.18
심심풀이 납품용  (2) 2010.06.05
[Guide] Vaadin Korean Guide (ver01)  (3) 2010.05.11
[Share Document Note] Evernote  (0) 2010.01.24
블로그코리아에 블UP하기

댓글을 남겨주세요.

2010년 7월 16일, 미투데이

Posted at 2010.07.17 18:31 // in SNS // by MOOVA 무바㏇

이 글은 moova님의 2010년 7월 16일의 미투데이 내용입니다.

신고

'SNS' 카테고리의 다른 글

2010년 7월 25일, 미투데이  (4) 2010.07.25
2010년 7월 23일, 미투데이  (0) 2010.07.23
2010년 7월 16일, 미투데이  (0) 2010.07.17
2010년 7월 16일, 미투데이  (4) 2010.07.16
2010년 6월 29일, 미투데이  (4) 2010.06.29
moova의 미투데이 - 2010년 1월 19일  (0) 2010.01.19
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바