I''ve just adapted the original salted hashed login generator tests for
the login engine, such that we can now run tests against it and verify
that it behaves nicely, in the same way that you might test any Rails
plugin:
$ rake test_plugins # ensuring your test database it set up, etc etc
All the tests pass except one - "test_change_password_with_bad_email".
This test is meant to simulate a user who is trying to change their
password, but where the email to notify them cannot be sent. From what
I can tell, despite the password update being wrapped in a transaction
(user_controller.rb, line 69 in the latest revision) which should get
rolled back upon the mail-related exception, the password when the
controller action exits has actually been changed! I can''t replicate
this behaviour in the console, so I''m throwing it out to some
entreprising plugin debugger out there on the interwebs.
Anyone got any ideas?
- james
------ code snippet follows -----
def change_password_for(user, params)
begin
User.transaction(user) do
user.change_password(params[:user][:password],
params[:user][:password_confirmation])
if user.save
#@user.reload
#puts "changed password: #{@user.salted_password}"
if LoginEngine.config(:use_email_notification)
# ---> the exception gets thrown on the next line
UserNotify.deliver_change_password(user, params[:user][:password])
flash[:notice] = "Updated password emailed to
#{@user.email}"
else
flash[:notice] = "Password updated."
end
# since sometimes we''re changing the password from within
another action/template...
redirect_to :action => params[:back_to] if params[:back_to]
else
end
end
rescue
# ---> this is where we should land after the exception, and the
transaction should roll back
# ---> but the password seems to be changed.
flash[:warning] = ''Password could not be changed at this time.
Please retry.''
end
end
James, Here''s an an obvious question, but are you using InnoDB tables (assuming you are using MySQL)? Joe On Nov 9, 2005, at 12:59 PM, James Adam wrote:> I''ve just adapted the original salted hashed login generator tests for > the login engine, such that we can now run tests against it and verify > that it behaves nicely, in the same way that you might test any Rails > plugin: > > $ rake test_plugins # ensuring your test database it set up, etc > etc > > All the tests pass except one - "test_change_password_with_bad_email". > This test is meant to simulate a user who is trying to change their > password, but where the email to notify them cannot be sent. From what > I can tell, despite the password update being wrapped in a transaction > (user_controller.rb, line 69 in the latest revision) which should get > rolled back upon the mail-related exception, the password when the > controller action exits has actually been changed! I can''t replicate > this behaviour in the console, so I''m throwing it out to some > entreprising plugin debugger out there on the interwebs. > > Anyone got any ideas? > > - james > > > ------ code snippet follows ----- > > def change_password_for(user, params) > begin > User.transaction(user) do > user.change_password(params[:user][:password], > params[:user][:password_confirmation]) > if user.save > #@user.reload > #puts "changed password: #{@user.salted_password}" > if LoginEngine.config(:use_email_notification) > # ---> the exception gets thrown on the next line > UserNotify.deliver_change_password(user, params[:user] > [:password]) > flash[:notice] = "Updated password emailed to # > {@user.email}" > else > flash[:notice] = "Password updated." > end > # since sometimes we''re changing the password from within > another action/template... > redirect_to :action => params[:back_to] if params > [:back_to] > else > end > end > rescue > # ---> this is where we should land after the exception, and the > transaction should roll back > # ---> but the password seems to be changed. > flash[:warning] = ''Password could not be changed at this time. > Please retry.'' > end > end > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 11/9/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote:> James, > > Here''s an an obvious question, but are you using InnoDB tables > (assuming you are using MySQL)? > > Joe > > On Nov 9, 2005, at 12:59 PM, James Adam wrote: > > > I''ve just adapted the original salted hashed login generator tests for > > the login engine, such that we can now run tests against it and verify > > that it behaves nicely, in the same way that you might test any Rails > > plugin: > > > > $ rake test_plugins # ensuring your test database it set up, etc > > etc > > > > All the tests pass except one - "test_change_password_with_bad_email". > > This test is meant to simulate a user who is trying to change their > > password, but where the email to notify them cannot be sent. From what > > I can tell, despite the password update being wrapped in a transaction > > (user_controller.rb, line 69 in the latest revision) which should get > > rolled back upon the mail-related exception, the password when the > > controller action exits has actually been changed! I can''t replicate > > this behaviour in the console, so I''m throwing it out to some > > entreprising plugin debugger out there on the interwebs. > > > > Anyone got any ideas? > > > > - jamesPostgresql doesn''t allow nested transactions, so you have to disable transactional fixtures for methods using transactions themselves. class MyTest < Test::Unit::TestCase uses_transaction :test_foo def test_foo end # tests..... end I discovered this ages ago (in Rails time), so does anyone know if there is a better way to do this? -- rick http://techno-weenie.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 9, 2005, at 11:34 AM, Rick Olson wrote:> Postgresql doesn''t allow nested transactions, so you have to disable > transactional fixtures for methods using transactions themselves. > > class MyTest < Test::Unit::TestCase > uses_transaction :test_foo > > def test_foo > end > > # tests..... > end > > I discovered this ages ago (in Rails time), so does anyone know if > there is a better way to do this?You nailed it. Another way is to segregate the tests which specifically need to check the results of a rollback into another test case which has disabled transactional fixtures. jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDcmaUAQHALep9HFYRAlIdAKChZBQty9B4Px59iOWrRbHDPJCo2gCfaayt pGgJDQYAsPtxkett1lYIvSo=4Cgw -----END PGP SIGNATURE-----
To the best of my knowledge the schema.rb file is creating InnoDB tables, yes - that was one of the first things I checked. What struck me as most odd is that the method appears to work from the console.... Any other ideas? It would be great to see all tests passing... On 11/9/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote:> James, > > Here''s an an obvious question, but are you using InnoDB tables > (assuming you are using MySQL)? > > Joe > > On Nov 9, 2005, at 12:59 PM, James Adam wrote: > > > I''ve just adapted the original salted hashed login generator tests for > > the login engine, such that we can now run tests against it and verify > > that it behaves nicely, in the same way that you might test any Rails > > plugin: > > > > $ rake test_plugins # ensuring your test database it set up, etc > > etc > > > > All the tests pass except one - "test_change_password_with_bad_email". > > This test is meant to simulate a user who is trying to change their > > password, but where the email to notify them cannot be sent. From what > > I can tell, despite the password update being wrapped in a transaction > > (user_controller.rb, line 69 in the latest revision) which should get > > rolled back upon the mail-related exception, the password when the > > controller action exits has actually been changed! I can''t replicate > > this behaviour in the console, so I''m throwing it out to some > > entreprising plugin debugger out there on the interwebs. > > > > Anyone got any ideas? > > > > - james > > > > > > ------ code snippet follows ----- > > > > def change_password_for(user, params) > > begin > > User.transaction(user) do > > user.change_password(params[:user][:password], > > params[:user][:password_confirmation]) > > if user.save > > #@user.reload > > #puts "changed password: #{@user.salted_password}" > > if LoginEngine.config(:use_email_notification) > > # ---> the exception gets thrown on the next line > > UserNotify.deliver_change_password(user, params[:user] > > [:password]) > > flash[:notice] = "Updated password emailed to # > > {@user.email}" > > else > > flash[:notice] = "Password updated." > > end > > # since sometimes we''re changing the password from within > > another action/template... > > redirect_to :action => params[:back_to] if params > > [:back_to] > > else > > end > > end > > rescue > > # ---> this is where we should land after the exception, and the > > transaction should roll back > > # ---> but the password seems to be changed. > > flash[:warning] = ''Password could not be changed at this time. > > Please retry.'' > > end > > end > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >