Em 25-05-2011 08:03, Rodrigo Rosenfeld Rosas escreveu:
Hi, just want to talk about the status of the migration to Devise.
I've been learning about Gitorious authentication, Devise and Warden
lately.
Here is part of what I learned:
Devise is built upon Warden. Warden is a Rack middleware that is
lazily loaded through a lazy object available at env.request['warden']
for a Rack application.
It allows different applications in the same Rack stack to share a
common authentication system.
You can authenticate using Warden with
env.request['warden'].authenticate(:passord, :another_strategy, :etc).
This will try the Password strategy, then AnotherStrategy if the prior
was not successful, etc. Devise actually uses
warden.authenticate(:scope => :user) in the case of Gitorious. Warden
supports authentication for different scopes and Devise supports
scopes :user and :admin, although I'm only considering a single scope
(:user) for Gitorious at the moment.
The strategies used are set in Devise config, which delegate to Warden
manager through a default_strategies method.
Continuing...
In this first step, I'm migrating to Devise 1.0.10, which is compatible
with Rails 2. When we upgrade Gitorious to Rails 3 we upgrade Devise to
the newest version.
For this Devise, the default strategies, in order, are: [:rememberable,
:http_authenticatable, :token_authenticatable, :database_authenticatable]
Gitorious needs something like: [:rememberable, :http_authenticatable,
:openid, :database_authenticatable], unless I'm forgetting something.
The OpenID strategy is not present in Devise 1.0, but there is a gem for it:
https://github.com/nbudin/devise_openid_authenticatable
This gem won't work in newest Devise, but the good news is that newest
Devise supports OmniAuth, which supports OpenID and several other
authentication systems like LDAP, Google Apps, Twitter, LinkedIn,
YouTube, GitHub, Facebook. See the complete list here:
https://github.com/intridea/omniauth
That is all fantastic when it is finished, but I'm a bit far of
finishing it right now. There is a lot of things to do yet.
I need to get rid of the SessionsController and think what to do about
its functional tests. I think we should move it to integration tests.
Can I add the capybara gem dependency to tests?
Also, I guess the only reason for Gitorious to set the "_logged_in"
cookie is to easy the functional tests for they knowing if the user was
correctly authenticated. I don't like this approach very much and I'm
going to remove it if that is ok with you. This could be set adding a
Warden hook after successful authentication, but I really don't think
this is a great approach for testing this. In the integration tests,
I'll try to do something like this:
in setup:
get '/logout' # don't remember exactly the URL...
in the test:
try_to_log_in_with_some_method
check_for_presence_of login_name
Or something like that... I've noticed that Gitorious tests used to be
specs using Rspec sometime in the past. Then, there was one commit
converting them all to Shoulda. Is there any reason why RSpec was
dropped? I really like to read specs because they are clearer to me. For
instance:
non_admin_user.should_not be_allowed_to_view('/admin')
And then, adding a custom RSpec matcher for BeAllowedToView.
Getting back to strategies, the rememberable strategy will store the
cookie for 2 weeks by default in Devise, which is the same period
Gitorious currently use. Should I make this time span explicit in Devise
config of is it ok for Gitorious to rely on Devise's default? Also, I
needed to change the field names to use the "user" scope. For instance,
<input name="email"> should be changed to <input name="user[email]">.
Gitorious currently use the "auth_token" cookie for storing this
setting, but I'll change it to "authenticated_user_token" (or something
like that), which is used by the :rememberable strategy implemented by
Devise for avoiding creating another strategy just for maintaining the
same cookie name. Also, Devise 1.0 won't set the cookie as secure I
guess. But I'm not worried with it right now since the newest Devise
support passing options to generated cookies in Devise config, so we can
do that later after migrating to Rails 3 and newest Devise. If Devise is
going to be merged into master before we convert Gitorious to Rails 3,
we'll probably need to replace the Rememberable strategy with a custom
one anyway for keeping the cookie secure... I'll take a closer look at
this later...
This is another thing I would like to talk about: timing for merging
this. If we keep such a big change in a separate branch for a long
while, it will be very hard to rebase or merge it with master as the
time passes. It would be great if we could integrate it as soon as
possible to master once it is finished. Is it possible?
I'll keep you updated of this progress.
--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com
