superkdk in the NET.

Rails 1.2.x에서는 scaffold_resource라는 generator가 있었다. 예를 들어 post라는 model의

scaffold_resource를 생성하기 위해서는 다음과 같은 명령어가 사용되었다.




$> script/generate scaffold_resource post title:string content:text created_at:datetime




위의 명령어는 다음과 같은 요소들을 생성하게 된다.

• Model (app/models/post.rb)
• RESTful controller (app/controllers/posts_controller.rb)
• Views (app/views/posts/)
• Migration (db/migrate/001_create_posts.rb)
• RESTful route (map.resources :posts)
• Test Suite



Rails 2.0에서는 scaffold_resource 라는 generator가 삭제되고, scaffold generator가 동일한 역할을 하게 되었다. 즉 "script/generate scaffold <model> <columns>"라는 명령어를 실행시킬 경우, 위와 동일한 요소들을 생성하게 된다.




단 Rails 1.2.x에서 사용되던 "script/generate scaffold <model> <controller>"와 같은 형태의 명령어는 사용할 수 없게 되었다.






scaffold 도움말

Rails 2.0.2에서 기본 데이터베이스로 선택된 SQLite3에 대해서 살펴보고, 간단한 블로그 어플리케이션을 만들어보자. 이 문서는 Windows 머신을 기본으로 작성되었다.

SQLite 환경 구축하기

Windows에서  SQLite를 사용하기 위해서는 다음의 단계에 따라서 설치한다.

1. SQLite 다운로드

SQLite 다운로드 페이지에서 sqlite-3_5_4.zip 파일과 sqlitedll-3_5_4.zip 파일을 다운로드 받는다.

2. 압축풀기 및 설치

각각의 파일의 압축을 풀면 다음 파일들이 확인할 수 있다.

• sqlite-3_x.zip : sqlite3.exe
• sqlitedll-3_x.zip : sqlite3.def, sqlite3.dll

SQLite3를 위한 폴더를 만들고 (ex. C:\Program Files\SQLite3) 위 파일들을 복사한다. SQLite3 폴더는 환경변수 PATH에 등록되어 있어야 한다. (이도저도 귀찮으면 그냥 C:\Windows\System32에 복사해도된다.)

3. Gem 설치

sqlite3-ruby gem을 설치한다.

sqlite3-ruby gem 설치

블로그 어플리케이션 만들기

SQLite3를 사용해서 간단한 블로그 어플리케이션을 만들어보자.

1. 프로젝트 생성

Rails 2.0.2 이전에는 "rails myapp" 라는 명령어를 실행시키면, config/database.yml이 MySQL로 설정되었다. 그러나 SQLite3가 기본 데이터베이스로 변경되면서 새로운 프로젝트를 생성하면 config/database.yml이 다음과 같이 설정된다.

config/database.yml

MySQL을 기본 데이터베이스로 했을 경우에는 Rails 프로젝트의 생성과는 별도로 데이터베이스 생성(CREATE DATABASE) 및 권한 설정(GRANT)을 해주어야만 했다. 하지만 SQLite3의 DB 파일은 자동으로 생성되기 때문에, 데이터베이스 생성이나 권한 설정 작업이 필요없이 바로 개발을 시작할수 있다.

cf. 만약 예전처럼 MySQL을 기본 데이터베이스로 사용하고 싶다면, "rails -d mysql myapp"와 같이 프로젝트 생성시, 데이터베이스를 명시해주어야 한다.

2. Scaffold 생성

위에서 언급하였듯이, SQLite3의 데이터베이스 파일은 자동으로 생성되기 때문에, 바로 migration을 생성해서 적용할 수 있다. 위의 config/database.yml과 같이 설정되어있다면 db/development.sqlite3라는 파일이 생성되게된다. 여기서는 Post에 대한 scaffold resource를 생성한 후, migration을 적용해보자.

scaffold 생성

3. 생성된 테이블 확인

sqlite3라는 커맨드라인 유틸리티를 이용해서 생성된 테이블을 확인하고, SQL문을 실행할 수 있다. (현재는 테이블에 레코드가 들어있지 않는 상태이다.)

sqlite3 커맨트라인 유틸리티

4. 어플리케이션 확인

서버를 시작하고, 방금 작성한 어플리케이션을 확인하다.

1. 글쓰기 페이지 (http://localhost:3000/posts/new)

2. 글보기 페이지 (http://localhost:3000/posts/1)

3. 글목록 페이지 (http://localhost:3000/posts)

결론

Rails 소개에서 지겹도록(?) 나오는 블로그 어플리케이션 만들기를 통해서 SQLite3의 사용법을 살펴보았다. 15분 만에 블로그 만들기는 Rails를 처음 접하는 사람에게 Rails의 매력을 보여주기 충분한 예제이다. 이것이 Scaffold, Resource의 개념이 추가되면서 점점 시간이 단축되더니, 이번에 Rails 2.0.2에서 SQLite3가 기본 데이터베이스 엔진으로 선택되면서 1분만에 블로그 만들기가 가능하게 되었다.

Ruby on Rails를 공부하거나 내부적으로 사용되는 간단한 어플리케이션을 개발하는 용도라면 SQLite3는 좋은 대안이 될 수 있을 것이다.

참조

• http://blog.rubyonrails.org/2007/12/17/rails-2-0-2-some-new-defaults-and-a-few-fixes
• http://jroller.com/obie/entry/installing_sqlite_3_on_windows

• http://www.sqlite.org/

CookieStore

Rails2.0에서의 Session값의 기본 저장장소는 Cookie이다. rails 1.x에서 Server의 File System, DB 혹은 메모리에 저장되는 Session 정보를 클라이언트의 PC에 Cookie로서 저장하는 것이다. 이 Cookie 기반의 session 저장을 사용하기 위해서는 몇가지 제약이 따른다.



• Cookie 스펙 자체에서 발생하는 4KB의 용량제한.
• 사용자에게 Session 정보가 노출됨에 따른 보안 이슈.



이런 제약 사항에도 불구하고, CookieStore가 사용되는 이유는 성능상의 문제 때문일 것이다. 보안 상의 문제만 주의한다면 위에서 언급한 기존의 Session Store보다 performace면에서 훨씬 이득을 볼 수 있다. 다음은 각 Session 저장 방식의 장단점을 정리한 표다.




방식	장점	단점
File System	간편한 사용 (추가적인 설정이 필요없음)	느린 퍼포먼스 App. Server를 여러 대 사용하는 경우 사용할 수 없다.
DB	File System보다 나은 퍼포먼스 확장성 (App. Server가 여러 대인 경우에도 사용 가능) Session 정보 유지 (MemoryDB가 아니라면, DB server가 재시작해도 session 정보를 유지할 수 있다.)	추가적인 설정이 필요. (rake db:session:create) Memory 기반 방식보다는 느린 퍼포먼스
Memory	빠른 퍼포먼스 확장성	memory 관리를 위한 추가적인 service가 필요 (ex. MemCached daemon) 서버가 재시작될 경우, Session 정보가 유지되지 않는다.
Cookie	최고의 퍼포먼스 확장성 (클라이언트의 PC에 저장되므로 Server의 대수와 관계없음) Session 정보 유지 (Cookie가 삭제되지 않는한 Session정보가 유지됨)	4KB의 용량 제한 보안 문제 (Session 정보가 사용자에게 노출됨)




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 값을 구할 수 있다.





참조

• 037 레일스 쿠키와 보안 문제
• CookieStore
• SecretKeyGenerator