728x90

마이크로소프트는 최근 비주얼 스튜디오 2015 버전을 공개하면서 ASP.NET 5 와 크로스플랫폼 런타임 환경인 .NET CLR Core 을 공개했습니다. 새로운 버전의 공개에 맞추어 지난 20일 마이크로소프트 닷넷 개발자 블로그 포스팅을 통해 버그 혹은 취약점을 발견하는 이들에게 최대 15,000달러의 포상금을 지급하는 프로그램이 시작됨을 알렸습니다. 버그와 취약점에 대한 리포트는 새롭게 공개된 ASP.NET 5 와 .NET CLR Core 에 대해 적용되며 아직까지 개발이 진행중인 네트워크 스택(Network Stack)은 이번 프로그램에서 일단은 제외된다고 합니다.


마이크로소프트가 이번과 같은 프로그램을 운영했던 적이 있는지 찾아보지는 못했습니다만 근래 메신저 서비스인 텔레그램(Telegram)의 보안 취약점 관련 프로그램이나 라인(LINE)의 버그 바운티(Bug Bounty) 처럼 보다 적극적으로 취약점을 찾고 보완하여 크로스플랫폼 시장에서의 존재감을 만들어 나가겠다는 적극성이 물씬 느껴지는 듯 합니다. 시간이 되시는 분들이나 관심 있으신 분들은 닷넷 코어의 크로스플랫폼 버전에 대해서 심도 있는 지식도 쌓고 포상 프로그램을 통해 금전적인 혜택도 받아볼 수 있는 기회로 만들면 더할나위 없이 좋은 기회일 것 같습니다.




포상금은 취약점 타입별로 몇 가지 등급으로 나뉘어져 있습니다. 단순한 크로스 사이트 스크립트(XSS)와 같은 케이스는 심각도에 따라 500 달러에서 최대 2,000 달러까지 지급되며, 원격 코드 실행(Remote Code Execution)과 같은 심각한 케이스에 대해서는 최대 15,000 달러까지 포상금이 책정되어 있습니다. 보안 취약점을 찾아내어 증명하기 쉬운 것과 어려운 것에 차별점을 두어 보다 심각한 오류, 버그에 대해서는 충분히 그 보상을 해주겠다는 의미로 해석됩니다.



소프트웨어, 어플리케이션을 개발하다 보면 다양한 입력감 검증이나 변수 핸들링, 체계적으로 제한된 위임등을 통해 가능한 불필요한 코드의 영향을 줄이고 테스트 케이스들을 통해 이들이 정상적으로 동작하는지 검증하는 일들을 늘 하게 됩니다. 하지만 사람이 하는 모든 일들이 그렇듯 모든 예외 케이스나 특정한 상황을 다 찾아내어 테스트 하는 것은 거의 불가능합니다. 그래서 늘 패치(Patch)가 존재하고 버그 픽스(Bug Fix)가 필요할 수 밖에 없습니다. 쟁쟁한 사람들이 모여 만들고 테스트하여 출시하는 마이크로소프트에서도 버그 포상 프로그램을 통해 보다 완벽한 환경을 만들고자 하는 것을 보면 창과 방패의 관계처럼 완벽을 "추구"하는 코드와 버그와의 전쟁은 앞으로도 계속 될것만 같습니다!


닷넷 코어 CLR 및 ASP.NET 5 버그 포상 프로그램 포스팅 살펴보기 [바로가기]

버그 포상 프로그램 상세 시상(?) 내역 및 범위 살펴보기 [바로가기]


728x90
728x90
iBatis.net 을 사용하면 확실히 닷넷 코드 레벨에서 데이터베이스 관련하여 고민할 것이 많이 줄어들기 때문에 무척 좋습니다. Entity Framework 를 쓰면 얻을 수 있는 더 많은 잇점들이 있지만 간단하게 데이터베이스 엑세스에 대한 부분을 정리하고 간편화하는데에는 iBatis.net 이 훨씬 투입 공수가 적은 장점이 있습니다.

다만 iBatis.net 단에서 문제가 발생했을 때는 트러블 슈팅이 쉽지 않은편입니다. 오픈소스기 때문에 누가 책임을 져주는 것도 아니고 한번 내부적으로 처리된 에러 메세지들이 나오기 때문에 더 상세한 오류 원인을 찾으려 삽질하기 일쑤지요. 이번에 개발된 내용물을 클라우드 서버에 포팅하면서 겪은 문제 역시 마찬가지였습니다. 기록 차원에서 블로그에 정리해 둡니다.

에러의 시작, " Unable to open connection to ... "

로컬에서 MS-SQL 을 가지고 작업을 할때 아무런 문제가 없었던 로직. iBatis.net 의 장점을 십분 활용해 실서버 환경에서 provider.config 를 오라클에 맞추어 조정하면 가볍게 끝날것으로 생각했던 작업은 만 하루가 넘게 걸리고서야 해결될 수 있었습니다. 오래걸린 주요한 이유 중 하나가 바로 iBatis.net 가 추상적으로 던진 에러의 원인을 찾기 위함이었네요.

로컬은 32bit 개발환경이고 공교롭게도 처음 포팅했던 서버는 Windows Server 2003 32bit 버전이어서 더욱 오래 걸렸던 이번 에러. 두번째 포팅한 서버가 Windows Server 2008 R2 64bit 환경이었고, 여기에서 System.Data.OracleClient 네임스페이스에 매핑된 라이브러리가 32bit 냐 64bit 냐 때문에 발생하는 것이었습니다.  

참조링크 : OTN 의 OracleClient 64bit 모드 관련 Forum 글 참조 [바로가기]


비주얼 스튜디오로 빌드를 하면서 특별히 빌드 환경을 지정하지 않고 Any CPU 로 하고 있던게 화근이었습니다. iBatis.net 이 계속 에러를 토하는 과정에서 내부 에러를 살펴보니 아래와 같은 메세지를 내놓고 있었습니다. 기본적으로 iBatis.net 이 던져주는 Exception 의 Message 로는 확인이 되지 않는 부분이었습니다.


여러가지 해결 방법들이 제시되었고 가장 많은 것이 Oracle Client 를 환경에 맞게 재설치 하는 것이었는데 제가 전담하는 서버도 아니고 해서 그 방법을 쓰는건 너무 위험해 보였습니다. 그래서 x86 과 x64 로 빌드후 포팅을 해보기로 했는데, x86 으로 재빌드 하고 나서 아무런 문제가 없이 잘 수행되는게 확인 되었습니다.

혹시 비슷한 오류를 겪으시는 분들은 서버 환경에 따라 빌드 옵션을 다르게 주고 빌드한 다음 테스트를 해보시는 것을 추천해 드립니다. 이것 때문에 하루를 넘게 소비했다는 것이 참 어이가 없을 뿐입니다. 아무쪼록 누군가에게 도움이 되고 스스로에게도 언젠가 레퍼런스로 활용할 수 있도록 블로그에 글 남겨둡니다.

- NoPD -
 
728x90
728x90
마이크로소프트가 제공하는 닷넷 프레임워크는 그 양이 정말 방대하다. 그러다 보니 이미 오래전부터 존재하고 있음에도 불구하고 사용자들에게 널리 사용되지 않는 요소들도 꽤 많다. 오래된 기술이라서 Deprecated 되는 요소를 제외하더라도 그 유용성에 비해 사용자들의 인지가 떨어지는 것들이 여럿 있다. 그 중 대표적인 것이 바로 "?? 연산자" 이다. 

일반적으로 사용자들은 단행 조건문 처리를 할 때나 Nullable 자료형을 선언할 때 쓰는 "?" 는 많이 사용하는 편이다. 하지만 물음표를 두개 붙이 "??" 연산자를 사용하는 경우는 쉽게 찾아보기 어렵다. 그렇다면 도대체 물음표를 두개 붙여 놓은 "?? 연산자"는 무얼하는 친구일까?

 
우선 "??" 연산자는 영어로 null-coalescing 연산자라고 부른다. 우리말로 어떻게 해석해야 할지 조금 애매하니 그냥 "??" 또는 "?? 연산자" 라고 부르기로 하겠다. 이 연산자의 용도는 Null 값을 가질 수 있는 변수들을 사용할 때 초기값의 원활한 지정이다. 보통 Null 값의 처리를 위해 아래와 같은 코드를 많이 사용한다.

int? numOne = null;
int? numTwo = 23;

if (numOne != null)
    return numOne;
if (numTwo != null)
    return numTwo;

return 10;


이 코드는 Null 값을 가질 수 있는 두개의 정수형 변수 numOne 과 numTwo를 비교하여 Null이 아닌 값을 출력하기 위한 간단한 코드이다. 만약 둘다 null 값이면 숫자 10을 출력하게 된다. 우선 이 코드를 물음표 한개를 이용하여 단행 조건문으로 처리해 보면 아래처럼 표현될 수 있다.

return (numOne != null ? numOne : (numTwo != null ? numTwo : 10));

한줄로 처리가 되긴 했지만 가독성이 그리 높은 코드는 아니다. 코드 자체의 길이도 길지만 콜론과 괄호, 물음표, 부등호 등이 섞여 있어서 한눈에 내용을 파악하기에는 쉽지 않은 상태이다. 이것은 "??" 연산자를 이용해서 표현하면 아래와 같다.

return ((numOne ?? numTwo) ?? 10);

처음에 상당히 길었던 코드가 상당히 짧게 표현되었다. numOne ?? numTwo 의 의미는 두가지 변수 중 Null 값이 아닌 것이 어떤 것인가? 를 의미한다. Null 이 아닌 값이 있으면 해당 변수 값이 Return 된다. 하지만 둘다 Null 이면 numOne ?? numTwo 의 결과는 Null 이다. 이후 바깥쪽 괄호의 처리가 진행되는데 Null ?? 10 을 연산하게 되면 Null 이 아닌 10 이 Return 되게 된다.  

소프트웨어 개발을 하면서 Null 값의 처리는 꼭 해줘야 하는 필수적인 예외처리 로직이다. 이왕 해야 하는 처리 로직이라면 조금 더 간결하고 가독성 있는 코드를 만들어 쓰는 것이 더 좋지 않을까?

- NoPD - 
728x90
728x90
WCF 를 이용한 통신채널을 구성할때, 일반적인 방법으로 인터페이스를 선언하고 웹 참조 혹은 DLL 참조, Svcutil 로 생성된 레퍼런스 정보를 사용할 때는 별 문제가 없다. 하지만 WCF 3.5 부터 제공되기 시작한 REST 형태의 호출 지원을 사용하는 경우에는 파라메터의 데이터 형태에 따라 BodyStyle 속성을 지정해야 하는 경우가 빈번하다.

예> IService.cs

[ServiceContract]

public interface IService

{

    [OperationContract]

    [WebInvoke(UriTemplate = "Counter", Method = "POST", BodyStyle = WebMessageBodyStyle.Wrapped)]

    int Counter(CounterList counterValues, int tryCount); 

 
그런데 문제는 서비스의 인터페이스 선언에 이렇게 WebInvoke Attirbute 와 BodyStyle 을 지정했음에도 클라이언트에서 서비스를 호출할 때 BodyStyle 이 Wrapped 로 지정되지 않았다는 에러가 발생할 때가 간혹 있다는 점이다. 특히 svcutil 을 이용해서 매뉴얼하게 레퍼런스 클래스를 만드는 경우에 이런 일이 많이 발생한다. (웹참조로 추가하는 경우에도 발생한다는 보고가 있다)

예> 클라이어트에서 서비스 호출시 에러 메세지

'IService' 계약의 'Counter' 작업에서 래퍼 요소 없이 직렬화할 여러 개의 요청 본문 매개 변수를 지정합니다. 최대 하나의 본문 매개 변수가 래퍼 요소 없이 직렬화될 수 있습니다. 추가 본문 매개 변수를 제거하거나 WebGetAttribute/WebInvokeAttribute의 BodyStyle 속성을 Wrapped로 설정하십시오.


이런 경우 서비스쪽을 자꾸 살피게 되는데 원인은 서비스가 아니라 레퍼런스 클래스의 생성에 있기 때문에 트러블슈팅이 쉽지 않다. svcutil 명령을 이용해서 만든 레퍼런스 클래스를 확인해 보면 WebInvoke 로 지정한 내용이 전혀 들어가있지 않은 걸 쉽게 발견할 수 있다. 해당 부분에 동일한 선언을 추가해주면 에러를 가볍게 제거할 수 있다.

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]

[System.ServiceModel.ServiceContractAttribute(ConfigurationName="IService")]

public interface IService

{

[System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IService/Counter", ReplyAction="http://tempuri.org/IService/CounterResponse")]

    [WebInvoke(UriTemplate = "Counter", Method = "POST", BodyStyle = WebMessageBodyStyle.Wrapped)]

    int Counter(Counters counterValues, int tryCount);


비동기 형태로 호출하기 위해 만든 레퍼런스 클래스의 경우에도 Beginxxx 와 같은 비동기 메소드를 선언하는 부분에는 지정해줄 필요가 없다. 원래 함수의 속성으로만 지정하면 문제는 해결된다. 혹시 비슷한 어려움을 겪는 사람들을 위해서 공유해둔다.

- NoPD -



 

 
728x90

+ Recent posts