UserEngine deployment pain: can't login


#1

All right, after a full day of troubleshooting, I’ll restate my problem:

  1. On my dev machine, my application works perfectly with the
    LoginEngine/UserEngine combo.

  2. On the production box, where prior builds of my app worked before
    installing the engines, I am stuck at the login page. I stop Apache,
    kill my fcgis, delete the session files in /tmp, restart apache, and
    it’s the same thing. Login page.

  3. I have dropped all the engine-related tables three or four times now,
    re-run rake engine_migrate and boostrap each time, and the tables all
    look correct. There is an admin user with the email address I specified
    in environment.rb. The roles and permissions and the join tables all
    look properly populated.

  4. I have given up for now on setting my before_action on a
    per-controller basis even though it worked berfectly on the dev box. I
    got rid of all of those directives and the mixins in
    RAILS_ROOT/app/controllers and instead put the single :authorize_action
    after the engine includes in application.rb.

  5. I have checked, double-checked and triple-checked the includes in
    application.rb and application_helper.rb.

After all this, my dev machine works exactly as expected: all actions
require a user to be logged in and if it’s not the admin, they need
assigned permissions. All of this works, including the admin user’s
ability to work with roles and user permissions.

On the production machine, I simply attempt to access /user/list… which
correctly redirects me to /user/login… and I’m stuck. I cannot log in.

Clicking the signup or forgot-password links crap out with the familiar
nil-user error:

NoMethodError in User#forgot_password

Showing vendor/plugins/login_engine/app/views/user/forgot_password.rhtml
where line #4 raised:

undefined method `errors’ for nil:NilClass

Extracted source (around line #4):

1:


2:

Forgotten Password


3:
4: <%= error_messages_for ‘user’ %>
5:
6:

7:

Enter your email address in the field below and click ‘Reset
Password’ to have instructions on how to retrieve your forgotten
password emailed to you.

Now what?


#2

SOLVED!

Still don’t know why it was working all along on one environment and not
the other, but I got completely rid of my overloading user_ and role_
controllers and now it seems to be working. So instead of applying
before_filters on an as-needed basis, I’m going to apply it globally in
application.rb and disable it–or grant guest privs, I suppose–as
necessary.

Ugh.

Steve K. wrote:

All right, after a full day of troubleshooting, I’ll restate my problem:

  1. On my dev machine, my application works perfectly with the
    LoginEngine/UserEngine combo.

  2. On the production box, where prior builds of my app worked before
    installing the engines, I am stuck at the login page. I stop Apache,
    kill my fcgis, delete the session files in /tmp, restart apache, and
    it’s the same thing. Login page.

  3. I have dropped all the engine-related tables three or four times now,
    re-run rake engine_migrate and boostrap each time, and the tables all
    look correct. There is an admin user with the email address I specified
    in environment.rb. The roles and permissions and the join tables all
    look properly populated.

  4. I have given up for now on setting my before_action on a
    per-controller basis even though it worked berfectly on the dev box. I
    got rid of all of those directives and the mixins in
    RAILS_ROOT/app/controllers and instead put the single :authorize_action
    after the engine includes in application.rb.

  5. I have checked, double-checked and triple-checked the includes in
    application.rb and application_helper.rb.

After all this, my dev machine works exactly as expected: all actions
require a user to be logged in and if it’s not the admin, they need
assigned permissions. All of this works, including the admin user’s
ability to work with roles and user permissions.

On the production machine, I simply attempt to access /user/list… which
correctly redirects me to /user/login… and I’m stuck. I cannot log in.

Clicking the signup or forgot-password links crap out with the familiar
nil-user error:

NoMethodError in User#forgot_password

Showing vendor/plugins/login_engine/app/views/user/forgot_password.rhtml
where line #4 raised:

undefined method `errors’ for nil:NilClass

Extracted source (around line #4):

1:


2:

Forgotten Password


3:
4: <%= error_messages_for ‘user’ %>
5:
6:

7:

Enter your email address in the field below and click ‘Reset
Password’ to have instructions on how to retrieve your forgotten
password emailed to you.

Now what?


#3

I’m having a similar problem, but I don’t think your solution works for
me because I haven’t overloaded any controllers.

Here are the specifics of my situation.

Everything works fine on development with webrick. When I deploy to
Apache 1.3 + mod_fcgi, I cannot login. Even after entering my login
information, my screen returns to the login page.

I’ve added some privileges for some controllers to the Guest role (so
that I don’t have to login) and I can execute that code. That tells me
that the routine to check if Guest can do something still works. For
some unknown reason, I cannot change my status to ‘logged in’.

I’ve set the file system privileges to the tmp directory so that anyone
can write there. I’ve cleared out all session files, and have seen new
session files appear, so I don’t believe that there is a problem with
session management.

I thought that maybe because my deployment uses a symlink to add the
Rails app to an existing web site, the routes.rb file needed to be
modified. However, adding the directory to the mapping makes Rails
submit to the wrong controller/action. So, I’m at a loss.

Can you offer any advice?

Thanks,

-Anthony

Steve K. wrote:

SOLVED!

Still don’t know why it was working all along on one environment and not
the other, but I got completely rid of my overloading user_ and role_
controllers and now it seems to be working. So instead of applying
before_filters on an as-needed basis, I’m going to apply it globally in
application.rb and disable it–or grant guest privs, I suppose–as
necessary.

Ugh.