Sorcery VS Devise

Sorcery 소개

ca62lrg

얘는 소서리스에요..

Devise는 워낙 유명해서 별도의 설명이 필요 없겠지만 Sorcery의 경우 상대적으로 덜 유명해서 간략하게 소개를 먼저 해본다.

이스라엘 개발자 Noam Ben Ari(이후 NoamB)가 만든 Authentication Gem으로 2010년 10월에 첫 커밋이 나왔다.
필자는 이전까진 restful-authentication를 사용했는데 Rails 3가 출시했음에도 불구하고 대응이 늦었다.
그때 혜성처럼 나타난 게 몇 가지 있었는데 Sorcery, Devise도 그것들 중 하나였다. (지금까지 살아남은 녀석들도 아마 이 두 녀석뿐일 듯)
처음에는 Devise를 사용했었지만 RailsCasts에서 Sorcery를 소개해줬고, 이때부터 쭉 Sorcery를 사용해왔다.

NoamB 거의 혼자서 개발을 해오다시피 했고, 지금은 개인 Repository가 아닌 Sorcery의 Repository를 만들어서 관리하고 있고, NoamB는 현제 일선에서 물러나 Chase GilliamJosh Buker 이 두 사람이 Maintainers로 관리를 하고 있다.

Sorcery만 소개해주면 Devise한테 미안하니 간략히 소개하자면 SimpleForm을 만든 plataformatec이 만들고 관리하고 있다.

기능 비교

사실 처음에는 그냥 느낀 점만 간략하게 쓸려고 했는데.. 그럼 너무 성의 없어 보일까 봐 간략하게 정리해봤다.
기능 위주로 선택하려 한다면 아래 표가 도움이 되시리라

기능설명 Sorcery Devise
Authentication Core Database Authenticatable
OAuth External Omniauthable
회원가입시 메일 인증 프로세스 User Activation Confirmable
암호 리셋 프로세스(메일 전송) Reset Password Recoverable
회원가입 Core Registerable
자동 로그인 Remember Me Rememberable
로그인/아웃등 유저 행적 기록 Activity Logging Trackable
Session Timout 설정 Session Timeout Timeoutable
Validation email, password Validatable
로그인 실패 여러번시 계정 잠금 Brute Force Protection Lockable
HTTP Authentication Basic HTTP Authentication Database Authenticatable

Validation이 Sorcery에는 없지만 이건 Rails의 Validators를 이용하면 해결된다. (Rails를 아시는 분이라면 Devise가 Validation을 왜 따로 제공하는지 이해가 안가실 수도 있는데, 그건 아래에 설명하겠다)
보면 알겠지만 방법의 차이만 있을 뿐 제공하는 기능은 동일하다.
그러므로 기능의 수는 안타깝게도 무승부.

간단히 Authentication 위주로만 쓸 경우

문서 살펴보고 맘에 드시는 걸로 선택하면 된다.

57f8la

장난 아니고, 진짜에요..;;

여러 부가기능을 쓰지만 수정 안 하고 쓸 경우

Devise를 추천한다.
Devise는 Boilerplate가 아주 많이 제공되어서 여러 부가 기능을 사용할 때 편리하다.
하지만 많은 커스터마이징이 필요한 경우에는 적합하지 않다. (우리가 알고 있듯 Boilerplate는 양날의 검인데, 그 단점이 여기에도 해당된다고 보면 된다)
왜냐하면 Devise는 많은 부분들이 감추어져 있다 보니, 구현 단계에서의 수정이 쉽지 않다.
그래서 커스터마이징이 필요한 사람들을 위해 Registerable, Validatable 같은 부가기능을 통해 커스터마이징을 하도록 하고 있지만 안타깝게 이마저도 쉽지 않다.  더욱이 문서 또한 레퍼런스가 아닌 API만 제공하다 보니 실제 Usage를 알기가 어렵다.

여러 부가기능 및 커스터마이징이 필요한 경우

Sorcery를 추천한다.
Sorcery는 Boilerplate가 없다고 봐도 무방하다. 그렇기 때문에 많은 부분들을 처음부터 쌓아올려야 한다.
별도의 수정 없이 사용할 때는 이게 그렇게나 귀찮고 짜증 나지만, 반대로 커스터마이징을 많이 해야 하는 경우 이처럼 좋을 수도 없다.
기본적인 건 다 Sorcery가 제공하고 그것들을 어떻게 사용할지는 내 입맛에 맞춰서 만들 수 있으니!!

권한 관리가 필요한 경우

Devise의 막강한 기능 중 하나가 CanCan, Rolify 같은 녀석들 때문이다.
CanCan은 권한 관리 Gem으로 페이지, Row(DB의 row) 단위로도 권한 설정이 가능하다고 한다. (실 서비스에 써본 적은 없다. 사용하려고 했는데, 커스터마이징을 너무 많이 해야 해서 그냥 하나 만들어서 사용했다)
CanCan은 Object에 대한 권한 관리라면, Rolify는 역할 관리라고 보면 된다. 예를 들자면 ‘유저’, ‘관리자’, ‘스텝’ 등으로 역할별로 권한을 관리할 때 사용하는 Gem이다.
(역시 실 서비스에 써본 적은 없다. Rolify가 등장하기 전에 이런 기능이 필요해서 만들어서 쓰고 있..)

암튼 이러한 녀석들이 공식적으로 Devise에 잘 붙는다고 적혀있고, 많은 사람들이 Devise + CanCan + Rolify 이렇게 트리플 콤보세트로 사용한다.

근데 CanCan, Rolify를 써보니 어랏? 딱히 Devise와의 Dependency가 안 보인다. 즉 Sorcery에서도 사용할 수 있을 것 같긴 한데.. 나중에 시간 나면 한번 해봐야겠다.
혹 해보신 분 계시면 알려주세요~!

정리

Sorcery Devise
소상공인 기업
가난하다 부자다
Screen Shot 2018-04-04 at 11.19.22 PM Screen Shot 2018-04-04 at 11.19.09 PM
로고도 없다 부자는 다르다.
가난해서 Boiler못킨다. 돈 많아서 Boilerplate가 빵빵하다
가난해서 감출게 없다. 많은 부분들이 감추어져 있다.
그래서 커스터마이징이 쉽다. 그래서 커스터마이징이 어렵다.
github wiki가 아주 깔끔하게 정리가 되어있어서 다른 문서 볼 필요가 없다.
Boilerplate와 설명까지 다 빵빵하다.
github wiki 또한 보기 어렵게 되어있다.
공식 문서는 API만 제공되고, Usage는 찾기 힘들다.
Boilerplate가 있긴 하지만 설명도 없고, Boilerplate를 어떻게 사용해야 하는지 알려주는 문서 또한 없다.
github wiki 페이지 수가 25개로 아주 깔끔하게 되어 있다.
(내가 만들거나 기여한 페이지들도 몇 개 있..읍읍)
github wiki 페이지 수가 130개다. 역시 부자는 다르다.

Sorcery를 오랫동안 사용하기도 했고, 기여도 해서 그런지.. 나도 모르게 글 자체가 Sorcery에 조금 더 편향되게 쓰여진것긴 한데.. 사실 아주 오래전 Devise를 주제로 글을 썼었다. 그것도 2개나! (언제까지 restful-authentication을 쓸것인가! devise도 써보자!devise에서 sign_out시 서버가 기절할 경우. (Ruby Or Rails Bug인듯))
블로그 이사하면서 양식이 다 깨져서 지금은 내용을 알아보기 힘들지만, 어쨌든 썼었다!

아, 그게 중요한 게 아니고.. 흠흠
둘 다 모두 검증된 Authentication 툴이니 믿고 사용하시길

Advertisements

간만에 Rails왔더니 Rails3로 업데이트가… #1

한동안 IPhone, IPad, Android 개발하다가, 잠들어 있던 개인프로젝트를 다시 시작할려고 맘을 먹었다.

Rails2 기반이어서, 깔끔하게 새로 만들자는 마음으로 Rails3를 설치를 했다.
Rails3로 넘어가면서 어떤것들이 바뀌었나 찾아보고 Railscasts도 보면서 틈틈이 학습을 해놓았지만..
역시 난관은 있었다.
내가 부닥쳤던 난관들을 정리해서 올리면, 어떤분은(한분이라도..) 도움을 받으시지 않을까 하는 소박한 희망에 몇자 끄적여본다.
이상하다. 문명히 예전에는 plugin install하고 script/generator 로 initialize를 했었는데..
Could not find generator authentiaceted.
이리저리 찾아봐도 별다른 말은 없고 technoweenie의 restful-authentication이 아닌 satin의 restful-authentication만 딸랑 링크가 걸려있다.
Sation의 restful-authentication의 install 설명을 봐도, 내가 한것과 틀린것이 없다.
아 뭐지 -ㅅ-;;
그러던 찰라
“아. technoweenie가 아직 Rails3 버전을 안맞들었고, Sation은 작업을 해놓은건가?” 라는 의문이 생기고..
Sation걸로 install을 하고 initialize하니 잘 된다.
하지만 막상 사용할려고 하면
uninitialized constant ApplicationController::AuthenticatedSystem

라고 한다.

include AuthenticatedSystem

require File.join(Rails.root, ‘lib’, ‘authenticated_system.rb’)
로 바꿔주니깐 되긴 하는데, lib아래 있는 모든 파일을 이렇게 불러올 수 는 없는 노릇.
뭔가 더 스마트한 방법이 있을것 같긴한데.. Railscasts에서 이 내용을 본것같아 이리저리 뒤져봐도 못찾고.
결국 구글링으로 알아냈다.
application.rb 에다가
config.autoload_paths << File.join(config.root, “lib”)
해주면 된다.
2. haml
예전에는 gem으로 설치하고, 그 후에 plugin install을 해줬어야 했다.
난 당연히 plugin install을 했는데, 왠걸 initialize가 제대로 안된다.
vendor/plugin/haml보니 init.rb은 있는데 0 bytes고..
haml을 initialize하면 생기는 파일은 init.rb 딸랑 하나인데, 이 녀석이 하는 일은 haml gem을 불러오는것 뿐이다.
그런데…..
Rails3부터 bundler가 추가되면서 Gemfile이라는게 생겼다, init.rb가 존재해야 할 명분이 사라져 버린것이다.
init.rb가 하던일을 Gemfile에 gem ‘haml’ 적어주면 끝나니 말이다.
Gemfile에
gem ‘haml’
을 적어주고,
$user> bundle install
하면 끝.
3. Routes => :path_prefix
내가 작업했던 수없이 많은 개인 프로젝트(오픈한것은 NA;;)들의 Routes에는 :path_prefix가 꼭 사용되었었다.
근데, Rails 3로 오면서 이녀석 Deprecated…..;;
혹시나 하는 마음에
scope “:user_login” do

해봤는데 안된다.

혹시나 하는 마음에 한번더 시도를 해보았는데
scope “(/:user_login)” do
이렇게 하니 된다.
예전에는 resources 하나하나 모두 :path_prefix를 적어주어야 하는 번거로움이 있었는데
이와 같은 방식으로 변해서, 보다 깔끔하게 코드를 작성할 수 있게 되었다.
ps. 작업하다 추가되는것들은 모아놨다가 또 포스팅할 계획임.
ps2. 한국루비사용자모임도 죽은지 오래.. 살아있는 Ruby Forum이 없는것 같은데.. 하나 만들까 -ㅅ-;
도메인은 사놓은게 있긴 한데..