태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Cassandra GUI Client 프로그램을 찾던중에 괜찮은 녀석을 발견해서 올려봅니다.

Java 기반이고 war를 tomcat의 webapp 디렉토리에 넣어주기만 하면 됩니다.

처음실행시

Cassrandra Host , Thrift Port (보통 9160) , JMX port 를 입력해주시면 접속이 됩니다.

왼쪽의 Configuration 메뉴에서도 변경 가능하구요.



다운로드 페이지
http://github.com/suguru/cassandra-webconsole



소개하는 블로그
http://nosql.mypopescu.com/post/611576467/cassandra-web-console



스크린샷











Posted by Breeze.Kang

댓글을 달아 주세요

요즘 취업하기가 참 어렵다고 합니다.

신입은 물론이고 경력직까지 뽑는데도 별로 없는 상황인데요.

이럴때일수록 급하다고 아무 회사나 덜컥 들어가는 경우가 많은것 같습니다.

절박한 심정이야 이해를 못하는 것은 아닙니다만, 한번 입사를 하면 평생동안 자신의 경력에 포함이 되는 선택이므로 신중에 신중을 기해야 합니다.

특히 신입들은 첫 직장이 매우 중요합니다.

그것은 개발이든 다른 직종이든 마찬가지입니다.

경험이 부족하기 때문에 회사를 고르는 기준이 없거나 판단을 잘 못하기도 합니다.

그런분들을 위하여 몇가지 조심해야 할 회사 유형을 적어봅니다.



1. 자주 구인 광고를 내는 회사

회사가 발전하여 직원이 늘어나는 경우에는 문제가 아닙니다만, 매출이 늘거나 발전하는 것 같지는 않은 회사인데, 취업 사이트를 보면 거의 맨날 구인중이라는 공고가 올라오는 회사들이 있습니다.
이런 회사는 십중 팔구는 비전을 찾기가 힘들고 박봉에 야근으로 부려먹고 직원들이 입사후 얼마후에 관두는 경우가 많은 즉 이직율이 높은 회사일 확율이 높습니다.
좋은 대우를 해주고 비전이 있는 회사인데 그만두는 사람이 많을리는 없겠죠.


2. 개발자가 아닌 사람이 1차 면접을 보는 회사

개발팀장이나 개발 직군을 가진 사람이 아닌 사람이 개발자의 1차 면접을 보는 회사가 있습니다.

이런 회사들은 대부분 개발조직이 힘이 없거나 개발 조직은 상당히 하위 조직으로 포지셔닝된 회사입니다.
대부분 말도 안되는 일정의 쪼임을 당하거나 퀄리티 보다는 단순 반복 노가다를 반복하여 발전할 기회가 없는 회사일 가능성이 높습니다.



3. 기술력보다는 회사 규모나 인맥을 강조하는 회사

우리회사는 매출이 얼마,  정부 기관과 연줄이 있고.. 등등.
면접때 회사의 규모나 인맥을 강조하는 회사들이 있습니다.
이런 회사는 R&D에 대한 투자보다는 영업비를 더 많이 쓰는 , 그러다가 연줄이 끊기면 회사가 문을 닫아야 하는 경우가 발생할 확률이 높은 회사입니다.


4. 인력 파견 회사

첫직장 만큼은 단기 프로젝트로 인력 파견을 하는 회사는 피하라고 말씀드리고 싶습니다.

인력 파견 회사는 말그대로 소모품입니다.  인력 파견회사들이 신입을 잘 쓰지도 않지만 첫 직장 만큼은 자체 서비스를 하는 회사나 자체 솔루션을 개발하는, 스스로 발전할 수 있는 회사를 선택하라고 조언드리고 싶네요.




기타 여러가지 유형이 있고 상황마다 다르겠지만 제가 그동안 봐온 피해야할 회사들의 유형을 정리해보았습니다.

부디 신중하게 좋은 결정들 하시기 바랍니다.






Posted by Breeze.Kang

댓글을 달아 주세요

Setting up cron jobs in Unix and Solaris

cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are often termed as cron jobs in unix , solaris.  Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.

This document covers following aspects of Unix cron jobs
1. Crontab Restrictions
2. Crontab Commands
3. Crontab file – syntax
4. Crontab Example
5. Crontab Environment
6. Disable Email
7. Generate log file for crontab activity

1. Crontab Restrictions
You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file /usr/lib/cron/cron.deny.
If only cron.deny exists and is empty, all users can use crontab. If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.

2. Crontab Commands

export EDITOR=vi ;to specify a editor to open crontab file.

crontab -e    Edit your crontab file, or create one if it doesn’t already exist.
crontab -l      Display your crontab file.
crontab -r      Remove your crontab file.
crontab -v      Display the last time you edited your crontab file. (This option is only available on a few systems.)

3. Crontab file
Crontab syntax :
A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.

*     *     *   *    *        command to be executed
-     -    -   -  -
|     |     |   |    |
|     |     |   |    +----- day of week (0 - 6) (Sunday=0)
|     |     |   +------- month (1 - 12)
|     |     +--------- day of month (1 - 31)
|     +----------- hour (0 - 23)
+------------- min (0 - 59)

* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).
Notes
A. ) Repeat pattern like /2 for every 2 minutes or /10 for every 10 minutes is not supported by all operating systems. If you try to use it and crontab complains it is probably not supported.

B.) The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed .

4. Crontab Example
A line in crontab file like below removes the tmp files from /home/someuser/tmp each day at 6:30 PM.

30     18     *     *     *         rm /home/someuser/tmp/*

Changing the parameter values as below will cause this command to run at different time schedule below :

min hour day/month month day/week Execution time
30 0 1 1,6,12 * – 00:30 Hrs  on 1st of Jan, June & Dec.

0 20 * 10 1-5 –8.00 PM every weekday (Mon-Fri) only in Oct.

0 0 1,10,15 * * – midnight on 1st ,10th & 15th of month

5,10 0 10 * 1 – At 12.05,12.10 every Monday & on 10th of every month
:

Note : If you inadvertently enter the crontab command with no argument(s), do not attempt to get out with Control-d. This removes all entries in your crontab file. Instead, exit with Control-c.

5. Crontab Environment
cron invokes the command from the user’s HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:
HOME=user’s-home-directory
LOGNAME=user’s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh

Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry.

6. Disable Email
By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line .

>/dev/null 2>&1

7. Generate log file
To collect the cron execution execution log in a file :

30 18 * * * rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log

Posted by Breeze.Kang

댓글을 달아 주세요

이 글은  Beginner’s Guide to OAuth – Part III : Security Architecture 를 한글로 의역 번역한 글입니다.

http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-architecture/


내가 보기 위하여 번역을 해 두었지만 다른 분들도 같이 보면 좋을것 같아서 블로그에 올립니다.

잘못된 번역이나 수정할 내용이 있으면 알려주시면 감사하겠습니다.





Beyond Basic


HTTP는 많은 사이트와 API에서 사용하는 Basic한 인증 방법만을 정의한다 -  Basic한 인증 방법이란 사용자 아이디와 패스워드를 입력 받아서 인증을 처리하는 방식을 말한다.

Basic한 방법은 사용자 이름과 패스워드를 매 request 마다 plain text로 전송하여 동작한다.

HTTPS로 전송하지 않는 경우 이런 Basic한 방식은 중요한 보안적 결함을 가지게 되는데 여기서 우리는 세가지 점에 촛점을 맞추고자 한다.

첫번째는 전송되는 암호화 하지 않은 패스워드를 capture하여 재사용될 가능성이 있다는 점이다.

두번째는 자격증명서가 request에 연결되지 않는 다는 점인데 , 이것은 일단 한번 자격을 얻게 되면 어떤 request건 제약없이 사용을 할 수 있다는 의미이다.

세 번째는 Basic방식은 자격증명을 위임하기 위한 Placeholder를 제공하지 않고 오직 하나의 사용자 아이디, 패스워드의 쌍만을 지원한다는 점이다.

Consumer(Caller)의 자격증명과 User의 자격증명(Consumer access의 집합)을 동시에 전송하기 위하여서는 위임이 필수적이다.


OAuth 아키텍처는 이러한 세가지 제약사항에 주목하고 있다.


OAuth 의 signature method는 기본적으로 안전하지 않은 전송방식 - Non Https - 으로 설계되었다.  MITM(man-in-the-middle attack) 같은 도청이나 다른 security risk를 막기 위하여서는 HTTPS가 좋은 솔루션이다.

그러나 HTTPS는 setup이나 유지보수 측면에서 매우 비싼 솔루션이다.

OAuth가 HTTPS위에 사용될때 대부분의 security에 대한 요구사항을 HTTPS에 맡기고 PLAINTEXT 방식이라는 훨씬 효율적이고  단순한 방법을 제공할수 있다.

물론 안전하지 않은 채널에서 PLAINTEXT방식을 사용하지 말아야 한다.

이 강의는 안전하지 않은 채널상에서 작업하기위한  HMAC-SHA1과 RSA-SHA1 에 좀더 집중하겠다.



Direct & Delegated Access

OAuth 의 명백한 목적은 Authorization Delegation Protocol(인증된 위임 프로토콜) 이다.

하나의 집단이 다른 사람의 리소스에 접근하기 위한 허가를 받는 것이 OAuth 프로토콜의 핵심이다.

이러한 위임 access 시나리오는 또한 3 - legged 시나리오로 알려져 있는데 Service Provider와 Consumer, 그리고 사용자 3자가 관련되어있다.

Consumer에 의하여서만 request가 생성되기 때문에 Service Provider를 스스로 인증하는 방법이 필요하지만 User data에 접근하는 데이터가 필요하게 된다. 이것은 OAuth가 HTTP 상에서 두개 셋의 자격조건을 지원해야 하는 요구사항이 된다.


OAuth는 2 legged 시나리오로 알려진 직접 접근 시나리오 에서도 동일하게 잘 동작한다.

이것은 대부분의 사람들이 친숙한  사용자이름과 패스워드로 로그인하는 인증방식이다. 이 시나리오에서는 다른 누구도 개입하지 않고 접근도 위임되지 않는다. Consumer는 리소스에 직접 접근하게 되고 Consumer와 User는 같은 Entity가 된다.


이것은 Consumer가 User측의 3-legged request와 Consumer측의 2-legged request를 각각 동시에 전송할때 약간의 혼란을 줄 수 있다.

Signature WorkFlow를 생각해 보면 각각의 자격증명이 무엇을 얻기 위하여 설계되었는지를 이해하는데 도움이 될 것이다.

Consumer의 자격증명은 request를 일으키는 집단을 인증하기 위한 것이기 때문에 만일 각 집단이 스스로 request를 만든다고 하더라도 그것은 end-user의 request 이기도 할것이기 때문이다. HTTP basic의 대안으로 OAuth를 사용하기를 원하는 application은  Consumer Key 와 Consumer Secret을  사용자 아이디와 패스워드대신 가지고 있어야만 하고, Token과 Token Secret을 비워둬야만 한다. 이것은 물론 직접적인 application 지원이 필요하다.


이 가이드는 인증을 위임하는 OAuth의 기본적인 use case에 집중하기 때문에 ,  이 강의의 나머지 부분은 3-legged 시나리오에 더 살펴볼 것이다.


Credentials

매일 매일의 web 트랜잭션에서 가장 일반적인 자격증명은 사용자이름과 패스워드 조합이 사용되는 것이다.

OAuth의 기본적인 목적은 개인적인 리소스에 대하여 접근을 위임하도록 허락하는 것이다.

이것은 두셋의 자격증명으로 이루어진다.

Consumer identities은 Consumer Key와 Consumer Secret이고

User identities은 Token과 Token secret 이 그것이다.

각각의 셋은 사용자이름과 패스워드의 쌍과 동일하게 생각하면 된다. Consumer의 경우는 application의 경우와 동일하고 User의 경우는 end-user의 경우와 동일하기 때문이다.

Consumer의 자격증명이 더 사용자 이름 패스워드 인증 방식과 유사한데 User의 경우는 실제 사용자 이름과 패스워드와는 다른 Token으로 표현되기 때문이다. 이것은 Service Provider와 User가 Consumer의 접근을 허용함에 있어서 더 좋은 제어와 유연성을 가지게 해준다.

예를 들면 User는 패스워드의 변경없이도 Token을 폐지하여 다른 application에서의 접근을 막을 수 있다.

User의 사용자이름, 패스워드와 Token과의 Decoupling은 OAuth 아키텍처의 중요한 요소중의 하나이다.


OAuth는 두개의 중요한 Token을 포함하는데 이것은 Request Token과 Access Token이다.

각각은 OAuth의 위임 workflow에서 특정한 역할을 담당하고 있다.

OAuth specification이 진화하는 동안 이 2 Token 설계는 specification에 머물러 있던 것들을 살제 가치있는 사용성과 보안적 기능으로 바꾸는 역할을 하게 되었다. OAuth의 두개의 채널로 동작한다. 하나는 Front Channel이고 이것은 User와 인증 request를 연관짓기 위하여 사용되고, Back Channel은 Consumer에 의하여 Service Provider와 직접적으로 상호동작하기 위하여 사용되어진다. Access Token을 back channel로 제한함으로써 Token은 User를 은닉할수 있게 된다. 이것은 Access Token이 특별한 의미를 전달할 수 있도록 해주고, 인증을 요청하거나 Mobile이나 셋톱 박스 같이 수동으로 입력 해야 해서 User에게 노출되는 front channel 의 Request Token보다 더 큰 사이즈를 가지게 해준다.


request signing workflow는 모든 Token을 동일하게 처리하고 workflow 역시 동일하다. 두개의 Token은 Token들을 동일하게 사용하는 signature workflow가 아닌 인증 Workflow를 명시 하고 있다. 이것은 두개의 Token Type이 서로 대체할수 있음을 의미하는 것이 아니라, signing request시에 동일한 보안 기능을 제공함을 의미한다.


Signature and Hash


OAuth는 각 request 마다 패스워드 같은 전체 자격증명을 보내는 것 대신 Digital signatures 를 사용한다.

사람들이 특정 문서에 사인을 하는것으로 자신의 동의를 표현하는 것과 유사한 방식으로 Digital Signature는 요청을 받는 쪽에서 request의 content가 전송시에 변경되지 않았음을 확인할수 있게 한다. sender는 request의 수학적 알고리즘으로 구현된 signature를 계산하고 request에 그것을 포함시킨다.


반면 받는 쪽에서는 똑같은 workflow로 request의 signature를 계산하고 제공된 signature value와 비교한다. 만일 두개가 동일하면 전송중에 request가 변조되지 않았음을 확신(Confidence)하게  된다. 확신레벨 (Confidence level) 은 signature 알고리즘이 강력한 것인지 아닌지에 따라서 다르게 된다.

이 매커니즘은 양쪽에서 모두 똑같은 Signature 알고리즘과 과 똑같은 방식으로 적용되어야만 한다.


일반적인 디지털 콘텐츠를 Sign하는 방식은 Hash 알고리즘을 사용한다.

일반적으로 Hashing은 데이터를 받는 과정과 재현 가능한 방식으로 훨씬 작은 값으로 압축하는 과정으로 되어있다.

이것은 똑같은 Hash 알고리즘을 이용하면 똑같은 데이터는 항상 같은 값이 나오는 것을 의미한다. 원본 비압축 데이터를 보존하는 것이 목적인 압축과는 달리 Hashing은 작은 값에서 원래의 값으로 돌리는 것을 허용하지 않는다.


예를 들면 콘텐츠 길이에 상관없이 hash의 결과 값의 길이는 항상 일정하다.


이것 때문에 Hashing은 sender의 identity를 보증하지는 못한다. 오직 데이터의 무결점만을 보증할 뿐이다.

받는쪽에서 request가 인증된 sender에게서 온것이라는 것을 확인하기 위하여서는 hash 알고리즘은 shared Secret과 연관되어야 한다.

양 쪽 모두가 어떤 Shared Secret에 동의하였고 양쪽만 알고 있다면 그것을 콘텐츠에 붙여서 Hashing 할수 있다. 이것은 단순하게 이 비밀코드를 콘텐츠에 붙이는 것으로 완료될수도 있고 HMAC 같은 더 복잡한 알고리즘을 이용 할 수도 있다. Signature를 생성 하고 인증 할때는  request를 위조하고 수정하는 attack을 막기 위하여서는 양쪽모두 Shared secret에 접근하기 위한 권한이 필요하다.


HTTP Basic 인증 방식과 비교하여 이 방식의 장점은 실질적인 secret은 결코 request와 함께 전송되지 않는 다는 점이다.

secret은 request를 sign하는데만 사용되어지고 실제 그것의 일부분은 아니기 때문에 (제대로 구현이 되어있다면) 추출되어 질수 없다.

Signature는 안전하지 않은 channel을 통하여 Shared secret을 request와 함께 전송하는 것보다 같은 기능을 하지만 더 안전한  방식이다.


Secrets Limitations

OAuth 에서 Shared secret은 사용되는 Signature 방법에 의존적이다.

PLAINTEXT 와 HMAC-SHA1 방식에서는 shared secret은 Consumer Secret과 Token Secret의 조합이다.

RSA-SHA1 방식에서는 Consumer Private Key가 request를 sign할때 배타적으로 사용되고 비대칭 shared secret (Asymmetric shared secret) 으로 제공된다. 비대칭 키 페어는 Consumer와 Service provider 각 side에서 request를 sign할때 하나의 키를 사용하고 reqeust를 인증할때 또다른 키를 사용한다. Consumer를 위한 private Key와 Service Provider를 위한 Public Key는 반드시 일치해야 하고, 올바른 쌍의 경우에만 성공적으로 request를 sign하고 인증할 수 있다. Asymmetric shared secrets을 사용할때의 장점은 Service Provider가 Consumer의 Private Key를 가지고 있지 않아도 되므로 secret이 외부에 유출될때 발생할 수 있는 위험요소를 줄여줄 수 있다.


그러나, RSA-SHA1 방식이 Token Secret을 사용하지 않기 때문에 , Private Key는 공격을 막기 위한 유일한 방식 이고, 한번 뚫리게 되면 모든 Token이 위험할수 있다.


OAuth 를 구현할때 대칭과 비대칭의 shared secrets의 제한사항을 이해 하는 것은 매우 중요하다.

Consumer secret (혹은 Private Key)은 Service Provider에 의하여 Consumer의 identity를 인증할때 사용된다. 웹서버 같은  web 기반의 Consumer의 경우 상대적으로 Consumer secret(Private Key)을 안전하게 유지하기가 쉽다. 반면 Consumer가 데스크탑 어플리케이션이나 모바일 어플리케이션 혹은 브라우저 어플리케이션 (Flash, java, silverlight , javascript 같은) 같은 client 소프트웨어라면 라면 Consumer의 자격증명은 각 application의 copy마다 포함되어야 한다. 이것은 Consumer secret (Private Key)가 application과 함께 배포 되어야 하고 이것은 상속적으로 그것들과 협의되어야 한다.(?)


이것이 그러한 application에서 OAuth의 사용을 막는것은 아니지만, 이러한 Public한 Secret을 가질수 있는 Service Provider에 대한 신뢰도에 대한 제약사항 가져다 준다. secret이 신뢰되어 질수 없기 때문에 Service Provider는 그러한 application을 알수 있는 엔티티로 간주하고 Consumer Identity를 어떤 level의 trust도 필요없는 행위 (application의 상태를 수집한다 던가 하는..) 로 제약한다.  어떤 Serivce Provider는 이러한 어플리케이션을 거부할수도 있고 다른 protocol이나 확장을 제공 할수도 있다. 그러나 지금 시점에서 이러한 제약 사항에 대하여 간단한 솔루션은 없는 상황이다.


Consumer에 대한 자격증명이 이러한 application에서의 취약함에도 불구하고 User의 자격증명(Token and Secret)이 보안 속성을 방어하는 각 Consumer 의 instance에 매우 specific하다는 것은 중요한 점이다. 물론 이것은 Consumer의 구현과 Token정보를 client 측에서 어떻게 저장하느냐에 따라서 의존적이다.


Consumer 자격증명으로 Token과 Token secret이 없고 단지 사용자 아이디와 패스워드를 사용하기 때문에 2-legged 시나리오와는 다르다.

HTTP Basic을 직접적으로 교체하는 방식으로 OAuth를 사용하게 되면 Consumer와 User는 같은 Entity이고, application은 즉각 User를 그들의 자격증명으로 집어넣을수 있다. 따라서 application자체에 그것을 하드코드 하는 것을 제거 할수 있다.  단순한 Sign-in을 위한 OAuth를 사용하는 것은 HTTP Basic과 동일한 사용자 경험을 줄수 있지만 안전하지 않은 Channel에서의 OAuth 사용은 훨씬 더 많은 안전성을 제공할수 있다.


Timestamp and Nonce

Signature와 Shared secret은 어느정도의 security level을 제공하고 있지만 여전히 공격으로 부터 안전하지 못하다.

Signature가 request의 conent 변조를 막고, shared secret이 권한이 있는 Consumer 로 부터의 request인지를  구분해 낸다.

Sniffing the network로 불리우는 권한이 없는 Party로 부터의 request를 가로채서 재사용하는 부분을 막기 위한 부분이 빠져있다. 이것은 replay attack으로 알려져 있는데, shared secret이 보호되어진 상태로 있는한 네트웍상에 있는 어느 누구도 새로운 request를 변조할수 없다. 그렇지만 똑같은 sign을 이용하여 같은 request를 반복하여 보낼수는 있다.

만일 가로챈 request가 민감한 보호된 데이터를 access 하도록 제공되어진 것이라면 이것은 커다른 security risk 이다.

request를 재사용하는 replay를 막기 위하여 OAuth는 nonce와 Timestamp를 사용한다.

nonce는 한번 사용되는 숫자를 의미하고, 각 sign된 request를 유니크하게 구분하는 유니하고 랜덤하게 생성된 스트링을 의미한다.

각 request는 unique한 identifier를 가짐으로 인하여 Service Provider는 request가 한번 이상 사용되는 것을 막을 수 있다. 이것은 Consumer가 각 request를 Service Provier에게 보낼때 유니크한 스트링을 생성해야 함을 의미한다. 그리고 Service Provider는 모든 nonce를 트래킹하여 두번 이상 사용되도록 막아야 한다는 것을 또한 의미한다. nonce는 Signature에 포함되기 때문에 shared secet에 대하여 알지 못하는 attacker에 의하여 변조될수 없다.


nonce를 사용하는것은 Service Provider의 입장에서는 매우 cost가 드는 일이다. 왜냐하면 받은 nonce를 스트리지에 저장하는 것이 필요하기 때문이다.

이를 더 쉽게 구현하기 위하여 OAuth는 timestamp를 각 request마다 덧붙여서 Service Provider가 일정시간동안만 nonce를 저장하도록 하고 있다.

일정 시간보다 오래된 timestamp를 가진 request가 들어오는 경우 Service Provider에 의하여 거부되고 저장할 필요가 없는 것이다. 허용된 일정 시간 이후에 들어오는 request를 replay로 간주하는 것이 안전 하기 때문이다. OAuth는 timestamp를 구현하기 위한 general mechanism을 제공하지만 실제 구현은 각 Service Provider에게 맡겨두고 있다. 보안 관점에서 실제 nonce는 timestamp값과 nonce 스트링 값과의 조합이다. 이 조합만이 유일한 값을 제공할수 있고 attacker에 의하여 재사용되는 것을 막을 수 있다.


Signature Methods

OAuth는 request를 sign하고 verify하는 3가지의 Signature 방법( PLAINTEXT, HMAC-SHA1,  RSA-SHA1)을 정의하고 있다.

PLAINTEXT는 자격증명을 encrypt하지 않는 HTTP BASIC 방식과 유사한 방식으로  HTTPS 상에서 동작하고자 의도된 것이다.

Basic 과는 달리 PLAINTEXT는 위임(Delegataion)을 지원한다. 다른 두가지 방식은 SHA1 해쉬 방식과 결합된 HMAC와 RSA Signature 알고리즘을 사용한다.

이 방식은 이 가이드에서 설명하기는 너무 복잡해서 설명을 하지는 않겠다. 그리고 이 알고리즘에 대한 가이드를 읽기전에는 직접 구현을 하기 보다 믿을만한 오픈 소스를 사용하는 것이 좋을것이다.


request를 sign할때, 어떤 singature 방식을 사용하여 request를 받는 쪽에서 인증을 위해 signature 재생산을 할 수 있는지를 명시해야 한다.

어떤 signature방식을 사용할지는 각 application에서 어떤 보안 요구 사항이 있는지에 따라서 다르다. 각각방식은 장점과 제한사항이 존재한다.

PLAINTEXT는 사용하기가 쉽고, 계산에 시간이 적게 걸린다. 그렇지만 오직 HTTPS나 비슷한 보안 channel에서만 안전하다.

HMAC-SHA1 은 대부분의 플랫폼에 적용가능한 단순하고 일반적인 알고리즘을 제공한다. 그러나 legacy device와 symmetric shared secret을 사용하는 모든곳에서는 사용할 수 없다.

RSA-SHA1 은 key-pairs를 사용하여 한층 강화된 보안을 제공한다. 그렇지만 더 복잡하고 키 생성이 필요하고 긴 학습곡선(?)이 필요하다.



Signature Base String


위의 예에서 살펴 봤듯이 양쪽 side에서는 똑같은 결과를 얻기 위하여 동일한 signature process를 행해야만 한다.

똑같은 알고리즘, share secret을 사용할 뿐만 아니라 같은 content를 사용해야 한다.

이것은 HTTP request를 signed content에 사용되는 하나의 string(Signature base string)으로 converting하는 일관된 방법이 필요하다.

이 base string을 만들기 위하여 많은 개발자가 specification에 노력을 했다.

다음 챕터에서 이 Signature base string을 만드는 것에 대한 예제를 제공한다.

Posted by Breeze.Kang

댓글을 달아 주세요

이 글은  Beginner’s Guide to OAuth – Part II : Protocol Workflow 의 주요 내용을 한글로 번역, 의역하여 초보자도 알기 쉽게 설명한 글 입니다.

사실은 저를 위한 정리입니다만, 같이 보면 좋을것 같아서 블로그에 올립니다.



OAuth의 흐름에 대하여 실제 예를 들어서 설명해 보고자 한다.

Flow Step 1

제인은 2주간의 스코트랜드 휴가를 다녀왔다.
그녀가 집에 돌아왔을때 그녀의 친구들과 휴가 사진을 공유하고 싶어졌다.
그녀는 사진 공유를 위하여 Faji.com 을 사용하고 있어서 비공개 상태로 2장의 사진을 업로드 했다.


OAuth의 개념으로 , 제인은 User 이고, Faji 인 Service Provider 이다. 업로드된 2개의 사진은 Protected Resources 이다.

Flow Screen 1

몇몇의 친구들과 사진을 공유한 그녀는 할머니에게도 사진을 공유하고 싶어졌다.

그렇지만 할머니는 인터넷을 사용하지 않으시기 때문에 온라인 사진인화 서비스를 이용하여 인화후에 우편으로 사진을 보내려고 한다. 온라인 사진 인화 사이트로는 Beppa를 사용하고 있다.



OAuth의 개념으로 Beppa는 Consumer이다.  왜냐하면 제인은 사진을 비공개로 설정해놓았기 때문에 Beppa는 사진인화를 위하여 그 사진들에 대한 access 권한을 얻기 위하여 OAuth를 사용해야 하기 때문이다.

제인은 Beppa.com을 방문하여 사진 주문을 시작하였다. Beppa는 다른 사진 사이트들로부터의 import를 지원하고 있고 제인은 Faji를 선택 하고 계속 버튼을 클릭하였다.


Flow Screen 2

Beppa.com에서 Faji 의 사진을 import 하는 기능을 support 하기 위하여서는 Beppa 개발자 - OAuth개념에서 Consumer Developer - 는 Consumer Key와 Consumer Secret 을 Faji로 부터 받아야만 Faji의 OAuth API를 사용할 수 있다.


제인이 계속 버튼을 클릭한순간 background에서는 중요한 일이 발생한다.

Beppa는 Faji로 request token을 전송한다. 이 Request Token은 사용자별로 생성되는 것은 아니기 때문에 제인의 비공개 사진에 접근하기 위하여서는 그녀(User)의 허락을 얻어야만 한다.


Flow Step 2

제인이 계속 버튼을 클릭하고 화면이 바뀌길 기다리고 있다.


Beppa가 Request Token을 받게 되면 Beppa는 Request Token과 함께 Faji의 OAuth 사용자 인증 URL로 redirect를 한다. 물론 이때 제인이 동의를 하게 되면 http://beppa.com/order 페이지로 다시 돌아오도록 요청한다.

제인이 Faji로 redirect 되면 로그인을 요청받게 된다. OAuth는 Service Provider의 User 인증을 먼저 요청하고 그 후에 Consumer에게 access권한을 요청하기 때문이다.

제인은 브라우저의 URL을 보고 Faji 페이지로 왔다는 것을 인지하고 그녀의 아이디와 패스워드를 입력한다.



Flow Screen 3

OAuth는 그녀의 아이디와 패스워드를 Beppa나 다른 사이트와는 공유하지 않도록 해주며,  그녀의 개인적인 정보를 beppa.com에 입력할 필요가 없게 해준다.

Faji에 성공적으로 로그인한 후에 , Consumer인 Beppa에서 접근할 수 있도록 허가 해 줄것을 요청받는다. 
Faji는 제인에게 Beppa가 접근할 것을 요청하였다는 것을 알려주고,  제인은 허용하거나 거부할수 있다.

제인은 Beppa가 제안적인 접근을 하려고 한다는 사실을 확인한다. 제인은 Beppa가 그녀의 사진이나 다른것을 변경하도록 허용하는 것을 원하지는 않고 있다.  Beppa는 그녀의 사진을 가져오기 위하여 오직 이번 한번만 한시간 동안만 접근할 수 있다는 사실을 인지하게 된다.


Flow Screen 4

제인이 이 요청을 허용하게 되면 Faji는 Request Token을 제인에 의하여 사용자가 허용하였다고 표시해 둔다.

제인의 브라우저는 Beppa로 리다이렉트 되는데 이전 Request Token과 함께 제공되어진 http://beppa.com/order 주소로 리다이렉트 된다.

이제 Beppa는 제인의 사진을 가져올 수 있다는 것을 알게 된다.

제인은 Beppa가 그녀의 사진을 Faji로 부터 가져오기를 기다린다.

Flow Screen 5

제인이 기다리는 동안 Beppa는 허용된 Request Token을 이용하여 Access Token을 받게 된다.

Request Token은 오직 사용자의 허용을 요청할때만 유효하고, 반면 Access Token은 제인의 사진과 같은 제한적인 리소스에 접근할수 있다.

Flow Step 3

Beppa가 작업을 끝내면 제인의 브라우저는 리로드 되면서 작업은 마무리 된다.

Beppa는 성공적으로 제인의 사진을 가져왔다.


제인은 Beppa가 그녀의 Faji 아이디와 패스워드를 물어보지도 않고 사진을 가져오는 기능에 감동 받았고 그녀의 사진을 인화하도록 주문을 마쳤다.

Flow Screen 6


Posted by Breeze.Kang

댓글을 달아 주세요

  1. 심홍섭

    좋은 글 감사드립니다.

    2010.05.25 10:09 [ ADDR : EDIT/ DEL : REPLY ]
    • Breeze

      방문해주셔서 감사합니다. (__)

      2010.05.26 01:16 [ ADDR : EDIT/ DEL ]
  2. 김상형

    정말 깔끔하게 잘 번역해 놓으셨네요.
    덕분에 많은 시간을 아끼게 되었습니다.

    2010.06.04 19:33 [ ADDR : EDIT/ DEL : REPLY ]
    • Breeze

      감사합니다. 번역은 오랜만에 하는것이라 어색하지는 않은지 모르겠습니다.

      2010.06.09 14:38 [ ADDR : EDIT/ DEL ]
  3. 깔끔하게 잘 정리해놓으셨네요, 감사합니다^^

    2010.07.10 12:00 [ ADDR : EDIT/ DEL : REPLY ]
    • Breeze

      방문해주셔서 감사합니다.

      2010.09.28 10:08 [ ADDR : EDIT/ DEL ]

Facebook의 아키텍처를 엿볼수 있는 문서입니다.

php, mysql과 memcached 를 사용하고 있군요.

아래 문서를 보시면 Facebook에 memcached 적용을 위하여 memcached의 UDP 지원 부분과 성능 개선 작업에 일부 기여를 한것으로 보입니다.



최근 문서를 보면 Facebook의 inbox의 search에서는 Cassandra로 Persistence layer를 변경한것 같습니다.

http://en.wikipedia.org/wiki/Cassandra_%28database%29

http://www.facebook.com/video/video.php?v=540974400803#/video/video.php?v=540974400803



Caching & Performance: Lessons from Facebook
Posted by Breeze.Kang

댓글을 달아 주세요


Hibernate의 Criteria를 이용하여 프로그래밍시에

Entity class가 다른 entity를 참조하고 있을 경우에 Sort Ordering을 하기 위하여서는 다음과 같이 해줘야 합니다.


예를 들어서 다음과 같은 코드가 있다고 한다면...

Class A  {
   String someProperty;
   Class B otherObject;
}

Class B {
   String name;
}


A Entity를 select하여 올때 B Class의 name으로 Sorting을 하고 싶다면...

다음과 같이 하면 될것 같으나 해보면 에러가 발생합니다.

Criteria fooCriteria = session.createCriteria(A.class);
fooCriteria.addOrder(Order.asc("otherObject.name"));


실제는 아래와 같이 해줘야 합니다.

Criteria fooCriteria = session.createCriteria(A.class);
fooCriteria.createAlias("otherObject", "otherObjectAlias");
fooCriteria.addOrder(Order.asc("otherObjectAlias.name"));

이런식으로 하는 이유는 inner Join을 발생시켜야 name에 대한 ordering이 가능해지기 때문입니다.
Posted by Breeze.Kang

댓글을 달아 주세요



오늘 슬픈 뉴스 하나를 보게 되었네요.

모은행 통합 전산망 구축 작업을 지휘하던 전산팀장이 한강에서 숨진채 발견되었다고 합니다.

http://www.asiae.co.kr/news/view.htm?idxno=2010021610085138723

아직 타살인지 아닌지에 대한 여부는 짧은 뉴스로 알길이 없으나,

정황으로 봤을때 업무 스트레스로 인한 자살이 아닐까 조심스럽게 추측을 해봅니다.

그만큼 엔지니어로써 살아 간다는 것이 쉬운일이 아니겠지요.

더군다나 금융권 전산실은 더더욱 정확성을 요구하는 일인 만큼 스트레스가 더 심할 것 입니다.


PM으로 일을 하던 시절 3개월여를 주말없이 야근을 하면서,  스트레스를 받아가며 일을 했던 기억이 납니다.

그러면서도 왠지 모를 불안감에 속쓰림과 불면증에 시달리기도 했죠.

최근에 오픈한 프로젝트에서는 오픈후 문제 때문에 이틀간 밤을 세고 3일째 새벽이 되어서야 집에 들어가서 2시간 자고 다시 나오는 생활을 하기도 했습니다.
설연휴에도 하루는 아침부터 새벽까지 일을 해야 했죠.

그러나 개발자로 일을 하면서 가장 회의가 드는 것은 이런 야근이 아닌,

주변의 시선인것 같습니다.

이렇게 고생을 하면서 노력을 하는데도,  격려는 커녕 장애의 원인을 추궁하고 너희들 때문에 서비스가 이 모양이다,  혹은 너희들 때문에 손해가 막심하다고 하는 영업이나 기획부서의 차가운 시선이죠.

결국 일이란 사람들이 해나가는것 아니겠습니까.

일이 힘들어도 사람이 좋으면 버틸수 있는게 인지상정인데 말이죠.

새해 벽두부터 참 안타까운 소식이네요.

삼가 고인의 명복을 빌겠습니다.

그리고 다른 분들 프로젝트 때문에 너무 스트레스 받지 마세요~

걱정하나 안하나 결국 일은 시간이 해결이 주더군요.




Posted by Breeze.Kang

댓글을 달아 주세요

  1. 개발자도 자신의 일에 긍지를 가지고 자신의 능력과 실력에 합당한 대우를 받으며

    떳떳하게 일하는 그날이 빨리 왔으면 좋겠네요~

    저부터 노력해야죠^^

    2010.02.18 09:32 [ ADDR : EDIT/ DEL : REPLY ]
    • Breeze

      네 개발자들 모두가 그런 마인드로 일을 한다면 언젠가는 그런날이 오겠죠. 엔지니어들이 뭐 다른 직종보다 더 대접해달라는 것도 아니고 노력한 만큼만 인정 받겠다는건데 그게 왜 그리 힘든건지...

      2010.02.19 07:43 [ ADDR : EDIT/ DEL ]

${RequestParameters['test']}

또는

${RequestParameters.test}

로 사용하면 HttpRequest의 모든 Parameter를 사용할 수 있다.



또한 httpRequest의 Attribute를 사용하고 싶다면 다음과 같이 하면 된다.

${Request['AttributeName']}

또는

${Request.AttributeName}

Posted by Breeze.Kang

댓글을 달아 주세요

Spring 3.0을 이미 Project에 적용하고 계신 분들도 있으시리라고 생각합니다.

웹서핑을 하다가 보니 Spring 3.0의 새로운 기능에 대하여 잘 설명하고 있는 자료가 있어서 퍼왔습니다.

2009년 5월에 열린 Java User Group 세미나에서 발표된 자료구요,

원본 출처는 다음과 같습니다.

http://www.intertech.com/UserGroups/JUGPresentation.aspx?TopicID=135

무엇보다 REST URL을 지원해주는 부분이 눈에 띄는 부분입니다.

기존에 이 부분이 지원이 안되서 외부 라이브러리를 사용하거나 직접 구현하여 사용하곤 했었는데,

아주 깔끔하게 이 부분이 적용이 되었네요.

PPT에 그 내용도 설명이 나와있습니다.

한번 읽어보시기 바랍니다.

좀 더 자세한 내용은 아래 링크에서 문서를 보실 수 있습니다.

http://www.epril.com/resources/spring3/reference/html/index.html



Description : Spring MVC is the core component of the Spring Framework's web strategy. It provides a robust, flexible framework for building web applications built on the Model 2 architecture. In this presentation, Bob McCune will provide an overview of the new features and capabilities of Spring MVC including its @Controller annotations, REST support, and new data validation integrations.

Spring MVC 3
Posted by Breeze.Kang

댓글을 달아 주세요