This was already fixed in master. If not available in the latest gem, should be in the next release.

http://github.com/plataformatec/devise/blob/master/lib/devise/models/confirmable.rb#L130

If you need it now, you can vendor devise.

Take a look into Devise::Models::Confirmable:

http://github.com/plataformatec/devise/blob/master/lib/devise/models/confirmable.rb#L89

run rake test if you want to run just for activerecord. the shortcut rake will run rake pre_commit, which will tests all ORMs (datamapper in the future as well)

OK, I see!

You need to set the mailer sender:

http://github.com/plataformatec/devise/blob/master/generators/devise_install/templates/devise.rb#L46

Blame Rails for this terrible error message. I will set this mailer sender to a default value, something like: please-change-me@devise-config.com

Odd, but better than this weird error.

I modified the mailer sender, as seen on http://pastie.org/751644 (yep, I will rechange the secret after that :)

But I still get exactly the same error.

Odd, odd. :/

Try searching past issues, because this error already popped up here, and more than one time.

Yep, I've seen http://blog.plataformatec.com.br/2009/11/devise-authentication-for-lazy-programmers/comment-page-1/#comment-367 but I didn't find anything in the issues

Your application is fresh or an already existing one?

Fresh.

In fact, I had already defined this in environments/development.rb :

DeviseMailer.sender = "no-reply@yourapp.com"
config.action_mailer.default_url_options = { :host => 'localhost:3000' }

But now, I commented DeviseMailer.sender = "no-reply@yourapp.com" and added config.mailer_sender = "notifications@mastersieve.com" in devise.rb, and now it works.

This is one of them:

http://github.com/plataformatec/devise/issues/closed#issue/43

There was another similar issue, but I can't find it. The failure was due to another plugin monkey patching Rails (I think it was thinking_sphinx). So that's why it would be nice if you could try that in a fresh app :)

It is a fresh app, using mongo_mapper as the orm :)

this is sad :(
the same even if you use other ORM?

I don't think so. BTW, I try devise especially because of its mongo_mapper support !

This is odd. :/ There are people using MongoMapper with Devise successfully, I will ask on the mailing list for some of them to ping here to see if they have a clue.

Ok, the whole test suite now runs with MongoMapper and I cannot reproduce it. So I kindly ask you to try to reproduce the error in the test suite.

To execute MongoMapper tests, git pull and do:

DEVISE_ORM=mongo_mapper rake test

Thanks!

weird error, i'm using devise and mongo_mapper i've never seen this. I ran the rake task devise_install and configured the sender in the initializer setup block, not my environment.rb

I was just spending all day trying to chase down this error. It's a fresh app, only gem being used is devise.

One of the first things I coded was the spec.

User.create!(@valid_attributes)

It was throwing the error. Following the link josevalim posted worked. My issue was that I had DeviseMailer.sender = "no-reply@yourapp.com" in test.rb when I should have had config.mailer_sender = "foo.bar@yourapp.com" in the config/initializer/devise.rb

Since I was following the instructions blindly, I either followed them badly, or you guys should update the instructions accordingly .. but it was most likely my fault.

Ok, I set a default value for config.devise_mailer and removed the DeviseMailer.sender. I hope we can make this error disappear for good now! :)

Hahaha, this is the code a copied and pastied from skype that day. I wonder what kind of trash skype sent me. :P Going to fix it soon!

Fixed! :D

Which error are you getting? If mongo_mapper mimics validatable API, you should be able.

    ArgumentError: invalid options: scope
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/understandable.rb:27:in `must_understand'
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/validations/validation_base.rb:47:in `initialize'
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/validatable_class_methods.rb:66:in `new'
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/validatable_class_methods.rb:66:in `add_validations'
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/validatable_class_methods.rb:65:in `each'
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/validatable_class_methods.rb:65:in `add_validations'
        from /opt/ruby-enterprise-1.8.6-20090610/lib/ruby/gems/1.8/gems/jnunemaker-validatable-1.8.1/lib/validatable/macros.rb:49:in `validates_format_of'
        from /Users/mattmini/dev/ror/coupon/vendor/gems/devise-0.7.1/lib/devise/models/validatable.rb:23:in `included'
        from /Users/mattmini/dev/ror/coupon/vendor/gems/devise-0.7.1/lib/devise/models/validatable.rb:20:in `class_eval'
        from /Users/mattmini/dev/ror/coupon/vendor/gems/devise-0.7.1/lib/devise/models/validatable.rb:20:in `included'
        from /Users/mattmini/dev

You should ask mongo_mapper guys why they do not accept scope option in validates_uniqueness_of. However I will try to provide a fix that should work on 80% of the cases.

That was actually a bug. Fixed. Devise 0.7.3 released.

Hard to decided lookup.

Fixed.

<3. Thanks.

Probably because the controller is caching the resource. Have you tried doing:

@controller.instance_variable_set(:@current_user, nil)

And check if the problem persists?

yep, the problem persists

Fixed.

Thank you!
And thank you for Devise! :-)

Hello!
Devise already redirect the user to its home page (ie user_root_path) when you access the sign in page and the user is already signed in. You can also override the :after_sign_in_path_for method inside application controller to redirect the user to another action, or you can set a before filter to sessions controller like:

# Skip default before filter from devise if you don't want it
SessionsController.skip_before_filter :require_no_authentication
# Add your own before filter, define it inside application controller.
SessionsController.before_filter :my_filter, :only => [:new, :create]

You can put it inside an initializer.
That should do the trick.

Ok.

I hadn't realized that it was skipping to my root path because my root path is also the page where I have the login.

Thanks

Right. You're welcome..
I'd ask you to use google group to ask for help about doubts you may have, there other people are able to see and help too.
http://groups.google.com/group/plataformatec-devise
Thanks. Closing.

Fixed.

Won't solve the problem as well.

Done.

Devise just validate the reset password token when you really submit the edit password form. Then it shows you if your token is invalid or not, together with password validation, adding errors to your model.

Agreed with Carlos, closing.

Hello David,
We are not planning to create invitable right now, there are still some points to be checked before adding it.
However, you can take a look at http://wiki.github.com/plataformatec/devise/3rd-party-extensions. There is already an extension created that allows you using invitable, and also a facebook connection.
Thanks,
Carlos.

Oh great. I missed that. Thanks Carlos.

You're welcome. Closing.

Can't you update Devise::ALL? This line is needed to order modules.

Yes, even better!

Closing!

Sorry, too fast. xP

Close this, not an issue - but once again I can't delete issues. -_-

Hahah, no problem :)

Please send some code of what you are trying to achieve.

in ApplicationController:
class ApplicationController < ActionController::Base
[..] before_filter :check_permissions # uses current_user... [..] end

SessionsController should have a "skip_filter :check_permissions" because everyone should be able to logout/login...

I know i can copy the devise-sessions_controller to app/controllers and modify it but it feels wrong - so how can i "add" a skip-filter statement to the devise "SessionsController"?

Yeah, this is a Rails Engine issue. You can solve it in different ways, but none of them feels write. One of them is ensure that SessionsController is loaded before the filter is loaded:

class ApplicationController < ActionController::Base
  # common logic to SessionsController
  SessionsController
  # logic not shared with SessionsController
end

I would personally do this:

SessionsController.skip_before_filter :check_permissions

Thanks! - your code looks good but does not work with my authorization-solution (Aegis). I solved my issue by adding a "return if is_a?(SessionsController)" into the check_permissions-method of Aegis.

But would'nt it be nice to have a devise-config-option for adding/skipping filters, as others may have the same problem skipping e.g. the authorization in sessions_controller just as me?

I cannot think on how a configuration option should work. But you may want to change your filter to "return if devise_controller?", it returns true for all Devise internal controllers. :)

Ah, for future questions, please use the mailing list instead:

http://groups.google.com/group/plataformatec-devise

Thanks!

I guess this is not true. This is because the default failure message is :invalid, which is "Invalid email or password". Are you sure you added your facebook strategy in Warden default strategies?

Ah, which devise version are you using?

This is what I got in the Initializer:

config.all = [:facebook_connectable, :authenticatable, :confirmable, :recoverable, :rememberable, :timeoutable, :trackable, :validatable]

But warden.authenticate don't seems to enter my strategy. Using debugger I managed to see that :authenticable is enabled by default and ignores my devise :facebook_connectable instruction in the User model (I don't enable any other devise there). This is the deepest info I can get using the debugger:

(rdb:10) Devise::Mapping.find_by_path(request.path)

#"sign_in", :confirmation=>"confirmation", :password=>"password", :sign_out=>"sign_out"}, @as=:users, @for=[:authenticatable]>

...then I get:

(rdb:11) l
[-4, 5] in (eval)
*** No sourcefile available for (eval)

=P

OMG! :)

config.all is about devise modules. In the same initializer file, there is a config.warden piece. Please add the following:

config.warden do |manager|
  manager.default_strategies.unshift :facebook_connectable
end

Or add it to Devise::STRATEGIES constant.

I tried both (had to remove .freeze on Devise::STRATEGIES to try that one), none works for me. =(

A-ha (with a ?! suffix): Devise is for some reason loading :authenticable by default AND an extra one instead of :facebook_connectable always:

First I get these:

DEPRECATION WARNING: :authenticatable won't be included by default in devise in future versions, please add it. (called from /Users/grimen/Development/examples/devise_plugin/devise_example/app/models/user.rb:3)

then with Rails footnotes I see:

#"sign_in", :confirmation=>"confirmation", :password=>"password", :sign_out=>"sign_out"}, @as=:users, @for=[:authenticatable, :trackable, :authenticatable]>

...even though the only ones I enabled are :facebook_connectable and :trackable (just for testing what happens). See 2 x :authenticatable, but in the model only got :trackable and :facebook_connectable.

Oh yeah, sorry! Devise still forces the loading of authenticatable. I added the warning because we want to remove it in future versions. :( You will have to hack it or work on a Devise fork. :(

OK, thanks

Grimen, this was solved in 0.7.0, right?

Yes! Closing

Yup!

This is not supposed to be a Devise bug, but a Rails Engine bug. :( I will have to do some debugging to see why this happens. In the meanwhile, the other haml views works flawlessly?

OK, I see. Well this one can be handled by calling a HAML partial from that view, so I guess it's not critical like that. Just annoying. =)

Maybe there is something like template engine priority and you can set haml views to be used. I will try to come up with a Rails patch later.

Don't bother, I cannot reproduce this anymore. It must have been an issue with my extension at that time or something. =S

Ok!

The new bundler still have some issues with Rails. Rails, by default, uses require_dependency in all gems and plugins paths and load init.rb files, which does not happen when you use bundler. In other words, this is a bundler issue, not Devise.

Mate, can I ask you to add some failing tests on the test suite?

I'll have a look later today, trying to add failing tests

I just remembered you can configure all the given values. Have you tried the following:

map.devise_for :users, :scope => :user

It should solve the inflection trick. :)

I just forked your gem and added "config/initializers/inflections.rb" to the testsuite, now we have failing tests ;)

Your inflection-trick did not work - have a look at my devise_example-fork, i committed a not-working example with inflections & inflections-trick enabled...

I consider this a critical bug as it would affect everyone who uses inflections (which could be a lot of people, especially in non-english-speaking countries; in my company we develop most rails-apps with germanized models/attribute-names, so customizable inflections are a 'must-have' for us.

Ok, fixed and released Devise 0.6.3.

For some strange reason, calling Inflections make routes be loaded twice, messing with Devise load stack.

that was fast! keep the releases coming! ;)

Have you executed script/generate devise_install?

When you run this command, it will freeze your devise to only use the modules at Devise 0.6.0. For example, in Devise 0.6.2, we add "trackable", and since your Devise is not frozen, it was automatically added to your models. But everything is failing now, since you didn't added "trackable" to your migrations.

You have three fixes:

1) Revert to Devise 0.6.0, freeze it with script/generate devise_install, return to 0.6.2;

2) Keep 0.6.2 and add t.trackable to your migration

3) Keep 0.6.2 and add "devise :all, :except => :trackable" to your model

This is an API change, do @user.class.confirm_within instead, since this is a class configuration value.

In which scenario 0.days does not work properly? And in which devise version? I will fix that as soon as I have more details, but no plan on changing the api for a while. Thanks!

hey, sorry for the missing info. version is 0.6.2, scenario is, in a model configured as follows:

class User < ActiveRecord::Base
  devise :authenticatable, :validatable, :recoverable, :confirmable
end

I create a new record and then I'm able to login right after the user is created, even when config.confirm_within = 0.days. After I overwrite the confirmation_period_valid? method as described, I get the behavior I need.

Thanks for the info, but this is still odd. This is the confirmation period valid implementation:

    def confirmation_period_valid?
      confirmation_sent_at && confirmation_sent_at >= self.class.confirm_within.ago
    end

confirmation_sent_at is set before saving the user and confirm_within.ago when confirm_within is equal to 0.days is the same as Time.now. That should not return true in any condition, even more if we consider that the line below in irb returns false:

Time.now >= Time.now #=> false

So I think it may be a timezone issue. Can you try something along those lines in your application console:

User.create(valid_attributes).confirmation_sent_at >= 0.days.ago
User.create(valid_attributes).confirmation_sent_at >= 0.hours.ago
User.create(valid_attributes).confirmation_sent_at >= 1.hour.from_now
User.create(valid_attributes).confirmation_sent_at >= 1.hour.ago

All should return false, except for the last one.

Thanks! :)

Any feedback on this please?

hey, sorry, I was in a hurry and just left my workaround in place. I'll try to create a failing spec for this. I'll come back to you with the news later today.

Ok, I'm closing this one since I could not reproduce it. If you can reproduce it in the test suite or in devise_example (github.com/plataformatec/devise_example), please let me know. Thanks.

Try giving :path_prefix => "admin" instead. It should be almost the same as namespace, but without the adding admin_ to named routes (which wouldn't work anyway).

Looking at log:

Processing Admin::SessionsController#new (for 127.0.0.1 at 2009-11-23 19:13:37) [GET]
  Parameters: {"action"=>"new", "controller"=>"admin/sessions"}

ActionController::UnknownAction (ActionController::UnknownAction):
  devise (0.5.5) lib/devise/controllers/helpers.rb:50:in `is_devise_resource?'
  haml (2.2.13) rails/./lib/sass/plugin/rails.rb:19:in `process'
  warden (0.6.4) lib/warden/manager.rb:84:in `call'
  warden (0.6.4) lib/warden/manager.rb:84:in `call'
  warden (0.6.4) lib/warden/manager.rb:83:in `catch'
  warden (0.6.4) lib/warden/manager.rb:83:in `call'

Rendering rescues/layout (not_found)

If i set devise_for outside namespace this works fine

@josevalim

i tried but i got the same error:

map.devise_for :users, :path_prefix => 'admin', :controller => 'sessions'

Processing SessionsController#new (for 127.0.0.1 at 2009-11-23 19:18:00) [GET]

ActionController::UnknownAction (ActionController::UnknownAction):
  devise (0.5.5) lib/devise/controllers/helpers.rb:50:in `is_devise_resource?'
  haml (2.2.13) rails/./lib/sass/plugin/rails.rb:19:in `process'
  warden (0.6.4) lib/warden/manager.rb:84:in `call'
  warden (0.6.4) lib/warden/manager.rb:84:in `call'
  warden (0.6.4) lib/warden/manager.rb:83:in `catch'
  warden (0.6.4) lib/warden/manager.rb:83:in `call'

Rendering rescues/layout (not_found)

Just the following should work:

map.devise_for :users, :path_prefix => 'admin'

Hello, are you using a different encryptor than the defaul Sha1? To use a different encryptor, you must use a symbol that represents it (ie :sha1 or :sha512) in devise config file.

That was fixed! :) Thanks!

Not possible right now. And I don't think we are going to implement it any time soon (we are happy with the default). Fell free to stab a patch!

Hrm, we will stop using such methods then.

The same problem is with CouchRest too.

Awesome, just fixed and pushed!
Please report any other problem, so I can release a compatible gem soon! :)

this is what i have to do to get the datamapper to work in the user model

class User
include DataMapper::Resource class << self

def before_create method
end

def after_create method

end


def find(method, opts)

  first(opts[:conditions])


end

alias validates_presence_of       validates_present
alias validates_uniqueness_of     validates_is_unique
alias validates_format_of         validates_format
alias validates_confirmation_of   validates_is_confirmed
alias validates_length_of         validates_length

end

property :id, Serial property :username, String, :length => 255, :unique => true property :email, String, :index => true, :nullable => false, :length => 1000 property :encrypted_password, String, :length => 255, :nullable => false property :password_salt, String, :length => 255, :nullable => false property :confirmation_token, String, :length => 20 property :confirmed_at, DateTime property :confirmation_sent_at, DateTime property :reset_password_token, String, :length => 20 property :remember_token, String, :length => 20 property :remember_created_at, DateTime

extend Devise::Models

devise :all

def confirmed_at?

confirmed_at

end

def confirmation_sent_at?

confirmation_sent_at

end

def remember_token?

remember_token

end def save(flag = nil)

super()

end end

most noteworth things are the before_save and after_save callback, find, and save(false)

just take care of those and you will have a compatible gem hehe.


class User
include DataMapper::Resource class << self

def before_create method
end

def after_create method

end


def find(method, opts)

  first(opts[:conditions])


end

alias validates_presence_of       validates_present
alias validates_uniqueness_of     validates_is_unique
alias validates_format_of         validates_format
alias validates_confirmation_of   validates_is_confirmed
alias validates_length_of         validates_length

confirmed_at

confirmation_sent_at

remember_token

super()

Awesome! Just updated once again.

Can you please install Devise as a plugin and try to use it with Datamapper? The required steps are:

1) Install Datamapper
2) ruby script/generate devise_install
3) Change config.orm = :data_mapper in "config/initializers/devise.rb"
4) Change your model above to the following:

class User
  include DataMapper::Resource
  property :id, Serial

  alias validates_presence_of       validates_present
  alias validates_uniqueness_of     validates_is_unique
  alias validates_format_of         validates_format
  alias validates_confirmation_of   validates_is_confirmed
  alias validates_length_of         validates_length

  devise :all
  has n, :external_accounts has 1, :facebook_account
  accepts_nested_attributes_for :facebook_account
end

I tried to handle everything in Devise, except the validations, which won't be added unless you define aliases by hand.

Just added. Run "script/generate devise_install" and set the config.scoped_views options to true. Have fun!

Of course, don't forget to install new devise version before!

@josevalim: A very elegant solution, thank you!

Can you duplicate this bug running devise example at http://github.com/plataformatec/devise_example ?

I find it!
It hapens when
DeviseMailer.sender = "no-reply@yourapp.com" is defined in environments/development.rb
Where I should write it?

Hello!
You should remove this config (it's from old versions) and run the following generator:

ruby script/generate devise_install

This generator will copy a config file under your config/initializers named devise.rb.. There you can setup your mail sender:

config.mailer_sender = "foo.bar@yourapp.com"

Let us know if it works.

It works, yeah. Thank you!
Please, update your README to prevent this mistake with new users.

Glad to help.
Our mistake, it really shouldn't be there anymore. I will do it as soon as possible.
Thanks.

config.mailer_sender is just a wrapper to DeviseMailer.sender:

http://github.com/plataformatec/devise/blob/master/lib/devise.rb#L89

I guess it's not the issue, unless I'm missing something. :(

Ok... I'm closing this.

Fixed! If you find more issues with Datamapper, please let me know I will fix them ASAP!

Maybe you can fork the project and create an orm for Datamapper in lib/devise/orm/ as well? Feel free to add me on gtalk at jose dot valim at gmail.

Sorry - this issue was posted twice.

Just include Devise::TestHelpers and make use of sign_in and sign_out helpers! :)

Duplicated :)

This is the same thing if I try to use authenticate_user!

http://pastie.org/708349

Hello,

I'm testing my application with cucumber and I have some trouble getting the current_user to be created. I tried using the sign_in method in my steps definitions but it fails... Anyone had a chance to make this work with cucumber ?

Thx

The sign_in method in Devise::TestHelpers should be used in functional tests, where you need mocking. To sign in your users in integrations tests, just go to the sign page and fill in the form (it's an integration test!) or store the user direct in session (works for webrat, but not for selenium, culerity...).

I just pushed a patch that tries to fix it. Could you please reinstall Devise 0.5.5 and give it a try?

Your patch got me one step further, but there were more missing constants.

So what I did was:

add

require 'devise/schema'

to orm/active_record.rb

also add

require 'devise/mapping'
require 'devise/controllers/filters'
require 'devise/controllers/url_helpers'

to rails/routes.rb

After that, script/server was no longer complaining and rake db:migrate was running as well.

Not sure this is the right way to do it, but it worked for me so far. I just wonder why not anyone else seems to experience this.

Are you using Bundler?

Just re-released 0.5.5 again. Can you try one more time please?

No, not using Bundler.

But I got another error after adding

map.devise_for :users

to my routes.rb:

% script/server => Booting WEBrick => Rails 2.3.4 application starting on http://0.0.0.0:3000 /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/base.rb:1959:in method_missing_without_paginate': undefined methoddevise' for #<Class:0x2b1e852e6610> (NoMethodError)

    from /home/cjk/work/hot/hotrails/vendor/gems/mislav-will_paginate-2.3.11/lib/will_paginate/finder.rb:170:in `method_missing'
    from /home/cjk/work/hot/hotrails/app/models/user.rb:2
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:380:in `load_without_new_constant_marking'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:380:in `load_file'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:379:in `load_file'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:259:in `require_or_load'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:425:in `load_missing_constant'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:80:in `const_missing'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:92:in `const_missing'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/inflector.rb:361:in `constantize'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/inflector.rb:360:in `each'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/inflector.rb:360:in `constantize'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/core_ext/string/inflections.rb:162:in `constantize'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/mapping.rb:80:in `to'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/mapping.rb:74:in `for'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/rails/routes.rb:98:in `devise_for'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/core_ext/object/misc.rb:78:in `with_options'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/rails/routes.rb:97:in `devise_for'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/rails/routes.rb:90:in `each'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/rails/routes.rb:90:in `devise_for'
    from /home/cjk/work/hot/hotrails/config/routes.rb:3
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/routing/route_set.rb:226:in `draw'
    from /home/cjk/work/hot/hotrails/config/routes.rb:1
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:145:in `load_without_new_constant_marking'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:145:in `load'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:145:in `load'
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/routing/route_set.rb:286:in `load_routes_without_devise!'
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/routing/route_set.rb:286:in `each'
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/routing/route_set.rb:286:in `load_routes_without_devise!'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/rails/routes.rb:12:in `load_routes!'
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/routing/route_set.rb:266:in `reload!'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:537:in `initialize_routing'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:188:in `process'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:113:in `send'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:113:in `run'
    from /home/cjk/work/hot/hotrails/config/environment.rb:12
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/commands/server.rb:84
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from script/server:3

My user-model looks like this (and works without the route):

class User < ActiveRecord::Base
devise :all, :except => :confirmable end

This is completely odd. It seems that you load stack is not working properly because devise with Rails 2.3.4 works properly here. Are you using config.threadsafe! then?

After applying your latest patch, "uninitialized constant Devise::Encryptors" is back:

... => Rails 2.3.4 application starting on http://0.0.0.0:3000 /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:440:in `load_missing_constant': uninitialized constant Devise::Encryptors (NameError)

    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:80:in `const_missing'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise.rb:58
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/rails/gem_dependency.rb:208:in `load'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:307:in `load_gems'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:307:in `each'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:307:in `load_gems'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:164:in `process'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:113:in `send'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/initializer.rb:113:in `run'
    from /home/cjk/work/hot/hotrails/config/environment.rb:12
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/commands/server.rb:84
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from script/server:3

Sorry, but such errors makes no sense. Can you send us your ruby version, rails and gems/plugins? Somone is messing up with Rails load process along the way. You should have the devise method available in your models (it's added in a after_initializer hook) before the routes are loaded, as we can see in Rails source code: http://github.com/rails/rails/blob/2-3-stable/railties/lib/initializer.rb#L126

Finally, could you please ensure that a init.rb is in your gem/plugin root folder?

No, not using config.threadsafe! either. I think my config is pretty standard.

But strange indeed. Never had such problems with my app so far.

The only non-standard rails-code running from the stack-traces seems to be "will_paginate".

Do you have this running as well?

Once I put back

require 'devise/encryptors/sha1'

into devise.rb it starts working until of course I put in the map.devise_for route.

The error then is as stated above:

/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/base.rb:1959:in method_missing_without_paginate': undefined methoddevise' for #<Class:0x2ba0cb86b950> (NoMethodError)

    from /home/cjk/work/hot/hotrails/vendor/gems/mislav-will_paginate-2.3.11/lib/will_paginate/finder.rb:170:in `method_missing'
    from /home/cjk/work/hot/hotrails/app/models/user.rb:2
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:380:in `load_without_new_constant_marking'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:380:in `load_file'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:379:in `load_file'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:259:in `require_or_load'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:425:in `load_missing_constant'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:80:in `const_missing'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/dependencies.rb:92:in `const_missing'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/inflector.rb:361:in `constantize'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/inflector.rb:360:in `each'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/inflector.rb:360:in `constantize'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/core_ext/string/inflections.rb:162:in `constantize'
    from /home/cjk/work/hot/hotrails/vendor/gems/devise-0.5.5/lib/devise/mapping.rb:80:in `to'

...

Please try running the devise_example at http://github.com/plataformatec/devise_example.>

Can you send us your ruby version, rails and gems/plugins? Somone is messing up with Rails load process along the way.

ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]

Rails is v2.3.4

Gems/plugins from environment.rb:

... config.gem "warden" config.gem "devise"

config.gem 'mislav-will_paginate', :version => '~> 2.3.8', :lib => 'will_paginate', :source => 'http://gems.github.com' config.gem "rich-acts_as_revisable", :lib => "acts_as_revisable", :source => "http://gems.github.com"

config.gem "zilkey-active_api", :lib => "active_api", :source => "http://gems.github.com"

config.plugins = [ :haml, :state_machine, :"thinking-sphinx", :"acts-as-importable" ] ...

Finally, could you please ensure that a init.rb is in your gem/plugin root folder?

There is an init.rb in vendor/gems/devise-0.5.5/

Thanks a lot for your help so far.

Well, the devise_example app is running fine.

Though it's using different versions of warden / devise - could this make a difference?

Update: When I disable all my plugins (not gems) it starts working!

I tracked it further down to the thinking-sphinx plugin. But once I install all my plugins as gems, it works as well!

Even the load-order seems to make a difference.

Anyway, I'll need to analyse this further and so far it seems like devise is not the cause, but perhaps a symptom.

Thanks again for your support on this issue, please consider it solved so far.

I have a similar issue whereby I am requiring warden in a sinatra app and getting "NameError: uninitialized constant Warden".

I am doing:

require 'rubygems'
require 'sinatra/base'
require 'warden'

class Warden::Serializers::Session
  def serialize(user)
    user.id
  end

  def deserialize(key)
    User.get(key)
  end
end

iq,

not sure how warden and sinatra are supposed to get along.

I fixed my problem by changing the order of the required gems and get rid of all plugins (applies to Rails only).

If that doesn't work for you, you could try to add extra 'require ...' statements in devise where needed, as perhaps sinatra does autoloading different from Rails.

good luck,
Claus

Thanks Claus, the only way I could get around it was to manually require all parts of warden i.e:

require 'warden'
require 'forwardable'
require 'warden/mixins/common'
require 'warden/proxy'
require 'warden/manager'
require 'warden/errors'
require 'warden/strategies'
require 'warden/strategies/base'
require 'warden/serializers'
require 'warden/serializers/base'
require 'warden/serializers/cookie'
require 'warden/serializers/session'

It does not make sense :( Or you are using Bundler, or you are using something that is messing with Rails load path (maybe config.threadsafe!)?

Just released a new version 0.5.5!

It works! You're the man. Go grab yourself a sandwich! :)

Right now you're able to change the behavior of redirects using an admin_root_path instead of root_path like your example. Devise will always look for a namespaced route before redirecting to root_path. This just works while signing a user in, reseting his password or confirming his account. However, after destroying a user the redirect will always be to root_path. Do you fell you'll need to change any other default behavior besides this?
Perhaps we can create a way to overwrite the redirect to root_path while signing a user out, as a specific route. What do you think?

Ok, right now, if you need to configure the sign out path, just overwrite the after_sign_out_path_for in your ApplicationController. Closing!

@carlosantoniodasilva: Yes, I would like to change the behavior if possible. In my application, it makes sense for a user to be redirected to the "real" root_path, i.e., the home page of the public-facing application, but I would like admins to get redirected to their own "backend" home page, i.e., admin_root_path. In fact, maybe the answer is to change the last line of SessionsController#destroy to:

redirect_back_or_to home_or_root_path

as is used in SessionsController#create. Would that have any unwanted side effects?

@josevalim: Thanks for the tip, but I'm afraid I don't understand how to do this. First, I couldn't find this variable anywhere in Devise--is it a hook? And second, what would the syntax be? Sorry if it's a stupid question!

This is a hook just added to Devise. Install devise 0.5.4 and do in your application controller:

  def after_sign_out_path_for(resource_or_scope)
    case resource_or_scope
      when :admin, Admin
        your_special_path
      else
        root_path
    end
  end

Just replace your_special_path with the path you want and that should do the trick!

@josevalim: Thanks for such a quick fix! That's just what I needed.

Devise already handles that:

http://github.com/plataformatec/devise/blob/master/lib/devise/models/validatable.rb#L36

If you don't want to validate password, ensure that password attributes are discarded if they are blank or use two forms: one for updating attributes and other for updating password as in devise_example.

You could move that to Devise.friendly_token. Can you please try out a patch?

Done.

That was supposed to work, try doing some debug on devise/rails/routes.rb

It would but Mapping.initialize has:

      options.assert_valid_keys(:class_name, :as, :path_names, :singular, :path_prefix)

which kicks back that :conditions isn't valid

Updated, try pulling it out as a plugin.

That did it.

Awesome! I'm closing now, expect a new release in the next week!

Hello, could you please try updating your plugin and see if everything is still working?
I've made some changes to ensure options (ie :conditions) are passed to devise routes, so in your scenario, employees will only be able to sign in inside a subdomain, and not the root domain.

We have no support for MongoMapper yet. I would suggest you to ask in the mailing list, there are some folks there working on it.

Hi, I use Devise with CouchRest successfully. I think it will be the same situation here so you just need to extend your class using extend Devise::Models.

Jose Valim: Are you interesting in a devise example app with CouchRest? I'm able to make it. :)

Please do! We are going to support mutliple ORMs, the more examples, the best! Are you following our mailing list?

http://groups.google.com/group/plataformatec-devise

Thanks!

Devise relies on Rails require_dependency, which bundler does not use. require_dependency knows that Devise::Controllers::Filters is available at "devise/controllers/filter" and loads that file automatically. Using bundler, that file cannot be loaded and should be required manually.

After a talk with Yehuda, we agreed that the bundler preinitializer for Rails 2.3 needs to be improved, something along those lines might make it work:

require "#{File.dirname(__FILE__)}/../vendor/bundler_gems/environment"

Gem.loaded_specs.values.each do |spec|
  require_dependency File.expand_path("lib", spec.full_gem_path)
  init = File.expand_path("init", spec.full_gem_path)
  require init if File.exists?(init)
end

I've tried the code and it failed on:

c:\dev\MUNI\Bakalarka\portfonica>ruby script\server
c:/dev/MUNI/Bakalarka/portfonica/config/../config/preinitializer.rb:6:in `block in ': undefined method `require_dependency' for main:Object (NoMethodError)
        from c:/dev/MUNI/Bakalarka/portfonica/config/../config/preinitializer.rb:5:in `each'
        from c:/dev/MUNI/Bakalarka/portfonica/config/../config/preinitializer.rb:5:in `'
        from c:/dev/MUNI/Bakalarka/portfonica/config/boot.rb:28:in `load'
        from c:/dev/MUNI/Bakalarka/portfonica/config/boot.rb:28:in `preinitialize'
        from c:/dev/MUNI/Bakalarka/portfonica/config/boot.rb:10:in `boot!'
        from c:/dev/MUNI/Bakalarka/portfonica/config/boot.rb:110:in `'
        from script/server:2:in `require'
        from script/server:2:in `'

Hrm, so try it at the end of config/environment.rb.

It has not helped, it returns the same problem like in my first report.

But It is okay. It seems to be a problem in Bundler, so sorry for reporting here :).

No problem. Just one more try. Instead of "require_dependency" try "ActiveSupport::Dependencies.require_dependency" or simple adding it to load path "ActiveSupport::Dependencies.load_path <<".

Hi!

I'm in the same problem, my configuration is the following:
boot.rb (at the end) # To run with passenger

class Rails::Boot
def run

load_initializer
extend_environment
Rails::Initializer.run(:set_load_path)

end

def extend_environment

Rails::Initializer.class_eval do
  old_load = instance_method(:load_environment)
  define_method(:load_environment) do
    Bundler.require_env RAILS_ENV
    old_load.bind(self).call
  end
end

end end

preinitializer.rb

require "#{RAILS_ROOT}/vendor/bundled_gems/environment"

And I'm tried all your options but nothings happens, I've received the following errror:

undefined method devise' for #<Class:0x7fb972d37448><br/> /home/pacoguzman/dev/my_github/tmp/devise/vendor/bundled_gems/gems/activerecord-2.3.5/lib/active_record/base.rb:1959:inmethod_missing' /home/pacoguzman/dev/my_github/tmp/devise/app/models/user.rb:2

Thanks

I just noticed the code above was wrong, here is the proper version:

require "#{File.dirname(FILE)}/../vendor/bundler_gems/environment"

Gem.loaded_specs.values.each do |spec|
require_dependency File.expand_path("lib", spec.full_gem_path) init = File.expand_path("init", spec.full_gem_path) require init if File.exists?("#{init}.rb") end

If this does not work, try doing require "devise" in your initializer/preinitializer. If that does not work, I do not know how to help any longer. This is more a bundler issue though.

You should be able to obtain that declaring a named route after devise_for:

map.user_confirmation '/users/confirmation/:confirmation_token', :controller => 'confirmations', :action => 'show'

Sorry, Github sent the message without finishing. I just want to add that we have no plans in changing that in Devise. :)

Marcelo,
Just merged. Thank you for your excellent work! :)

We pushed a fix to Warden and to Devise. New version should be released soon. Thanks!

Done!
Added sign_in(@resource), sign_out(@resource) and stored_location_for(@resource).

I just tried in my computer, using Devise 0.4.2:

rails foo
cd foo
script/generate devise_install

And it worked. It was supposed to work on devise 0.4.1 as well, but try upgrading it to check if it's broken for you or on 0.4.2 as well.

Hi Jose,

thanks for the quick reaction.

Sadly, upgrading to 0.4.2 did not resolve the problem:

$ rails foo && cd foo
$ script/generate devise_install
Couldn't find 'devise_install' generator

Sorry for the inconvenience ...

This is quite odd that it's not working. Which rails are you using? (It won't work with Rails 3/edge...)

I am using

• Devise 0.4.2
• Warden 0.5.1
• Rails 2.3.4
• ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9]
• MacOS X 10.5.8

I do not use Rails Edge or Rails 3 ( I am not that fancy ... :-D )

BTW: If this only affects me, then please do not bother. Devise is a great piece of code, and you should invest your time into perfecting and extending it.

Hello,
I've also tried it here the same way you did:

rails foo && cd foo
script/generate devise_install

And everything is fine.. Have you already tried adding warden and devise to your config.gem before running "script/generate devise_install"?

Hi Carlos,

yes, the config.gem lines are in my environment.rb. Devise as such is working, I am able to login and manage user data. It is just that I cannot use the generator to create the devise initializer like everybody else seems to do ... :-(

It seems odd... as we can't reproduce here.. are all others Devise generators working fine?

I know it is odd. I even removed the gems (Warden and Devise) and re-installed them. And yes, all other generators work fine, including

script/generate devise User

Thanks!

Hi everyone, I just scrapped all my gems and reinstalled them via the corresponding rake task. Suddenly, everything works fine.

Strange, but not unwelcomed ... :-D

Thanks for your time, anyway!

Great it's working now!
You're welcome..
Closing....

Hey, I think there are other thing that won't work on Rails 3 as well, as routes definition.

I worked on Rails 3 callbacks, so in theory, the API should be the same. Which error are you getting?

Hi,
maybe I wasn't clear, sorry. CouchRest uses Rails 3 callbacks:
http://github.com/mattetti/couchrest/blob/master/lib/couchrest/mixins/callbacks.rb

I'm using Rails 2.3 with CouchRest and Devise. My code fails on before_create method which is calling inside Models::Confirmable mixin. CouchRest uses Rails 3 callback such as create_callback :before instead. But I did a hack using own mixin which makes a bridge between those callbacks without broken Devise or CouchRest code.

Understood ;) I would suggest you to define and after_create and before_create callbacks (which I think you already done), so everything should work as expected. :)

Thanks your advice, but you need to define those callbacks before including Devise::Models::Confirmable mixin. :)

I think any initializer is executed before the mixin is included.

Notifier.sender is invalid (I will fix it). The other to are valid, but I think the last one should be renamed to config.mailer_sender. Wdyt?

Fixed!

Perfect.

Even if you set the locale in default_url_options?

def default_url_options
  { :locale => I18n.locale }
end

Yes, same result.
One strange thing (maybe due to a redirect) is that if you F5 the page the problem doesn't reproduce.

Ok, so in order to fix that, could you please fork devise_example at github.com/plataformatec/devise_example and explain me what I need to do to reproduce the error?

I was able to get it working on devise_example. I defined:

map.user_root 'admin/dashboard', :controller => 'admin/dashboard', :path_prefix => '/:locale'

And then in my application controller:

def default_url_options
{ :locale => I18n.locale } end

I will have a check and let you know as soon as possible ;)

Hi, Jose, It was my mistake!
instead of simply using link_to "Dashboard", user_root_path I was passing an additional argument (I18n.locale) to the path: link_to "Dashboard", user_root_path(I18n.locale)

I'm sorry

Keep doing the good work ;)

No problem, closing this one ;)

Anyway I found this:
https://rails.lighthouseapp.com/projects/8994/tickets/1251-default_url_options-cant-be-used-with-named-routes

I think my issue was referable to the linked topic, I was trying to do something that isn't supported yet ;)

Bye

Please update your migration to use t.authenticatable instead of t.authenticable. There was a version with deprecations, I guess you missed it.

Actually, now I realized that the migration in generator was outdated. Already fixed. Please reinstall devise 0.4.1. Thanks!

Cool updated it, appreciate all your work - really impressive. I will try to be more helpful and dig to the issue next time.

Thanks! Closing this issue as well :)

Yeah, actually this breakage makes sense. I'm going to fix it and release a new gem soon.Thanks!

Fixed and released 0.4.1. Thanks!

Done.

Sorry Gavin, but it's not clear for me. You want a method that does it? A view?