- Cookie 스펙 자체에서 발생하는 4KB의 용량제한.
- 사용자에게 Session 정보가 노출됨에 따른 보안 이슈.
- 느린 퍼포먼스
- App. Server를 여러 대 사용하는 경우 사용할 수 없다.
- File System보다 나은 퍼포먼스
- 확장성 (App. Server가 여러 대인 경우에도 사용 가능)
- Session 정보 유지 (MemoryDB가 아니라면, DB server가 재시작해도 session 정보를 유지할 수 있다.)
- 추가적인 설정이 필요. (rake db:session:create)
- Memory 기반 방식보다는 느린 퍼포먼스
- 빠른 퍼포먼스
- 확장성
- memory 관리를 위한 추가적인 service가 필요
- 서버가 재시작될 경우, Session 정보가 유지되지 않는다.
- 최고의 퍼포먼스
- 확장성 (클라이언트의 PC에 저장되므로 Server의 대수와 관계없음)
- Session 정보 유지 (Cookie가 삭제되지 않는한 Session정보가 유지됨)
- 4KB의 용량 제한
- 보안 문제 (Session 정보가 사용자에게 노출됨)
CookieStore
Rails2.0에서의 Session값의 기본 저장장소는 Cookie이다. rails 1.x에서 Server의 File System, DB 혹은 메모리에 저장되는 Session 정보를 클라이언트의 PC에 Cookie로서 저장하는 것이다. 이 Cookie 기반의 session 저장을 사용하기 위해서는 몇가지 제약이 따른다.
이런 제약 사항에도 불구하고, CookieStore가 사용되는 이유는 성능상의 문제 때문일 것이다. 보안 상의 문제만 주의한다면 위에서 언급한 기존의 Session Store보다 performace면에서 훨씬 이득을 볼 수 있다. 다음은 각 Session 저장 방식의 장단점을 정리한 표다.
|
방식 |
장점 |
단점 |
|
File System |
간편한 사용 (추가적인 설정이 필요없음) |
|
|
DB |
|
|
|
Memory |
|
(ex. MemCached daemon) |
|
Cookie |
|
|
CookieStore를 실제 서비스에 적용하는데 있어서 일차적으로 걱정이 되는 것 중의 하나가 4KB의 용량 제한이다. 하지만 실제 Rails Service를 개발해보면, Session에 저장되는 정보는 4KB의 용량이면 충분한 것들이 대부분이다. (로그인 유지를 위한 사용자 id, flash 메시지 등) 따라서 특별히 Session에 많은 양의 정보를 넣을 필요가 없는 경우라면, CookieStore는 좋은 대안이 될 수 있다.
Cookie 저장방식
다음은 CookieStore를 사용하는 경우, 사용자 PC에 저장된 cookie의 일부분이다. (key=value)
_blog.superkdk.com_session_id=BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6R
mxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7AA%253D%253D--da48d6c6a6bffdb189855
d3b6ae13a3c559673a2
위의 key, value를 분석해보면 다음과 같다.
|
값 |
내용 |
|
_blog.superkdk.com_session_id |
다른 Cookie 값들과 구분하기 위한 session key |
|
BAh7BiIKZmxhc2hJQzonQWN0aW9uQ 29udHJvbGxlcjo6Rmxhc2g6OkZsYX No%250ASGFzaHsABjoKQHVzZWR7AA %253D%253D |
--의 앞부분으로 실제 session data. Base64로 encoding된 Marshal 값. |
|
da48d6c6a6bffdb189855d3b6ae13 a3c559673a2 |
--의 뒷부분으로 session data의 변조여부를 검증하기 위한 값. session data에 secret 값을 붙인 string을 SHA512로 digest한 값. ( Digest::SHA512.hexdigest("#{data}#{secret}) ) |
위에서 보는 것처럼 실제 session data는 원래의 session 정보를 decode해서 볼 수 있다. 하지만 서버에서 설정된 secret 값을 모른다면 위의 session data는 변조될 수 없다. 매번 session 값을 cookie로 부터 restore할 때마다, session data의 변조 여부를 검증하기 때문이다.
Rails2.0으로 Upgrade시 주의사항
위에서 언급하였듯이, CookieStore에서는 사용자 PC에 Session 정보가 저장되기 때문에 사용자가 쉽게 session 정보를 읽을 수 있다. 따라서 이를 변조하지 못하게 하기 위한 secret key가 필요하게 되었다. Rails 1.x에서 2.0으로 update하는 경우, config/environment.rb에 secret에 대한 설정이 없기 때문에 에러가 발생한다.
A secret is required to generate an integrity hash for cookie session data. Use config.action_controller.session = { :session_key => "_myapp_session", :secret => "some secret phrase of at least 30 characters" } in config/environment.rb
위의 설명대로 config.action_controller.session 값을 설정해주면 되는데, 여기서 secret 값으로 30자 이상의 문자열이 요구한다. Rails::SecretKeyGenerator를 사용하면 이 값을 간단하게 생성할 수 있다. (Rails 2.0에서 프로젝트를 생성할 때, 자동으로 입력되는 secret 값이 Rails::SecretKeyGenerator에 의해서 생성되는 것이다.)
$> ./script/console
>> require 'rails_generator/secret_key_generator'
>> Rails::SecretKeyGenerator.new('blog.superkdk.com').generate_secret
만약 Rails 2.0.2로 업그레이드 했다면 "rake secret"이란 rake 명령어로 간단히 secret 값을 구할 수 있다.
참조
::: 사람과 사람의 교감! 人터넷의 첫 시작! 댓글을 달아주세요! :::
잘 배우고 갑니다.
Rails 2.0.2로 업글하면서 안 되는 이유들이 하나씩 풀려가서 기쁩니다.
루비사용자모임에서 보이던 아이디를 여기서 또 는군요. ^^*
감사합니다.