현재 우리 회사 솔루션의 ASP.NET 웹 애플리케이션에는, 빈번하게 사용되는 개인 정보(혹은 설정값)을 담는 용도로 쿠키를 사용하고 있다. 쿠키는 사실 참 편리하다. 서버의 리소스를 점유하지도 않고, 만료기간만 지정해두면 서버가 다운되건 말건 계속 유지도 되고.. 서버사이드, 클라이언트 사이드 어디서나 쉽게 접속할 수 있기도 하고.

하지만, 솔루션에 대한 보안 감사 끝에.. 쿠키를 제거하기로 결정이 되었다. 사실 보안 측면에서 보자면 쿠키라는 것은 꽤 위험하다. 문제는 이 쿠키가 클라이언트에 저장되는 Plain Text파일인데다가, 모든 Web Server에 대한 Request/Response시에 전송이 된다는 것이다. 즉, 클라이언트에서 이 파일을 열어 볼 수도 있고, 네트워크 패킷을 스니핑해서 내용을 볼 수도 있다. 거기다가 위/변조하기도 당연히 쉽다. 또 일부 국가 - 어딘지는 잘 모른다 - 에서는 법적으로 쿠키를 금지하기도 하고, Internet Explorer등의 브라우저에서도 쿠키를 허용하지 않는 옵션을 장착하고 있기 때문에 어떤 사용자들의 경우 쿠키를 아예 사용할 수 없을 가능성도 있는 것이다.

서두가 장황했는데, 암튼 쿠키를 모두 제거하기로 하고 우리가 선택한 대안은 ASP.NET 세션이었다. 사실 빈번하게 사용되는 사용자 개인의 설정값등을 담아둘 수 있는 가장 이상적인 공간이기도 하고, 쿠키와 매우 유사하게 서버사이드에서 사용할 수도 있기 때문이었다. 하지만 이 ASP.NET 세션에는 한 가지 문제가 있다. 그 문제는 바로, 이 ASP.NET 세션이 기본적으로 쿠키를 사용한다는 것이다.

ASP.NET 세션을 사용하면 생성되는 쿠키는 이렇게 생겼다.

ASP.NET_SessionId=d1ucyg30qyjw1f554szadoqy;

즉, ASP.NET 세션에서 각 사용자를 구분하는 것 자체가 이 쿠키를 사용하는 것이다.

그런데, ASP.NET에는 Cookie-less Session이라고 해서, 쿠키를 사용하지 않고 세션을 사용할 수 있게 해주는 모드 또한 있다. 이것은 별도의 코딩이 필요한 것은 아니고 단지 Web.Config의 SessionState 부분에 Cookieless를 True로 바꿔주기만 하면 된다.

<sessionState
            mode="InProc"
            stateConnectionString="tcpip=127.0.0.1:42424"
            sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
            cookieless="true"
            timeout="20"
    />

이 Cookie-less Session에 대한 자세한 내용은 Dino Esposito씨의 다음 Article을 보면 알 수 있다.

위 아티클을 보면 알 수 있겠지만, 이 Cookieless Session은 세션을 쓰면서도 Cookie를 완전히 쓰지 않아도 된다는 점에서 나의 고민을 완벽하게 해주는 것이었다. 그러나 나는 몇 가지 문제를 발견했다..-_-;;

첫째로 이 Cookieless Session을 쓸 경우 모든 URL이 조금씩 바뀌게 된다는 것이다. 즉, 요청한 URL이 이렇다면..

http://localhost/CookielessSessionWebSample/Webform1.aspx

실제로 페이지가 열린 다음에는 이렇게 바뀌게 된다.

http://localhost/CookielessSessionWebSample/(mkwgif552tavi2vtxhgq1a45)/Webform1.aspx

위의 URL에 가운데 부분에 이상하게 끼어든 (mkwgif552tavi2vtxhgq1a45)이 바로 쿠키의 SessionID의 역할을 하는 것이다. 즉 쿠키를 쓰는 대신에 URL에 세션ID를 넣어서 사용한다고 생각하면 되겠다.

두번째로 바로 위 사실 때문에 몇가지 제약 사항이 발생한다. Server.Transfer와 Response.Redirect 등을 사용할 때, Root로부터 시작하는 URL 즉 이런 형태 - /RootDir/Somepage.aspx - 를 사용하지 못하며, Full URL - http://ServerName/RootDir/Somepage.aspx - 를 또한 사용하지 못한다. 이 사실은 EggHeadCafe라는 사이트의 한 게시물에서 알게 되었다.

첫번째 문제가 Accept된다면, 사실 대부분의 경우 큰 문제는 없을 것이다. 두번째처럼 만약 코딩을 했다는 것은, 사실 코딩 상에 문제가 있는 거라고 봐야 하니까. 그런데 내 경우는 우리 회사의 솔루션에 저런 것이 없다고 장담하기가 힘들었다는 것이다. 그래서, 우리 솔루션의 경우는 쿠키의 세션ID는 허용하는 방향으로 가기로 했다.

하지만, 쿠키를 완전히 사용할 수 없는 경우가 발생한다면, Cookie-less Session은 매우 좋은 선택이 될 것이다. 그리고 이 Cookie-less Session을 사용한다면 위에서 언급한 코딩상의 주의 사항은 반드시 지켜야 할 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

MSDN Magazine에 IIS 7.0에 대한 글이 실렸다.

http://msdn.microsoft.com/msdnmag/issues/07/03/IIS7/

IIS 7.0의 개선된 점들을 소개하고 있는데, 아래의 네 가지 항목이다.

Modular Web server functionality (웹 서버 기능의 모듈화 - 설치/제거가 간편해 진 듯)
Simplified deployment and configuration (배포, 구성이 간단해졌다)
Extensibility and ASP.NET integration (확장성과 ASP.NET 통합)
Improved security, performance, and compatibility (보안, 성능, 호환성의 개선)

개발자로서 가장 관심이 가는 부분은 아무래도 ASP.NET과 유기적인 통합을 이루었다는 점일 것이다. 위 글에 실린 그림을 인용해 보자면..


ISAPI Native 모듈을 통하지 않고, 바로 IIS와 ASP.NET이 연결이 된다는 것을 볼 수 있다. 위 글은 다음과 같이 그 효과를 설명하고 있다.

When running in Integrated mode in IIS 7.0, ASP.NET modules run in the unified request processing pipeline side-by-side with native C++ IIS modules. This means that existing ASP.NET services like Output Caching, URL Rewriting, and any others provided by your custom ASP.NET modules can now apply to any content type. Better runtime integration also enables ASP.NET modules to access previously unavailable server functionality, removing the need to write native IIS extensibility in most cases.
IIS 7.0이 통합 모드로 운영될 때, ASP.NET모듈은 Native C++ IIS모듈과 나란히 통합적인 리퀘스트 처리 파이프라인에서 동작하게 된다. Output 캐싱, URL 리라이팅과 같으 기존의 ASP.NET 서비스나 혹은 다른 당신이 만드는 별도의 서비스들이 이제는 모든 컨텐트 타입에 적용되게 된다. 개선된 런타임 통합은 ASP.NET이 이전에는 불가능했던 여러 가지 기능을 할 수 있도록 해주며, 결국 기존에 Native IIS 확장 모듈을 만들어야 했던 경우들은 이제 없게 될 것이다.

예전에 모 프로젝트(ASP.NET으로 진행했었던)에서 나는 C++로 ISAPI 필터를 하나 만들었던 경험이 있다. 이 ISAPI 필터의 역할은 특정 Request Header를 검사해서, 그것이 있다면 ID, PW입력이 없이도 Windows 인증을 통과시켜주는 것이었다. 이 것을 ASP.NET의 HttpModule 혹은 HttpHandler로 작성할 수 없을까 조사를 했었는데, 그 때는 그것이 불가능했었다. 왜냐하면 Windows 인증은 ASP.NET까지 오기전 ISAPI 모듈에서 일어나는 일이었기 때문에 ASP.NET으로서는 전혀 방법이 없었기 때문이다. 그런데, 이 그림을 보아하니 이런 경우도 이제는 가능해지는 것이 아닐까 생각된다. ASP.NET이 이제는 IIS와 Full Integration이 된다면, 아마 성능 상에도 많은 이점이 있을 것 같다. 결국은 단계가 하나 줄어드는 셈이 되는 것이니까. 물론 직접 사용해봐야 알 수 있겠지만, 현재로서는 기대가 많이 된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

특정 폴더에 있는 이미지를 웹 화면에 출력해야 하는데, 그 폴더를 웹 가상 디렉토리로 만들기가 힘든 상황이 있을 수가 있다. 아무래도 웹 가상 디렉토리로 노출되는 것은 보안에 문제가 있을 수 있다는 것을 의미하고, 그 폴더가 이미지 외에도 많은 내부 자료들이 들어있는 공용 스토리지라면 가상 디렉토리로 만드는 것은 좋지 않은 선택이다.

이럴 때, 이미지 파일을 읽어서 웹 화면에 출력해줄 수 있는 ASPX 웹 페이지 코드를 소개한다. 아래 코드는 서버의 파일명을 파라미터로 받아서, 그 파일을 이미지 형태로 웹 화면에 출력하는 코드이다.

일단, ASPX 페이지에는 아무런 HTML 코드가 없어야 한다. 아래와 같이 ASPX 페이지 지시자만 놔두고 모두 삭제하도록 한다.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

비하인드 코드는 다음과 같다. 아래 코드는 Page_Load 이벤트 핸들러에 두면 된다.

System.Byte[] arrBytes = null; //파일을 바이트로 읽기 위한 변수를 선언
string fileName = null; //파일명을 받을 변수 선언

try
{
  Response.ContentType = "image/jpeg" //Content Type을 반드시 image/jpeg 혹은 image/gif 등의 image 유형으로 지정해야 한다.
  fileName = Request["FileName"];

  if (!String.IsNullOrEmpty(fileName)) //파일명이 전달되지 않았을 때의 분기
  {
   arrBytes = new System.Byte[1000000]; //바이트를 넉넉하게 지정하자. 이 크기가 파일보다 작다면 에러가 발생한다.
   System.IO.FileStream fs = null; //파일을 읽기 위해 파일스트림 선언
   string filePath = fileName;
   string defaultFilePath = "c:\\camels.jpg" //파일이 존재하지 않을 때 사용할 이미지
   if (System.IO.File.Exists(filePath))
   {
     fs = new System.IO.FileStream(filePath, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read);
   }
   else
   {
     fs = new System.IO.FileStream(defaultFilePath, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read);
   }

   fs.Read(arrBytes, 0, 1000000);
   fs.Flush();
   fs.Close(); //파일스트림객체는 사용한 후에 반드시 해제해야 한다.

   Response.Clear();
   Response.OutputStream.Write(arrBytes, 0, arrBytes.Length); //웹 Response에 파일을 직접 쓴다. 이로써 이미지가 출력된다.
  }
  else
  {
   throw new Exception("파일명이 지정되지 않았습니다");
  }
}
catch (Exception ex)
{
  Response.Write(ex.ToString());
}

이 ASPX 페이지는 다음과 같이 사용하면 된다.

<img src="default.aspx?FileName=C;\\Camels.jpg"/>

사실, 이렇게 이미지를 웹 페이지로 출력하는 방법은 그렇게 좋은 방법은 아니다. 사실은 HttpHandler를 사용하는 것이 더 좋다. HttpHandler를 사용하는 방법은 Dino Esposito의 Image Generation Service for ASP.NET 1.1를 참조하기 바란다.

그리고, 위 샘플 코드는 파일 경로가 GET 파라미터로 완전히 보이기 때문에 그냥 사용하면 안된다. 적어도 파일 명 앞의 경로는 Config 파일에 두는 방법을 사용하길 바란다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Team Foundation Server에서 제공하는 Team build기능에서, 솔루션을 지정하게 되면 그 솔루션에 포함된 모든 프로젝트가 빌드되게 된다. 그러나 솔루션에 웹 사이트가 포함되어 있을 경우에 문제가 약간 있는데.. 이건 빌드가 되지 않는다.. 결과물에 다른 DLL이나 EXE는 있을 지 몰라도, 웹 사이트는 없을 것이다...-_-;;

이건 VS2003, 닷넷 1.X에서 우리가 쓰던 Web Application과 VS2005의 Web Site가 전혀 다른 개념이기 때문이다. Web Site는 사실 굳이 컴파일할 필요가 없다. Runtime에 자동으로 컴파일이 되기 때문이다. 그러므로 사실 팀 빌드에서 포함시킬 필요도 없긴 하겠지만.. Web Application 과 비교해봤을 때 아무래도 다음과 같은 단점이 있게 된다.

소스가 그대로 서버의 디렉토리에 노출된다.
미리 컴파일된 것보다는 Runtime시에 컴파일되는 것이 느릴 것이다. (물론 처음에 한 번만 하겠지만.., 그리고 이 때문에 소스만 바꿔도 컴파일할 필요없이 운영된다는 것은 아주 좋은 점이긴 하다)
실수로 컴파일 에러가 나는 소스가 올라갈 수도 있다.

Aspnet_compiler.exe와 aspnet_merge.exe를 사용해서 기존의  웹 애플리케이션과 똑같은 형태로 컴파일할 수 있긴 하다. 하지만 과정이 매우 복잡하고, 결정적으로 귀찮다는...-_-;;;; 이 과정을 자동화시킬 수 있는 툴이 있다. 바로 Visual Studio 2005 Web Deployment Project이다. 이건 VS2005에 Add-In으로 간단하게 설치할 수 있고, 아래 주소에서 다운로드 받을 수 있다.

http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx

사용방법은 간단하다. 아래 그림처럼 웹 사이트에 오른쪽 마우스를 누르면, 컨텍스트 메뉴가 뜨는데 거기서 Add Web Deployment Project를 누르면 된다.

팝업 화면이 뜨는데, 이름과 경로를 입력하면 된다. 입력한 이름은 그 Deployment Project의 이름이 되기도 하지만, 실제 출력되는 웹 DLL의 이름이 되기도 한다.

Debug(혹은 Release - 빌드 옵션에 따라서) 폴더에 가면, ASP.NET 1.X시절과 같은 형태로 출력물이 나온 것을 볼 수 있다. Web Page의 aspx와 bin 폴더 아래의 DLL들.. 이제 이 결과물을 IIS에서 만든 가상 디렉토리에 복사하기만 하면 된다. 아래 그림은 결과물 폴더와 bin 폴더인데, bin 폴더에 보면, 좀 전에 만든 Web Deployment Project의 이름과 똑같이 DLL이 만들어진 것을 볼 수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

ASP.NET 2.0에는 Master Page라는것이 새로 생겼다.  마스터 페이지의 개념을 MSDN에 나온 그대로 옮기면 다음과 같다.

"ASP.NET 마스터 페이지를 사용하면 응용 프로그램의 페이지에 대해 일관된 레이아웃을 만들 수 있습니다. 단일 마스터 페이지는 응용 프로그램의 모든 페이지 또는 페이지 그룹에 대해 원하는 모양과 느낌 및 표준 동작을 정의합니다. 그런 다음 표시할 콘텐츠가 포함된 개별 콘텐츠 페이지를 만들 수 있습니다. 사용자가 요청한 콘텐츠 페이지는 마스터 페이지와 병합되어 마스터 페이지의 레이아웃과 콘텐츠 페이지의 콘텐츠가 조합된 결과가 만들어집니다."

그런데, Master Page - Content Page가구성이되면, 마치 ASCX처럼 내부로 중첩된 컨트롤들의 Client ID가 아주복잡해지는 것을 소스보기에서 볼 수가있다. 이렇게..

그래서, 자바스크립트를 사용해서 제어하고자 할 때 반드시 서버사이드에서 그 컨트롤의 ClientID를 구해서 해야한다.다음은 Master Page에서 자바스크립트로 Content Page의 컨트롤을 제어하는 샘플이다.

마스터 페이지에는 버튼 컨트롤과 텍스트 박스 컨트롤을 하나씩 올려 두었다.

ASPX 소스는 아래처럼 된다.



컨텐트 페이지에는 텍스트박스 컨트롤을 하나 올렸다.


ASPX 소스는 아래처럼 구성된다.


목표는 마스터페이지에서 버튼을 눌렀을 때, 컨텐트 페이지의 텍스트 박스에 "aaa"라는 값이 들어가게 하는 것이고, 이를 자바스크립트를 사용해서 수행하는 것이다. 그 코드는 다음과 같다.



주석에도 설명이 되어 있지만, 포인트는 마스터 페이지에 있는 PlaceHolder 컨트롤 내부에서 그 컨텐트 페이지에 있는 컨트롤을 찾는 것이다. 일단 찾은 후에는 그 ClientID 속성을 구할수 있으므로, 이 샘플보다 복잡한 스크립트도 얼마든지 수행시킬 수가 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.