Hello all,
I''ve just installed and begun to integrate the salted login generator.
So far I''m very impressed, though I''ve hit a few snags along
the way.
Unfortunately, I''ve met the first one that I haven''t been able
to
resolve on my own.
When I hit the login action, I get errors in my log files. The specific
error with trace is included below. Unfortunately, I''m a ruby/rails
newb and my skills don''t seem to be strong enough to track this one
down.
Another problem I''m having, and I''m not sure if this is
related or not,
is that every page load drops the following in my apache error log:
[Tue May 17 17:14:52 2005] [error] [client xxx.xxx.xxx.xxx] FastCGI:
server "/opt/www/toolbox/public/dispatch.fcgi" stderr:
/opt/www/toolbox/public/../config/..//app/helpers/user_helper.rb:8:
warning: already initialized constant DEFAULT_HEAD_OPTIONS
I''ve grepped the entire tree and the only mentions of
DEFAULT_HEAD_OPTIONS exist in that file. It''s set at the beginning of
the file:
DEFAULT_HEAD_OPTIONS = {
:notice => true,
:message => true,
:error => false
}.freeze
It must exist elsewhere in the app, but I can''t find where. Probably
part of rails itself... is anyone else using the salted login generator
seeing this one?
Thanks,
Ben
> When I hit the login action, I get errors in my log files. The specific > error with trace is included below. Unfortunately, I''m a ruby/rails > newb and my skills don''t seem to be strong enough to track this one > down.Wooo. Way to include the log. Here we go: Processing UserController#login (for 192.168.243.123 at Tue May 17 17:28:33 PDT 2005) Parameters: {"action"=>"login", "controller"=>"user"} User Columns (0.000966) SHOW FIELDS FROM users Rendering user/login within layouts/scaffold User Columns (0.000815) SHOW FIELDS FROM users Rendering layouts/scaffold (200 OK) User Columns (0.000806) SHOW FIELDS FROM users NoMethodError (undefined method `[]'' for nil:NilClass): app/controllers/user_controller.rb:8:in `login'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/base.rb:708:in `send'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/base.rb:708:in `perform_action_without_filters'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/filters.rb:294:in `perform_action_without_benchmark'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/benchmarking.rb:37:in `perform_action_without_rescue'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/benchmarking.rb:37:in `measure'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/benchmarking.rb:37:in `perform_action_without_rescue'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/rescue.rb:79:in `perform_action'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/base.rb:330:in `send'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/base.rb:330:in `process'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/base.rb:273:in `process'' /usr/local/lib/ruby/gems/1.8/gems/rails-0.12.1/lib/dispatcher.rb:32:in `dispatch'' /opt/www/toolbox/public/dispatch.fcgi:20 /opt/www/toolbox/public/dispatch.fcgi:18:in `each_cgi'' /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each'' /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each_cgi'' /opt/www/toolbox/public/dispatch.fcgi:18 Rendering /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/action_controller/templates/rescues/layout.rhtml (500 Internal Error)
I get the same error on signup. The issue is that params[''user''] is nil, so accessing params[''user''][''login''] crashes. This is happening a lot in other methods in salted login generator, too. There are 2 solutions: 1) always make sure params[''user''] != nil 2) handle params[''user''] == nil case in all methods. What i need to know is _why_ it''s crashing - is it crashing because the call to login is wrong / should have parameters / should not have happened at all etc / or is it wrong because login should simply handle params[''user''] == nil. Do we blame the caller or the callee? N. On May 18, 2005, at 7:39, Ben Bleything wrote:>> When I hit the login action, I get errors in my log files. The >> specific >> error with trace is included below. Unfortunately, I''m a ruby/rails >> newb and my skills don''t seem to be strong enough to track this one >> down. > > Wooo. Way to include the log. Here we go: > > Processing UserController#login (for 192.168.243.123 at Tue May 17 > 17:28:33 PDT 2005) > Parameters: {"action"=>"login", "controller"=>"user"} > User Columns (0.000966) SHOW FIELDS FROM users > Rendering user/login within layouts/scaffold > User Columns (0.000815) SHOW FIELDS FROM users > Rendering layouts/scaffold (200 OK) > User Columns (0.000806) SHOW FIELDS FROM users > > > NoMethodError (undefined method `[]'' for nil:NilClass): > app/controllers/user_controller.rb:8:in `login'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:708:in `send'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:708:in `perform_action_without_filters'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/filters.rb:294:in `perform_action_without_benchmark'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/benchmarking.rb:37:in > `perform_action_without_rescue'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/benchmarking.rb:37:in `measure'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/benchmarking.rb:37:in > `perform_action_without_rescue'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/rescue.rb:79:in `perform_action'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:330:in `send'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:330:in `process'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:273:in `process'' > > /usr/local/lib/ruby/gems/1.8/gems/rails-0.12.1/lib/dispatcher.rb:32:in > `dispatch'' > /opt/www/toolbox/public/dispatch.fcgi:20 > /opt/www/toolbox/public/dispatch.fcgi:18:in `each_cgi'' > /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each'' > /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each_cgi'' > /opt/www/toolbox/public/dispatch.fcgi:18 > > > Rendering > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/templates/rescues/layout.rhtml (500 Internal Error) > _______________________________________________ > 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
I get the same error on signup. The issue is that params[''user''] is nil, so accessing params[''user''][''login''] crashes. This is happening a lot in other methods in salted login generator, too. There are 2 solutions: 1) always make sure params[''user''] != nil 2) handle params[''user''] == nil case in all methods. What i need to know is _why_ it''s crashing - is it crashing because the call to login is wrong / should have parameters / should not have happened at all etc / or is it wrong because login should simply handle params[''user''] == nil. Do we blame the caller or the callee? N. On May 18, 2005, at 7:39, Ben Bleything wrote:>> When I hit the login action, I get errors in my log files. The >> specific >> error with trace is included below. Unfortunately, I''m a ruby/rails >> newb and my skills don''t seem to be strong enough to track this one >> down. > > Wooo. Way to include the log. Here we go: > > Processing UserController#login (for 192.168.243.123 at Tue May 17 > 17:28:33 PDT 2005) > Parameters: {"action"=>"login", "controller"=>"user"} > User Columns (0.000966) SHOW FIELDS FROM users > Rendering user/login within layouts/scaffold > User Columns (0.000815) SHOW FIELDS FROM users > Rendering layouts/scaffold (200 OK) > User Columns (0.000806) SHOW FIELDS FROM users > > > NoMethodError (undefined method `[]'' for nil:NilClass): > app/controllers/user_controller.rb:8:in `login'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:708:in `send'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:708:in `perform_action_without_filters'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/filters.rb:294:in `perform_action_without_benchmark'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/benchmarking.rb:37:in > `perform_action_without_rescue'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/benchmarking.rb:37:in `measure'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/benchmarking.rb:37:in > `perform_action_without_rescue'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/rescue.rb:79:in `perform_action'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:330:in `send'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:330:in `process'' > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/base.rb:273:in `process'' > > /usr/local/lib/ruby/gems/1.8/gems/rails-0.12.1/lib/dispatcher.rb:32:in > `dispatch'' > /opt/www/toolbox/public/dispatch.fcgi:20 > /opt/www/toolbox/public/dispatch.fcgi:18:in `each_cgi'' > /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each'' > /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each_cgi'' > /opt/www/toolbox/public/dispatch.fcgi:18 > > > Rendering > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/templates/rescues/layout.rhtml (500 Internal Error) > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I''m seeing similar errors - the application hangs just before sending the confirmation email. Joshua Sierles On 5/18/05, Nikolaus Heger <nikolaus.heger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I get the same error on signup. > > The issue is that params[''user''] is nil, so accessing > params[''user''][''login''] crashes. >
I am running the standard unit tests that come with salted login generator (which are great, BTW) and i am getting a very strange error message:> 1) Error: > test_signup(UserControllerTest): > NoMethodError: undefined method `controller_path'' for > UserController:Class > > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/test_process.rb:249:in `process'' > (eval):3:in `post'' > ./test/functional/user_controller_test.rb:71:in `do_test_signup'' > ./test/functional/user_controller_test.rb:143:in `test_signup''This error happens 9 times altogether, always the same stack trace. Always happens on post. I don''t understand this at all because controller_path is part of ActionController::Base and UserController inherits from it ApplicationController which inherits from ActionController::Base I even tried a quick hack in inserting the source code from ActionController in UserController - same error message. Any ideas? I am lost... Thanks! Nik _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Did you make sure to set up your email settings in your
root/config/environments directory? Such as:
ActionMailer::Base.server_settings = {
:address => "mail.grandecom.net",
:port => 25,
:domain => "mail.grandecom.net"}
I neglected to set that at first and received a similar error. Once I
did that the email confirmation worked fine.
On 5/18/05, Joshua Sierles
<jsierles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> I''m seeing similar errors - the application hangs just before
sending
> the confirmation email.
>
Hi!
I am using the Salted Login Generator, largely without problems.
However, there are two unit test failures when running
rake on a pristine, clean SLG install:
1) Failure:
test_change_password(UserControllerTest)
[/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
action_controller/deprecated_assertions.rb:23:in `assert_session_has''
./test/functional/user_controller_test.rb:186:in
`do_change_password''
./test/functional/user_controller_test.rb:194:in
`test_change_password'']:
<"user"> is not in the session
<#<ActionController::TestSession:0x25960e0
@attributes={"user"=>nil, "flash"=>{}}>>
2) Failure:
test_signup(UserControllerTest)
[/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
action_controller/assertions.rb:44:in `assert_response''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
action_controller/deprecated_assertions.rb:13:in `assert_redirect''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
action_controller/deprecated_assertions.rb:98:in `assert_redirect_url''
./test/functional/user_controller_test.rb:37:in `do_test_signup''
./test/functional/user_controller_test.rb:145:in `test_signup'']:
Expected response to be a <:redirect>, but was <200>
I have determined that both of those failures come as a result of
ActionMailer::Base.inject_one_error = true
not being handled correctly. In both cases things get stored in the
database even though a confirmation email could not be sent.
In the signup test (2), the user is saved even though there were
delivery problems, which causes test after to fail: The first test
(with bad_email = true) saves a user when it should not - or at least
doesn''t delete the newly created user after figuring out that the email
was bad.
The second test (bad_email = false) then fails because the user name is
already taken.
If i remove the test with bad email the second test does not cause a
failure.
BTW, i also replaced assert_redirect_url with the non-deprecated
version:
assert_redirected_to({:action => "login"}) # no difference
I also added an assert that ensures that the test with the actual error
fails rather than the one after:
get :logout
assert_session_has_no "user"
### NEW CODE
if bad_email
# logging in with the changed password should not work on bad email
post :login, "user" => { "login" => "bob",
"password" =>
"changed_password" }
assert_session_has_no "user"
end
### END NEW CODE
if not bad_password and not bad_email.....
in (1) the user is saved despite email problems again. This time, the
changed password is saved even though the email could not be delivered.
Judging from the code, this is the intended - but incorrect - behavior.
What is a bit surprising is that the unit tests test for this case and
find out that it''s not being handled correctly, yet the error is still
in the code... ?!
Am i doing something really wrong, or do i just need to fix those
issues?
Nik
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails
On May 23, 2005, at 1:53 AM, nikolaus heger wrote:> Hi! > > I am using the Salted Login Generator, largely without problems. > However, there are two unit test failures when running > rake on a pristine, clean SLG install: > > 1) Failure: > test_change_password(UserControllerTest) > [/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/deprecated_assertions.rb:23:in `assert_session_has'' > ./test/functional/user_controller_test.rb:186:in > `do_change_password'' > ./test/functional/user_controller_test.rb:194:in > `test_change_password'']: > <"user"> is not in the session <#<ActionController::TestSession: > 0x25960e0 > @attributes={"user"=>nil, "flash"=>{}}>> > > 2) Failure: > test_signup(UserControllerTest) > [/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/assertions.rb:44:in `assert_response'' > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/deprecated_assertions.rb:13:in `assert_redirect'' > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/ > action_controller/deprecated_assertions.rb:98:in `assert_redirect_url'' > ./test/functional/user_controller_test.rb:37:in `do_test_signup'' > ./test/functional/user_controller_test.rb:145:in `test_signup'']: > Expected response to be a <:redirect>, but was <200> > > I have determined that both of those failures come as a result of > ActionMailer::Base.inject_one_error = true > not being handled correctly. In both cases things get stored in the > database even though a confirmation email could not be sent. >Your database must support transactions, or else the test code will not work. For MySQL, make sure the table type is InnoDB. The intent is that the changes to the database are rolled back if the email cannot be sent.> In the signup test (2), the user is saved even though there were > delivery problems, which causes test after to fail: The first test > (with bad_email = true) saves a user when it should not - or at > least doesn''t delete the newly created user after figuring out that > the email was bad. > The second test (bad_email = false) then fails because the user > name is already taken. > If i remove the test with bad email the second test does not cause > a failure. > BTW, i also replaced assert_redirect_url with the non-deprecated > version: > assert_redirected_to({:action => "login"}) # no difference > > I also added an assert that ensures that the test with the actual > error fails rather than the one after: > get :logout > assert_session_has_no "user" > ### NEW CODE > if bad_email > # logging in with the changed password should not work on > bad email > post :login, "user" => { "login" => "bob", "password" => > "changed_password" } > assert_session_has_no "user" > end > ### END NEW CODE > if not bad_password and not bad_email..... > > > in (1) the user is saved despite email problems again. This time, > the changed password is saved even though the email could not be > delivered. Judging from the code, this is the intended - but > incorrect - behavior. > > What is a bit surprising is that the unit tests test for this case > and find out that it''s not being handled correctly, yet the error > is still in the code... ?! > > Am i doing something really wrong, or do i just need to fix those > issues? >Once you change the table type, these tests should pass. The unit test code does express the intended behavior. -joe> Nik > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >Joseph Hosteny jhosteny-ee4meeAH724@public.gmane.org
> Your database must support transactions, or else the test code will > not work. For MySQL, make sure the table type is InnoDB. The intent is > that the changes to the database are rolled back if the email cannot > be sent.ARGH. Was this in the doc somewhere? We''re not using innodb.> Once you change the table type, these tests should pass. The unit test > code does express the intended behavior.I''ll convert now and see. thanks for the help, _alex -- alex black, founder the turing studio, inc. 510.666.0074 root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
On May 23, 2005, at 4:46 PM, alex black wrote:>> Your database must support transactions, or else the test code >> will not work. For MySQL, make sure the table type is InnoDB. The >> intent is that the changes to the database are rolled back if the >> email cannot be sent. >> > > ARGH. Was this in the doc somewhere? We''re not using innodb. >Yes, towards the top of the requirements section ahead of the DB tables. Also, the MySQL table type is shown as InnoDB.> >> Once you change the table type, these tests should pass. The unit >> test code does express the intended behavior. >> > > I''ll convert now and see. > > thanks for the help, > > _alex > > > -- > alex black, founder > the turing studio, inc. > > 510.666.0074 > root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org > http://www.turingstudio.com > > 2600 10th street, suite 635 > berkeley, ca 94710 > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >